Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
RFC 5266
also known as BCP 136
| Document | Type | RFC - Best Current Practice (June 2008) | |
|---|---|---|---|
| Authors | Pasi Eronen , Vijay Devarapalli | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Jari Arkko | |
| Send notices to | (None) |
RFC 5266
Network Working Group V. Devarapalli
Request for Comments: 5266 Wichorus
BCP: 136 P. Eronen
Category: Best Current Practice Nokia
June 2008
Secure Connectivity and Mobility Using Mobile IPv4 and
IKEv2 Mobility and Multihoming (MOBIKE)
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
Enterprise users require mobility and secure connectivity when they
roam and connect to the services offered in the enterprise. Secure
connectivity is required when the user connects to the enterprise
from an untrusted network. Mobility is beneficial when the user
moves, either inside or outside the enterprise network, and acquires
a new IP address. This document describes a solution using Mobile
IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide
secure connectivity and mobility.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Access Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Access Mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2. Access Mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3. Access Mode: 'mc' . . . . . . . . . . . . . . . . . . 6
3.2. Mobility within the Enterprise . . . . . . . . . . . . . . 7
3.3. Mobility When outside the Enterprise . . . . . . . . . . . 7
3.4. Crossing Security Boundaries . . . . . . . . . . . . . . . 7
3.4.1. Operation When Moving from an Untrusted Network . . . 8
3.4.2. Operation When Moving from a Trusted Network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Applicability to a Mobile Operator Network . . . . . 13
Devarapalli & Eronen Best Current Practice [Page 1]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
1. Introduction
A typical enterprise network consists of users connecting to the
services from a trusted network (intranet), and from an untrusted
network (Internet). The trusted and untrusted networks are typically
separated by a demilitarized zone (DMZ). Access to the intranet is
controlled by a firewall and a Virtual Private Network (VPN) gateway
in the DMZ.
Enterprise users, when roaming on untrusted networks, most often have
to authenticate themselves to the VPN gateway and set up a secure
tunnel in order to access the intranet. The use of IPsec VPNs is
very common to enable such secure connectivity to the intranet. When
the user is on the trusted network, VPNs are not used. However, the
users benefit tremendously when session mobility between subnets,
through the use of Mobile IPv4, is available.
There has been some work done on using Mobile IPv4 and IPsec VPNs to
provide roaming and secure connectivity to an enterprise [RFC5265]
[RFC4093]. The solution described in [RFC5265] was designed with
certain restrictions, including requiring no modifications to the VPN
gateways, and involves the use of two layers of MIPv4, with one home
agent inside the intranet and one in the Internet or in the DMZ
before the VPN gateway. The per-packet overhead is very high in this
solution. It is also challenging to implement and have two instances
of MIPv4 active at the same time on a mobile node. However, the
solution described here is only applicable when Internet Key Exchange
Protocol version 2 (IKEv2) IPsec VPNs are used.
This document describes an alternate solution that does not require
two layers of MIPv4. The solution described in this document uses
Mobile IPv4 when the mobile node is on the trusted network and
MOBIKE-capable IPsec VPNs when the mobile node is on the untrusted
network. The mobile node uses the tunnel inner address (TIA) given
out by the IPsec VPN gateway as the co-located care-of address (CoA)
for MIPv4 registration. This eliminates the need for using an
external MIPv4 home agent and the need for encapsulating the VPN
tunnel inside a MIPv4 tunnel.
The following assumptions are made for the solution described in this
document.
o IKEv2 [RFC4306] and IPsec [RFC4301] are used to set up the VPN
tunnels between the mobile node and the VPN gateway.
o The VPN gateway and the mobile node support MOBIKE extensions as
defined in [RFC4555].
Devarapalli & Eronen Best Current Practice [Page 2]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
o When the mobile node is on the trusted network, traffic should not
go through the DMZ. Current deployments of firewalls and DMZs
consider the scenario where only a small amount of the total
enterprise traffic goes through the DMZ. Routing through the DMZ
typically involves stateful inspection of each packet by the
firewalls in the DMZ. Moreover, the DMZ architecture assumes that
the DMZ is less secure than the internal network. Therefore, the
DMZ-based architecture allows the least amount of traffic to
traverse the DMZ, that is, only traffic between the trusted
network and the external network. Requiring all normal traffic to
the mobile nodes to traverse the DMZ would negate this
architecture.
o When the mobile node is on the trusted network and uses a wireless
access technology, confidentiality protection of the data traffic
is provided by the particular access technology. In some
networks, confidentiality protection MAY be available between the
mobile node and the first hop access router, in which case it is
not required at layer 2.
This document also presents a solution for the mobile node to detect
when it is on a trusted network, so that the IPsec tunnel can be
dropped and the mobile node can use Mobile IP in the intranet.
IPsec VPN gateways that use IKEv1 [RFC2409] are not addressed in this
document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", RFC 2911 IPP/1.1: Model and Semantics September 2000
"job-hold-until" (type3 keyword | name(MAX)):
The client OPTIONALLY supplies this attribute. The IPP object
MUST support this Operation attribute in a Restart-Job request,
if it supports the "job-hold-until" Job Template attribute in
create operations. See section 4.2.2. Otherwise, the IPP
object NEED NOT support the "job-hold-until" Operation
attribute in a Restart-Job request.
If supplied and supported as specified in the Printer's "job-
hold-until-supported" attribute, the IPP object copies the
supplied Operation attribute to the Job object, replacing the
job's previous "job-hold-until" attribute, if present, and
makes the job a candidate for scheduling during the supplied
named time period. See section 4.2.2.
If supplied, but the value is not supported, the IPP object
accepts the request, returns the unsupported attribute or value
in the Unsupported Attributes Group according to section 3.1.7,
returns the 'successful-ok-ignored-or-substituted-attributes'
status code, and holds the job indefinitely until a client
performs a subsequent Release-Job operation.
If supplied, but the "job-hold-until" Operation attribute
itself is not supported, the IPP object accepts the request,
returns the unsupported attribute with the out-of-band
'unsupported' value in the Unsupported Attributes Group
according to section 3.1.7, returns the 'successful-ok-
ignored-or-substituted-attributes' status code, and restarts
the job, i.e., ignores the "job-hold-until" attribute.
If the client (1) supplies a value that specifies a time period
that has already started or the 'no-hold' value (meaning don't
hold the job) and (2) the IPP object supports the "job-hold-
until" operation attribute and there are no other reasons to
hold the job, the IPP object makes the job a candidate for
processing immediately (see Section 4.2.2).
If the client does not supply a "job-hold-until" operation
attribute in the request, the IPP object removes the "job-
hold-until" attribute, if present, from the job. If there are
no other reasons to hold the job, the Restart-Job operation
makes the job a candidate for processing immediately (see
Section 4.2.2).
Hastings, et al. Standards Track [Page 77]
RFC 2911 IPP/1.1: Model and Semantics September 2000
3.3.7.2 Restart-Job Response
The groups and attributes are the same as for a Cancel-Job response
(see section 3.3.3.2).
Note: In the future an OPTIONAL Modify-Job or Set-Job-Attributes
operation may be specified that allows the client to modify other
attributes before releasing the restarted job.
4. Object Attributes
This section describes the attributes with their corresponding
attribute syntaxes and values that are part of the IPP model. The
sections below show the objects and their associated attributes which
are included within the scope of this protocol. Many of these
attributes are derived from other relevant documents:
- Document Printing Application (DPA) [ISO10175]
- RFC 1759 Printer MIB [RFC1759]
Each attribute is uniquely identified in this document using a
"keyword" (see section 12.2.1) which is the name of the attribute.
The keyword is included in the section header describing that
attribute.
Note: Not only are keywords used to identify attributes, but one of
the attribute syntaxes described below is "keyword" so that some
attributes have keyword values. Therefore, these attributes are
defined as having an attribute syntax that is a set of keywords.
4.1 Attribute Syntaxes
This section defines the basic attribute syntax types that all
clients and IPP objects MUST be able to accept in responses and
accept in requests, respectively. Each attribute description in
sections 3 and 4 includes the name of attribute syntax(es) in the
heading (in parentheses). A conforming implementation of an
attribute MUST include the semantics of the attribute syntax(es) so
identified. Section 6.3 describes how the protocol can be extended
with new attribute syntaxes.
The attribute syntaxes are specified in the following sub-sections,
where the sub-section heading is the keyword name of the attribute
syntax inside the single quotes. In operation requests and responses
each attribute value MUST be represented as one of the attribute
syntaxes specified in the sub-section heading for the attribute. In
addition, the value of an attribute in a response (but not in a
Hastings, et al. Standards Track [Page 78]
RFC 2911 IPP/1.1: Model and Semantics September 2000
request) MAY be one of the "out-of-band" values whose special
encoding rules are defined in the "Encoding and Transport" document
[RFC2910]. Standard "out-of-band" values are:
'unknown': The attribute is supported by the IPP object, but the
value is unknown to the IPP object for some reason.
'unsupported': The attribute is unsupported by the IPP object.
This value MUST be returned only as the value of an attribute
in the Unsupported Attributes Group.
'no-value': The attribute is supported by the Printer object, but
the administrator has not yet configured a value.
All attributes in a request MUST have one or more values as defined
in Sections 4.2 to 4.4. Thus clients MUST NOT supply attributes with
"out-of-band" values for operations defined in this document. All
attributes in a response MUST have one or more values as defined in
Sections 4.2 to 4.4 or a single "out-of-band" value.
Most attributes are defined to have a single attribute syntax.
However, a few attributes (e.g., "job-sheet", "media", "job-hold-
until") are defined to have several attribute syntaxes, depending on
the value. These multiple attribute syntaxes are separated by the
"|" character in the sub-section heading to indicate the choice.
Since each value MUST be tagged as to its attribute syntax in the
protocol, a single-valued attribute instance may have any one of its
attribute syntaxes and a multi-valued attribute instance may have a
mixture of its defined attribute syntaxes.
4.1.1 'text'
A text attribute is an attribute whose value is a sequence of zero or
more characters encoded in a maximum of 1023 ('MAX"chair", or "participant") for a "VTODO" calendar component. The
"REQUEST" method is sent by one of the "Attendees" of an existing
"VTODO" calendar component to some other individual.
For the purposes of this description, the "Attendee" delegating the
"VTODO" calendar component is referred to as the "Delegator". The
"Attendee" receiving the delegation request is referred to as the
"Delegate".
The "Delegator" of a "VTODO" calendar component MUST forward the
existing "REQUEST" method for a "VTODO" calendar component to the
"Delegate". The "VTODO" calendar component description MUST include
the "Delegator's" up-to-date "VTODO" calendar component definition.
Daboo Expires April 7, 2010 [Page 47]
Internet-Draft iTIP October 2009
The "REQUEST" method MUST also include an "ATTENDEE" property with
the calendar address of the "Delegate". The "Delegator" MUST also
send a "REPLY" method back to the "Organizer" with the "Delegator's"
"Attendee" property "PARTSTAT" parameter value set to "DELEGATED".
In addition, the "DELEGATED-TO" parameter MUST be included with the
calendar address of the "Delegate". A response to the delegation
"REQUEST" is sent from the "Delegate" to the "Organizer" and
optionally, to the "Delegator". The "REPLY" method from the
"Delegate" SHOULD include the "ATTENDEE" property with their calendar
address and the "DELEGATED-FROM" parameter with the value of the
"Delegator's" calendar address.
The delegation "REQUEST" method MUST assign a value for the "RSVP"
property parameter associated with the "Delegator's" "Attendee"
property to that of the "Delegate's" "ATTENDEE" property. For
example if the "Delegator's" "ATTENDEE" property specifies
"RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
"RSVP=TRUE".
3.4.2.4. REQUEST Forwarded To An Uninvited Calendar User
An "Attendee" assigned a "VTODO" calendar component may send the
"VTODO" calendar component to another new CU, not previously
associated with the "VTODO" calendar component. The current
"Attendee" assigned the "VTODO" calendar component does this by
forwarding the original "REQUEST" method to the new CU. The new CU
can send a "REPLY" to the "Organizer" of the "VTODO" calendar
component. The reply contains an "ATTENDEE" property for the new CU.
The "Organizer" ultimately decides whether or not the new CU becomes
part of the to-do and is not obligated to do anything with a "REPLY"
from a new (uninvited) CU. If the "Organizer" does not want the new
CU to be part of the to-do, the new "ATTENDEE" property is not added
to the "VTODO" calendar component. The "Organizer" MAY send the CU a
"CANCEL" message to indicate that they will not be added to the to-
do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
property is added to the "VTODO" calendar component. Furthermore,
the "Organizer" is free to change any "ATTENDEE" property parameter
from the values supplied by the new CU to something the "Organizer"
considers appropriate. The "Organizer" SHOULD send the new attendee
a "REQUEST" message to inform them that they have been added.
When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
MUST NOT make changes to the original message.
Daboo Expires April 7, 2010 [Page 48]
Internet-Draft iTIP October 2009
3.4.2.5. REQUEST Updated Attendee Status
An "Organizer" of a "VTODO" may request an updated status from one or
more "Attendees". The "Organizer" sends a "REQUEST" method to the
"Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
"SEQUENCE" property for the "VTODO" is not changed from its previous
value. A recipient determines that the only change in the "REQUEST"
is that their "RSVP" property parameter indicates a request for an
updated status. The recipient SHOULD respond with a "REPLY" method
indicating their current status with respect to the "REQUEST".
3.4.3. REPLY
The "REPLY" method in a "VTODO" calendar component is used to respond
(e.g., accept or decline) to a request or to reply to a delegation
request. It is also used by an "Attendee" to update their completion
status. When used to provide a delegation response, the "Delegator"
MUST include the calendar address of the "Delegate" in the
"DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property.
The "Delegate" MUST include the calendar address of the "Delegator"
on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE"
property.
The "REPLY" method MAY also be used to respond to an unsuccessful
"VTODO" calendar component "REQUEST" method. Depending on the
"REQUEST-STATUS" value, no scheduling action may have been performed.
The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
method from a "Calendar User" not in the original "REQUEST". For
example, a "REPLY" method MAY be received from a "Delegate" of a
"VTODO" calendar component. In addition, the "REPLY" method MAY be
received from an unknown "Calendar User", having been forwarded the
"REQUEST" by an original "Attendee" of the "VTODO" calendar
component. This uninvited "Attendee" MAY be accepted, or the
"Organizer" MAY cancel the "VTODO" calendar component for the
uninvited "Attendee" by sending them a "CANCEL" method.
This method type is an iCalendar object that conforms to the
following property constraints:
+-------------------------------------------+
| Constraints for a METHOD:REPLY of a VTODO |
+-------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" |
Daboo Expires April 7, 2010 [Page 49]
Internet-Draft iTIP October 2009
| | | |
| VTODO | 1+ | All component MUST have the same |
| | | UID |
| ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| REQUEST-STATUS | 0+ | |
| UID | 1 | MUST be the UID of the original |
| | | REQUEST |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| COMPLETED | 0 or 1 | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| SEQUENCE | 0 or 1 | MUST be the sequence number of |
| | | the original REQUEST if greater |
| | | than 0. MAY be present if 0. |
| STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | Can be null |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| | | |
| VALARM | 0 | |
| | | |
Daboo Expires April 7, 2010 [Page 50]
Internet-Draft iTIP October 2009
| VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.4.4. ADD
The "ADD" method allows the "Organizer" to add one or more new
instances to an existing "VTODO" using a single iTIP message without
having to send the entire "VTODO" with all the existing instance
data, as it would have to do if the "REQUEST" method were used.
The "UID" must be that of the existing to-do. If the "UID" property
value in the "ADD" is not found on the recipient's calendar, then the
recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
updated with the latest version of the "VTODO". If an "Attendee"
implementation does not support the "ADD" method it should respond
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
When handling an "ADD" message, the "Attendee" treats each component
in the "ADD" message as if it were referenced via an "RDATE"in the
main component.
The "SEQUENCE" property value is incremented as the sequence of to-
dos has changed.
This method type is an iCalendar object that conforms to the
following property constraints:
+-----------------------------------------+
| Constraints for a METHOD:ADD of a VTODO |
+-----------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" |
| | | |
| VTODO | 1 | |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| PRIORITY | 1 | |
Daboo Expires April 7, 2010 [Page 51]
Internet-Draft iTIP October 2009
| SEQUENCE | 1 | MUST be greater than 0 |
| SUMMARY | 1 | Can be null |
| UID | 1 | MUST match that of the original |
| | | to-do |
| ATTACH | 0+ | |
| ATTENDEE | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| COMPLETED | 0 or 1 | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| EXDATE | 0 | |
| RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | |
| RDATE | 0 | |
| RRULE | 0 | |
| | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
Daboo Expires April 7, 2010 [Page 52]
Internet-Draft iTIP October 2009
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.4.5. CANCEL
The "CANCEL" method in a "VTODO" calendar component is used to send a
cancellation notice of an existing "VTODO" calendar request to the
affected "Attendees". The message is sent by the "Organizer" of a
"VTODO" calendar component to the "Attendees" of the "VTODO" calendar
component. For a recurring "VTODO" calendar component, either the
whole "VTODO" calendar component or instances of a "VTODO" calendar
component may be cancelled. To cancel the complete range of a
recurring "VTODO" calendar component, the "UID" property value for
the "VTODO" calendar component MUST be specified and a "RECURRENCE-
ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
an individual instance of a recurring "VTODO" calendar component, the
"RECURRENCE-ID" property value for the "VTODO" calendar component
MUST be specified in the "CANCEL" method.
There are two options for canceling a sequence of instances of a
recurring "VTODO" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified "VTODO"
calendar component and all instances after
b. individual recurrence instances may be cancelled by specifying
multiple "VTODO" components with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled
The "Organizer" MUST send a "CANCEL" message to each "Attendee"
affected by the cancellation. This can be done using a single
"CANCEL" message for all "Attendees", or multiple messages with
different subsets of the affected "Attendees" in each.
When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
incremented as described in Section 2.1.4.
This method type is an iCalendar object that conforms to the
following property constraints:
+--------------------------------------------+
| Constraints for a METHOD:CANCEL of a VTODO |
+--------------------------------------------+
Daboo Expires April 7, 2010 [Page 53]
Internet-Draft iTIP October 2009
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" |
| | | |
| VTODO | 1+ | |
| ATTENDEE | 0+ | MUST include some or all |
| | | "Attendees" being removed from |
| | | the to-do. MUST include some or |
| | | all "Attendees" if the entire |
| | | to-do is cancelled. |
| UID | 1 | MUST echo original UID |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| SEQUENCE | 1 | |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| COMPLETED | 0 or 1 | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | |
| DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | cancel the entire VTODO. If |
| | | removing specific "Attendees" |
| | | then MUST NOT be included. |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
Daboo Expires April 7, 2010 [Page 54]
Internet-Draft iTIP October 2009
| X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.4.6. REFRESH
The "REFRESH" method in a "VTODO" calendar component is used by
"Attendees" of an existing "VTODO" calendar component to request an
updated description from the "Organizer" of the "VTODO" calendar
component. The "Organizer" of the "VTODO" calendar component MAY use
this method to request an updated status from the "Attendees". The
"REFRESH" method MUST specify the "UID" property corresponding to the
"VTODO" calendar component needing update.
A refresh of a recurrence instance of a "VTODO" calendar component
may be requested by specifying the &"SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Many of the following terms are defined in [RFC5265], but are
repeated here to make this document self-contained.
FA: Mobile IPv4 foreign agent.
Co-CoA: co-located care-of address.
FA-CoA: foreign agent care-of address.
FW: firewall.
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet)
network.
Devarapalli & Eronen Best Current Practice [Page 3]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
i-HA: Mobile IPv4 home agent residing in the trusted (intranet)
network.
i-MIP: The mobile node uses the home agent in the internal network.
VPN-TIA: VPN tunnel inner address. This address is given out by the
VPN gateway during IKE negotiation and is routable in the trusted
network.
mVPN: VPN with MOBIKE functionality.
The following access modes are used in explaining the protocol. The
access modes are explained in more detail in [RFC5265].
f: i-MIP with FA-CoA
c: i-MIP with Co-CoA
mc: i-MIP with MOBIKE-enabled VPN, with VPN-TIA as Co-CoA
3. Solution Overview
The mobile node is configured with a home address that remains the
same irrespective of whether the mobile node is inside or outside the
enterprise network. The mobile node is also reachable at the same
home address irrespective of its current point of attachment. When
the mobile node is connected to the intranet directly, it uses Mobile
IP for internal mobility.
When the mobile node roams and connects to an untrusted network
outside the enterprise, it sets up a VPN tunnel to the VPN gateway.
However, it still maintains a valid binding cache entry at the i-HA.
It uses the VPN-TIA, allocated by the VPN gateway, as the co-located
CoA for registration with the i-HA. If the VPN-TIA changes or if the
mobile node moves and connects to another VPN gateway, then it sends
a Registration Request to the i-HA using the new co-located CoA.
If the mobile node moves while outside the enterprise and its access
network changes, it uses the MOBIKE protocol to update the VPN
gateway of its current address. The internal home agent is not aware
of the mobile node's movement as long as the mobile node is attached
to the same VPN gateway and the TIA remains the same.
Figure 1 depicts the network topology assumed for the solution. It
also shows the possible mobile node locations and access modes.
Devarapalli & Eronen Best Current Practice [Page 4]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
{home} (MN) [i-HA]
\ /
.-+---+-.
( )
[mVPN] `--+----'
! !
.--+--. [R]
( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
Figure 1: Network Topology Using MIPv4 and MOBIKE
The solution described above results in a Mobile IP tunnel inside an
IPsec tunnel. The Mobile IP tunnel is between the mobile node and
the home agent, and the IPsec tunnel is between the mobile node (MN)
and the mVPN gateway. The mobile node MUST reverse tunnel through
the home agent [RFC3024] when the Mobile IP tunnel is inside an IPsec
tunnel.
The overhead of running a Mobile IP tunnel inside an IPsec tunnel can
be avoided by having the Mobile IP foreign agent functionality on the
VPN gateway. This is out of scope for this document and is further
described in [MEGHANA].
Whenever the mobile node attaches to a new link, it may encounter a
foreign agent. The mobile node MUST not use the foreign agent
care-of address with the i-HA when attached to an untrusted access
network. The default behavior for the mobile node is to always
configure an address from the access link using DHCP. The mobile
node then checks if it is attached to a trusted access network by
sending a Registration Request to the i-HA in the co-located care-of
address mode. If the mobile node discovers that it is attached to a
trusted access network, then it MAY start using a foreign agent
care-of address with the i-HA. In order to do this, the mobile node
has to perform a new registration with the i-HA.
Devarapalli & Eronen Best Current Practice [Page 5]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
The mobile node can use a foreign agent on a untrusted access
network, if there is an external home agent that the mobile node is
able to use. The use of an external home agent in the untrusted
access network and a home agent in the trusted access network at the
same time is described in detail in [RFC5265].
Some IPsec VPN implementations allow a host to send traffic directly
to the Internet when attached to an untrusted network. This traffic
bypasses the IPsec tunnel with the VPN gateway. This document does
not prevent such traffic from being sent out from the host, but there
will be no mobility or session continuity for the traffic. Any data
traffic that is sent through the Mobile IP tunnel with the home agent
is always sent through the VPN gateway.
3.1. Access Modes
The following access modes are used in the solution described in this
document.
3.1.1. Access Mode: 'c'
This access mode is standard Mobile IPv4 [RFC3344] with a co-located
care-of address. The mobile node must detect that it is connected to
an internal trusted network before using this mode. The co-located
care-of address is assigned by the access network to which the mobile
node is attached.
3.1.2. Access Mode: 'f'
This access mode is standard Mobile IPv4 [RFC3344] with a foreign
agent care-of address. The mobile node can use this mode only when
it detects that it is connected to an internal trusted network and
also detects a foreign agent on the access network.
3.1.3. Access Mode: 'mc'
This access mode involves using both Mobile IPv4 and a MOBIKE-enabled
IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec
tunnel. The mobile node uses the VPN-TIA as the co-located CoA for
registering with the home agent. This mode is used only when the
mobile node is attached to an untrusted network and is required to
set up an IPsec tunnel with a VPN gateway to gain access to the
trusted network.
Devarapalli & Eronen Best Current Practice [Page 6]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
3.2. Mobility within the Enterprise
When the mobile node is inside the enterprise network and attached to
the intranet, it uses Mobile IPv4 [RFC3344] for subnet mobility. The
mobile node always configures a care-of address through DHCP on the
access link and uses it as the co-located care-of address. The
mobile node MAY use a foreign agent care-of address, if a foreign
agent is available. However, the foreign agent care-of address is
used only when the mobile node is attached to the trusted access
network. The mobile node attempts Foreign Agent discovery and CoA
address acquisition through DHCP simultaneously in order to avoid the
delay in discovering a foreign agent when there is no foreign agent
available. The mobile node maintains a valid binding cache entry at
all times at the home agent mapping the home address to the current
CoA. Whenever the mobile node moves, it sends a Registration Request
to update the binding cache entry.
The Mobile IP signaling messages between the mobile node and the home
agent are authenticated as described in [RFC3344].
The mobile node maintains a valid binding cache entry at the home
agent even when it is outside the enterprise network.
3.3. Mobility When outside the Enterprise
When the mobile node is attached to an untrusted network, it sets up
an IPsec VPN tunnel with the VPN gateway to gain access to the
enterprise network. If the mobile node moves and its IP address
changes, it initiates the MOBIKE protocol [RFC4555] to update the
address on the VPN gateway.
The mobile node maintains a binding at the home agent even when it is
outside the enterprise network. If the TIA changes due to the mobile
node re-connecting to the VPN gateway or attaching to a different VPN
gateway, the mobile node should send a Registration Request to its
home agent to update the binding cache with the new TIA.
3.4. Crossing Security Boundaries
Security boundary detection is based on the reachability of the i-HA
from the mobile node's current point of attachment. Whenever the
mobile node detects a change in network connectivity, it sends a
Registration Request to the i-HA without any VPN encapsulation. If
the mobile node receives a Registration Reply with the Trusted
Networks Configured (TNC) extension from the i-HA, then it assumes
that it is on a trusted network. The TNC extension is described in
[RFC5265]. The mobile node MUST check that the Registration Reply is
integrity protected using the mobile node-home agent mobility
Devarapalli & Eronen Best Current Practice [Page 7]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
security association before concluding it is attached to a trusted
network. This security boundary detection is based on the mechanism
described in [RFC5265] to detect attachment to the internal trusted
network. The mobile node should re-transmit the Registration Request
if it does not receive the Registration Reply within a timeout
period. The number of times the mobile node should re-transmit the
Registration Request and the timeout period for receiving the
Registration Reply are configurable on the mobile node.
When the mobile node is attached to an untrusted network and is using
an IPsec VPN to the enterprise network, the ability to send a
Registration Request to the i-HA without VPN encapsulation would
require some interaction between the IPsec and MIPv4 modules on the
mobile node. This is local to the mobile node and out of scope for
this document.
If the mobile node has an existing VPN tunnel to its VPN gateway, it
MUST send a MOBIKE message at the same time as the registration
request to the i-HA whenever the IP address changes. If the mobile
node receives a response from the VPN gateway, but not from the i-HA,
it assumes it is outside the enterprise network. If it receives a
response from the i-HA, then it assumes it is inside the enterprise
network.
There could also be some out-of-band mechanisms that involve
configuring the wireless access points with some information that the
mobile node can recognize as access points that belong to the trusted
network in an enterprise network. Such mechanisms are beyond the
scope of this document.
The mobile node should not send any normal traffic while it is trying
to detect whether it is attached to the trusted or untrusted network.
This is described in more detail in [RFC5265].
3.4.1. Operation When Moving from an Untrusted Network
When the mobile node is outside the enterprise network and attached
to an untrusted network, it has an IPsec VPN tunnel with its mobility
aware VPN gateway, and a valid registration with a home agent on the
intranet with the VPN-TIA as the care-of address.
If the mobile node moves and its IP address changes, it performs the
following steps:
1a. Initiate an IKE mobility exchange to update the VPN gateway with
the current address. If the new network is also untrusted, this
will be enough for setting up the connectivity. If the new
network is trusted, and if the VPN gateway is reachable, this
Devarapalli & Eronen Best Current Practice [Page 8]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
exchange will allow the mobile node to keep the VPN state alive
while on the trusted side. If the VPN gateway is not reachable
from inside, then this exchange will fail.
1b. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal home agent without VPN encapsulation.
2. If the mobile node receives a Registration Reply to the request
sent in step 1b, then the current subnet is a trusted subnet,
and the mobile node can communicate without VPN tunneling. The
mobile node MAY tear down the VPN tunnel.
3.4.2. Operation When Moving from a Trusted Network
When the mobile node is inside the enterprise and attached to the
intranet, it does not use a VPN tunnel for data traffic. It has a
valid binding cache entry at its home agent. If the VPN gateway is
reachable from the trusted network, the mobile node MAY have valid
IKEv2 security associations with its VPN gateway. The IPsec security
associations can be created when required. The mobile node may have
to re-negotiate the IKEv2 security associations to prevent them from
expiring.
If the mobile node moves and its IP address changes, it performs the
following steps:
1. Initiate an IKE mobility exchange to update the VPN gateway with
the current address, or if there is no VPN connection, then
establish a VPN tunnel with the gateway from the new local IP
address. If the new network is trusted, and if the VPN gateway
is reachable, this exchange will allow the mobile node to keep
the VPN state alive, while in the trusted side. If the new
network is trusted and if the VPN gateway is not reachable from
inside, then this exchange will fail.
2. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal home agent without VPN encapsulation.
3. If the mobile node receives a Registration Reply to the request
sent in step 2, then the current subnet is a trusted subnet, and
the mobile node can communicate without VPN tunneling, using only
Mobile IP with the new care-of address.
4. If the mobile node didn't receive the response in step 3, and if
the VPN tunnel is successfully established and registered in step
1, then the mobile node sends a Registration Request over the VPN
tunnel to the internal home agent. After receiving a
Registration Reply from the home agent, the mobile node can start
Devarapalli & Eronen Best Current Practice [Page 9]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
communicating over the VPN tunnel with the Mobile IP home
address.
4. NAT Traversal
There could be a Network Address Translation (NAT) device between the
mobile node and the home agent in any of the access modes, 'c', 'f',
and 'mc', and between the mobile node and the VPN gateway in the
access mode 'mc'. Mobile IPv4 NAT traversal, as described in
[RFC3519], should be used by the mobile node and the home agent in
access modes 'c' or 'f', when there is a NAT device present. When
using access mode, 'mc', IPsec NAT traversal [RFC3947] [RFC3948]
should be used by the mobile node and the VPN gateway, if there is a
NAT device present. Typically, the TIA would be a routable address
inside the enterprise network. But in some cases, the TIA could be
from a private address space associated with the VPN gateway. In
such a case, Mobile IPv4 NAT traversal should be used in addition to
IPsec NAT traversal in the 'mc' mode.
5. Security Considerations
Enterprise connectivity typically requires very strong security, and
the solution described in this document was designed keeping this in
mind.
Security concerns related to the mobile node detecting that it is on
a trusted network and thereafter dropping the VPN tunnel are
described in [RFC5265].
When the mobile node sends a Registration Request to the i-HA from an
untrusted network that does not go through the IPsec tunnel, it will
reveal the i-HA's address, its own identity including the NAI and the
home address, and the Authenticator value in the authentication
extensions to the untrusted network. This may be a concern in some
deployments.
Please see [RFC4555] for MOBIKE-related security considerations, and
[RFC3519], [RFC3947] for security concerns related to the use of NAT
traversal mechanisms for Mobile IPv4 and IPsec.
6. Acknowledgments
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval
Shah, and John Cruz for their participation in developing this
solution.
Devarapalli & Eronen Best Current Practice [Page 10]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
The authors would also like to thank Henrik Levkowetz, Jari Arkko, TJ
Kniveton, Vidya Narayanan, Yaron Sheffer, Hans Sjostrand, Jouni
Korhonen, and Sami Vaarala for reviewing the document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-Based VPN Gateways", RFC 5265, June 2008.
7.2. Informative References
[RFC4093] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile
IPv4 Traversal of Virtual Private Network (VPN) Gateways",
RFC 4093, August 2005.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[MEGHANA] Sahasrabudhe, M. and V. Devarapalli, "Optimizations to
Secure Connectivity and Mobility", Work in Progress,
February 2008.
[RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
Devarapalli & Eronen Best Current Practice [Page 11]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
Devarapalli & Eronen Best Current Practice [Page 12]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
Appendix A. Applicability to a Mobile Operator Network
The solution described in this document can also be applied to a
Mobile Operator's network when the Operator deploys heterogeneous
access networks and some of the access networks are considered as
trusted networks and others as untrusted networks. Figure 2
illustrates such a network topology.
+----------------------+
| +----+ |
+----------------+ | |i-HA| |
| | | +----+ |
(MN)----+ trusted +---+ |
| access network | | internal network |
+----------------+ | |
| |
+----------+-----------+
|
|
|
[mVPN]
+----------------+ |
| | |
(MN)----+ untrusted +--------------+
{mc} | access network |
+----------------+
Figure 2: Network Topology of a Mobile Operator with Trusted and
Untrusted Networks
An IPsec VPN gateway provides secure connectivity to the Operator's
internal network for mobile nodes attached to an untrusted access
network. The VPN gateway supports MOBIKE extensions so that the
IPsec tunnels survive any IP address change when the mobile node
moves while attached to the untrusted access networks.
When the mobile node is attached to the trusted access network, it
uses Mobile IP with the i-HA. It uses the IP address obtained from
the trusted access network as the co-located care-of address to
register with the i-HA. If a foreign agent is available in the
trusted access network, the mobile node may use a foreign agent
care-of address. If the mobile node moves and attaches to an
untrusted access network, it sets up an IPsec tunnel with the VPN
gateway to access the Operator's internal network. It uses the IPsec
TIA as the co-located care-of address to register with the i-HA
thereby creating a Mobile IP tunnel inside an IPsec tunnel.
Devarapalli & Eronen Best Current Practice [Page 13]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
When the mobile node is attached to the trusted access network, it
can either be attached to a foreign link in the trusted network or to
the home link directly. This document does not impose any
restrictions.
Authors' Addresses
Vijay Devarapalli
Wichorus
3590 North First Street
San Jose, CA 95134
USA
EMail: vijay@wichorus.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Devarapalli & Eronen Best Current Practice [Page 14]
RFC 5266 MIPv4 and MOBIKE interworking June 2008
quot;RECURRENCE-ID" property
corresponding to the associated "VTODO" calendar component. The
"Organizer" responds with the latest description and rendition of the
"VTODO" calendar component. In most cases this will be a REQUEST
unless the "VTODO" has been cancelled, in which case the ORGANIZER
MUST send a "CANCEL". This method is intended to facilitate machine
processing of requests for updates to a "VTODO" calendar component.
This method type is an iCalendar object that conforms to the
following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:REFRESH of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" |
| | | |
| VTODO | 1 | |
Daboo Expires April 7, 2010 [Page 55]
Internet-Draft iTIP October 2009
| ATTENDEE | 1 | |
| DTSTAMP | 1 | |
| UID | 1 | MUST echo original UID |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| ATTACH | 0 | |
| CATEGORIES | 0 | |
| CLASS | 0 | |
| COMMENT | 0 | |
| COMPLETED | 0 | |
| CONTACT | 0 | |
| CREATED | 0 | |
| DESCRIPTION | 0 | |
| DTSTART | 0 | |
| DUE | 0 | |
| DURATION | 0 | |
| EXDATE | 0 | |
| GEO | 0 | |
| LAST-MODIFIED | 0 | |
| LOCATION | 0 | |
| ORGANIZER | 0 | |
| PERCENT-COMPLETE | 0 | |
| PRIORITY | 0 | |
| RDATE | 0 | |
| RELATED-TO | 0 | |
| REQUEST-STATUS | 0 | |
| RESOURCES | 0 | |
| RRULE | 0 | |
| SEQUENCE | 0 | |
| STATUS | 0 | |
| URL | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
Daboo Expires April 7, 2010 [Page 56]
Internet-Draft iTIP October 2009
3.4.7. COUNTER
The "COUNTER" method in a "VTODO" calendar component is used by an
"Attendee" of an existing "VTODO" calendar component to submit to the
"Organizer" a counter proposal for the "VTODO" calendar component.
The counter proposal is an iCalendar object consisting of a "VTODO"
calendar component describing the complete description of the
alternate "VTODO" calendar component.
The "Organizer" rejects the counter proposal by sending the
"Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
counter proposal by rescheduling the to-do as described in section
3.4.2.1 Rescheduling a To-Do. The "Organizers" CUA SHOULD send a
"REQUEST" message to all "Attendees" affected by any change triggered
by an accepted "COUNTER".
This method type is an iCalendar object that conforms to the
following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:COUNTER of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" |
| | | |
| VTODO | 1 | |
| ATTENDEE | 1+ | |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| PRIORITY | 1 | |
| SUMMARY | 1 | Can be null |
| UID | 1 | |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| COMPLETED | 0 or 1 | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTSTART | 0 or 1 | |
| DUE | 0 or 1 | If present DURATION MUST NOT be |
| | | present |
Daboo Expires April 7, 2010 [Page 57]
Internet-Draft iTIP October 2009
| DURATION | 0 or 1 | If present DUE MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PERCENT-COMPLETE | 0 or 1 | |
| RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if |
| | | non-zero. MAY be present if |
| | | zero. |
| STATUS | 0 or 1 | MAY be one of |
| | | COMPLETED/NEEDS-ACTION/ |
| | | IN-PROCESS/CANCELLED |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.4.8. DECLINECOUNTER
The "DECLINECOUNTER" method in a "VTODO" calendar component is used
by an "Organizer" of "VTODO" calendar component to reject a counter
proposal offered by one of the "Attendees". The "Organizer" sends
the message to the "Attendee" that sent the "COUNTER" method to the
"Organizer".
Daboo Expires April 7, 2010 [Page 58]
Internet-Draft iTIP October 2009
This method type is an iCalendar object that conforms to the
following property constraints:
+----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VTODO |
+----------------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER&Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Devarapalli & Eronen Best Current Practice [Page 15]