Internet DRAFT - draft-tschofenig-omipv6-multihoming
draft-tschofenig-omipv6-multihoming
Network Working Group H. Tschofenig
Internet-Draft Siemens
Expires: January 19, 2006 W. Haddad
Ericsson Research
July 18, 2005
OMIPv6 Multi-Homing and Privacy
draft-tschofenig-omipv6-multihoming-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Optimized Mobile IPv6 with CGA (OMIPv6-CGA) protocol specifies a
new route optimization (RO) to solve the mobility problem. Privacy
extensions for OMIPv6 adds anonymity and unlinkability support to the
OMIPv6-CGA protocol.
This document combines OMIPv6-CGA including its privacy extension
with support for multi-homing. As such, it offers an efficient and
Tschofenig & Haddad Expires January 19, 2006 [Page 1]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
secure multi-homing and mobility support for MIPv6 using CGAs
including privacy support.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Strawman Protocol Proposal . . . . . . . . . . . . . . . . . 4
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Alternate Care-of Address extension . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1 Normative References . . . . . . . . . . . . . . . . . . 10
11.2 Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 13
Tschofenig & Haddad Expires January 19, 2006 [Page 2]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
1. Introduction
Optimized Mobile IPv6 with CGA [I-D.haddad-mip6-cga-omipv6] protocol
specifies a new route optimization (RO) to solve the mobility
problem. Privacy extensions for OMIPv6 added anonymity and
unlinkability support to the OMIPv6-CGA protocol.
This document combines these previously mentioned documents and adds
multi-homing support. As such, it offers an efficient and secure
multi-homing and mobility support for MIPv6 using CGAs with privacy
support.
To provide multi-homing support based on [I-D.haddad-privacy-omipv6-
anonymity] requires to deal with the following aspects:
o Ability to inform the other peer about the peer address set
o Ability to inform the other peer about the preferred address
o Ability to test connectivity along a path and thereby to detect an
outage situation
o Ability to change the preferred address
o Ability to change the peer address set
Additionally, it is worth pointing out that a new care-of address
must be authorized prior to its usage. The procedure detailed in
OMIPv6 [I-D.haddad-mip6-cga-omipv6] and not repeated in this
document. Finally, the aspect of state indexing needs to be
considered. OMIPv6 selects the Binding Cache Entry (BCE) based on
the Home Address. The privacy extensions defined for OMIPv6 modify
this state selection approach and use a specially generated "Sequence
Value" (SQV). Since this document builds on top of the privacy
extensions for OMIPv6 SQV state indexing approach is reused.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Terms, such as peer, peer address set, path or preferred address, are
reused from MOBIKE [I-D.ietf-mobike-design]. Terminology related to
OMIPv6 [I-D.haddad-mip6-cga-omipv6] and its privacy extension
[I-D.haddad-privacy-omipv6-anonymity] can be found in the respective
documents.
3. Assumptions
This document makes the following assumptions:
Tschofenig & Haddad Expires January 19, 2006 [Page 3]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
o The home agent (HA) is supporting multiple care of addresses since
otherwise "Dynamic Home Agent Address Discovery" extensions, as
proposed in[I-D.wakikawa-mobileip-multiplecoa] are needed, to
query HAs for their capabilities regarding this option.
o Implicitly selecting the preferred address by using the
information from IP headers is sufficient. In contrast,
[I-D.wakikawa-mobileip-multiplecoa] uses an explicit signaling
mechanism based on flag in the binding update.
o Extension to the "Alternate Care-of address" field in the Binding
Update message to the CN and the HA. [I-D.wakikawa-mobileip-
multiplecoa] states that registering multiple CoAs to single HA is
prohibited:
* "However, according to Section 11.5.3 of the Mobile IPv6
specification, a mobile node is not allowed to register
multiple care-of addresses bound to a single home address."
* Section 11.5.3 of the Mobile IPv6 RFC does not state this
restriction explicitly.
o The entire document that OMIPv6 [I-D.haddad-mip6-cga-omipv6] and
its privacy extension [I-D.haddad-privacy-omipv6-anonymity] is
used.
4. Strawman Protocol Proposal
This document requires the following protocol processing:
Ability to inform the other peer about the peer address set:
The MN indicates support for multihoming in the Binding Update
with the Alternate Care-of Address extension. This payload also
indicates the available addresses.
Ability to inform the other peer about the preferred address:
The source and the destination address of a packet directly sent
to the CN is the preferred address pair.
Ability to test connectivity:
Procedures for path testing need further study. This procedure
ensures that a currently used path stopped working. [Editor's
Note: Some words about congestion control for concurrent path
tests are needed.]
Ability to change the preferred address:
The source and the destination address of a packet directly sent
to the CN is the preferred address pair. As a policy the MN
thereby decides about the preferred address pair being used. This
allows the protocol to work if stateful packet filtering firewalls
Tschofenig & Haddad Expires January 19, 2006 [Page 4]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
are deployed in IPv6 networks.
Ability to change the peer address set:
The mobile node can change its peer address set at any time by
sending a new Binding Update with a modified list of addresses in
the Care-of Address payload.
[Editor's Note: Detailed protocol processing rules for the MN and the
CN will be described in a future version of the document.]
5. Packet Format
This document defines an extension for the alternate care-of address
extension to carry multiple care-of address values.
5.1 Alternate Care-of Address extension
This extensions is used to carry multiple care-of addresses of the
mobile node. Normally, the "Alternate Care-of Address" field can
only carry a single IPv6 address. The number of CoAs can be
calculated by dividing the number of bytes indicated by "Option
Length" with 16. The field should be inserted in any Binding Update
message sent by the mobile node in case a mobile node wants to convey
more than one care-of address. The data structure transmits all
care-of addresses at once and the preferred address is implicitly
selected by the source/destination pair of the data packet it is
encapsulated. For any changes, adding or deleting addresses a new
set of addresses will be transmitted.
The format of the option is defined as shown in Figure 1:
Tschofenig & Haddad Expires January 19, 2006 [Page 5]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. Option Data .
. (Set of care-off addresses) .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
<To Be Assigned By IANA>. (ADDRESS_LIST)
Option Length
Length of the option.
(Length/16 indicates the number of stored IPv6 addresses)
Option Data
This field contains the mobile node's care-of addresses
it wishes to convey to Cn/HA.
Figure 1: Alternate Care-of Address Payload Format
As an alternative the extensions proposed in [I-D.wakikawa-mobileip-
multiplecoa] could be used. This proposal is based on serial
transmission of multiple CoAs and explicit signaling of preferred CoA
by means of a primary flag in the Binding-Update.
For identification and selection of registered bindings, a Binding
Unique Identification number (BID) is used.
A BID is selected by the MN for each CoA. Together with the HoA it
is used as a selector for Binding Cache Entries.
6. Example
This section shows a few example message flows. The first exchange
shows the usage of multiple CoAs as part of the OMIPv6 draft:
Tschofenig & Haddad Expires January 19, 2006 [Page 6]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
1. MN to CN (via HA): Pre Binding Update
2a. CN to MN (via HA): Pre Binding Acknowledgement
2b. CN to MN (directly): Pre Binding Test
3. MN to CN (directly): Binding Update + CoA set + ESN + CGA Key
+ SIG + BAD
4. CN to MN (directly): Binding Acknowledgment + ESN + SKey + BAD
5a. CN to MN (via HA): Home Test remaining CoA (HoT)
5b. CN to MN (directly): Care-of Test remaining CoA (CoT)
The message exchanges shown in (1), (2a) and (2b) establishes the
binding cache for the preferred address. The preferred address is
chosen implicitly by learning the source address of the MN from the
IPv6 header.
Then, in step (3) the Binding Update is performed, which transmits
all remaining Care-of Addresses _at once_ ('CoA set' in the list) by
using the extended version of the "Alternate Care-of Address" object
defined in Section 5.
Later, steps (5a) and (5b) are repeated for all CoAs except the
preferred one. The decision when performing the address test is a
matter of local policy.
Subsequent movement will then require the following message exchange
to take place.
6. MN to CN (directly): Care-of Test Init [+ ESN + KeepFlow + BAD]
7. CN to MN (directly): Care-of Test
8. MN to CN (directly): Binding Update + new CoA set +
+ NI + ESN + BAD
9. CN to MN (directly): Binding Acknowledgment + ESN + BAD
10a.CN to MN (via HA): Home Test remaining CoA (HoT)
10b.CN to MN (directly): Care-of Test remaining CoA (CoT)
Like in the initial case, the new preferred address will first be
checked for return routability with steps (6) and (7). The Binding
Update (8), may then contain an updated set of Care-of Addresses,
which will again be acknowledged by a Binding Acknowledgment message
(9).
Finally, the remaining CoAs of the CoA set are checked for return
routablity, which is done by messages (10a) and (10b).
Graphically, the exchange between the involved parties can be shown
as follows:
Tschofenig & Haddad Expires January 19, 2006 [Page 7]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
Mobile node Home agent Correspondent Node
| Pre Binding Update | |
|------------------------->|------------------------->|
| | Pre Binding Ack. |
|<-------------------------|<-------------------------|
| Pre Binding Test |
|<----------------------------------------------------|
| Binding Update + Care-of address set |
|---------------------------------------------------->|
| Binding Acknowledgement (optional) |
|<----------------------------------------------------|
. .
. .
. .
| Return routability tests remaining CoAs |
|<----------------------------------------------------|
| | |
|<-------------------------|--------------------------|
. .
. .
. .
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| Care-of Test (CoT) |
|<----------------------------------------------------|
| Binding Update + new care-of address set |
|---------------------------------------------------->|
| Binding Acknowledgement (optional) |
|<----------------------------------------------------|
. .
. .
. .
| Return routability tests remaining CoAs |
|<----------------------------------------------------|
| | |
|<-------------------------|--------------------------|
. .
. .
. .
As a comparison the mechanisms proposed in [I-D.wakikawa-mobileip-
multiplecoa] would require the following protocol exchange to the
place.
Tschofenig & Haddad Expires January 19, 2006 [Page 8]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
1a. MN to CN (via HA): Home Test Init (HoTI)
1b. MN to CN (directly): Care-of Test Init (CoTI)
2a. CN to MN (via HA): Home Test (HoT)
2b. CN to MN (directly): Care-of Test (CoT)
3. MN to CN (directly): Binding Update
4. CN to MN (directly): Binding Acknowledgment
5. MN to CN (directly): Registration of remaining CoA
Step (5) is repeated for all CoA except the preferred one.
The flow shown by the list above and the figure below is an extension
of the one given in the Mobile IPv6 [RFC3775]. Unlike the OMIPv6
draft example, this message flow is based on two initial MN to CN
messages (1a), (1b) for performing a return routability check. After
receiving, the CN sends two answers back to the MN, one directly and
one through the HA. (2a), (2b)
If the return routability check has succeeded, the MN sends a Binding
Update message (3), which is acknowledged by an Binding
Acknowledgement message from the CN (4), in case the MN signaled the
request by setting the 'A' flag in the Binding Update.
The first Binding Update message also conveys the "Primary Care-of
Address". Furthermore, the "Primary CoA" is marked with the 'B' flag
to indicate that multiple CoA will be used by the MN. Afterwards,
the MN sends all remaining CoA serially (5) to the CN, with a
separate message.
Mobile node Home agent Correspondent Node
| Home Test Init (HoTI) | |
|------------------------->|------------------------->|
| Care-of Test Init (CoTI) |
|---------------------------------------------------->|
| | Home Test (HoT) |
|<-------------------------|<-------------------------|
| Care-of Test (CoT) |
|<----------------------------------------------------|
| Binding Update |
|---------------------------------------------------->|
| Binding Acknowledgement (optional) |
|<----------------------------------------------------|
. .
. .
. .
| Registration of remaining CoA |
|---------------------------------------------------->|
. .
. .
Tschofenig & Haddad Expires January 19, 2006 [Page 9]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
. .
7. Security Considerations
The security properties of the extension defined in this document are
based on the OMIPv6-CGA [I-D.haddad-mip6-cga-omipv6] and subsequently
on the security of CGAs (see [I-D.ietf-send-cga]). Privacy related
aspects are discussed in [I-D.haddad-momipriv-problem-statement] and
in [I-D.haddad-privacy-omipv6-anonymity] and applicable to this
document. Mobility specific threats, such as traffic redirecting and
hijacking, third-party flooding and blackholing, are addressed by the
base OMIPv6-CGA proposal.
8. IANA Considerations
This document does not require actions by IANA.
9. Contributors
We would like to thank Franz Muenz for his contributions to this
draft.
10. Open Issues
The aspect of multiple HoA/HAs is not addressed in this document.
Registration of multiple CoA will provide benefits for the MN in a
sending case. However, the CN will still have only one HoA it may
choose from. For achieving goals like load balancing in both
directions, i.e., spreading work load over several interfaces, a
correspondent node would benefit from more than one HoA.
Another scenario which requires a change in the HoA is the battery
consumption. In fact, a user may be interested for example, to
switch off its 802.xx backup interface, i.e., HoA1, and switch on its
CDMA2000 backup interface, i.e., HoA2, while keeping the RO mode
running on WLAN interface. Of course it will always be possible to
update the HA1 with the HoA2 (as a CoA). However, applying OMIPv6
Anonymity design in such scenario can provide flexibility to do
changes on both sides: the RO interface and eventually backup
interfaces.
11. References
11.1 Normative References
[I-D.haddad-mip6-cga-omipv6]
Haddad, W., "Applying Cryptographically Generated
Tschofenig & Haddad Expires January 19, 2006 [Page 10]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
Addresses to Optimize MIPv6 (CGA-OMIPv6)",
draft-haddad-mip6-cga-omipv6-04 (work in progress),
May 2005.
[I-D.haddad-privacy-omipv6-anonymity]
Haddad, W., "Anonymity and Unlinkability Extension for
CGA-OMIPv6", draft-haddad-privacy-omipv6-anonymity-00
(work in progress), June 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
11.2 Informative References
[I-D.haddad-momipriv-problem-statement]
Haddad, W., "Privacy for Mobile and Multi-homed Nodes:
MoMiPriv Problem Statement",
draft-haddad-momipriv-problem-statement-01 (work in
progress), February 2005.
[I-D.ietf-mobike-design]
Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
protocol", draft-ietf-mobike-design-02 (work in progress),
February 2005.
[I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-01 (work in
progress), July 2005.
[I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.
[I-D.wakikawa-mobileip-multiplecoa]
Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Tschofenig & Haddad Expires January 19, 2006 [Page 11]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Wassim Haddad
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal, Quebec H4P 2N2
Canada
Phone: +1 514 345 7900 (#2334)
Email: Wassim.Haddad@ericsson.com
Tschofenig & Haddad Expires January 19, 2006 [Page 12]
Internet-Draft OMIPv6 Multi-Homing and Privacy July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig & Haddad Expires January 19, 2006 [Page 13]
