Internet Engineering Task Force S. Decugis
Internet-Draft University of Tokyo
Intended status: Informational December 19, 2007
Expires: June 21, 2008
Key Management Mobility Capability (K) flag in Mobile IPv6 BU/BA
messages.
draft-sdecugis-mextkbitissues-00
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.
This document may not be modified, and derivative works of it may not
be created.
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 June 21, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Mobile IPv6 specification (RFC 3775) introduces a flag called "Key
Management Mobility Capability (K)" to use during the home
registration procedure (BU/BA exchange.) This document describes the
sequences of events that occur when this flag is not used by the
implementation. It also highlights the requirements that this flag
Decugis Expires June 21, 2008 [Page 1]
Internet-Draft Use of the (K) flag December 2007
puts on the interface between the MIPv6 entity and the IKE entity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Dynamic keying . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scenario 1: HA updates its endpoints (K=1), MN does
not (K=0). . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scenario 2: MN updates its endpoints(K=1), HA does not
(K=0). . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Decugis Expires June 21, 2008 [Page 2]
Internet-Draft Use of the (K) flag December 2007
1. Introduction
This introduction presents briefly the Mobile IPv6 dynamic keying,
and the exact meaning of the 'K' flag in BU/BA messages. Previous
knowledge of the Mobile IPv6 RFC 3775 [RFC3775], IPsec RFC 4301
[RFC4301], and IKEv2 RFC 4306 [RFC4306] RFC 4877 [RFC4877] RFCs is
highly recommended.
1.1. Mobile IPv6
Mobile IPv6 provides the ability for a node (called "Mobile Node",
MN) to be reachable at a permanent IPv6 address (its "Home Address",
HoA) while its point of attachment to the network is changing (the
temporary IPv6 address is called the "Care-of Address", CoA). One of
the routers serving the prefix of the HoA has a special role in the
mobility (this router is called the "Home Agent", HA.) Basically,
the MN registers its CoA to its HA, then the traffic directed to the
HoA is tunneled to the MN at its CoA. The correspondents can always
use the HoA to reach the MN.
1.2. Dynamic keying
Mobile IPv6 also makes mandatory the use of IPsec to protect the
messages (Binding Update, Binding Acknowledgement -- BU / BA)
involved during the MN's registration to its HA. Dynamic keying
represents the situation where a Key Management Protocol (such as IKE
or IKEv2) is used for negotiating the Security Association ("SA")
pair that will protect the BU/BA exchange (and optionnally other
messages). We can distinguish two steps in the KMP exchanges.
First, the peers negociate a secured channel ("IKE_SA"), based on
some trust mechanism (shared key, certificates, ...). Then, using
this secured channel, the peers can negociate the SA parameters for
protecting the BU/BA and optionnally other traffic. Since the BU/BA
exchange has not yet been completed when the SA are negociated, the
HoA cannot be used, and therefore the IKE_SA is negociated using the
CoA on the MN side. The child SA (the IPsec SA that protects the
BU/BA) is established between the HoA and the HA.
1.3. Movement
When the MN changes its CoA, the IPsec rules are updated to reflect
this change. For the transport-mode SA, there is no update needed
since the SA are established between the HoA and the HA. The tunnel-
mode SA and SP entries must be updated. The IKE_SA (used only to
protect IKE messages) endpoints may or may not be updated. The "K
flag" as discussed in this document is meant to represent the ability
of the peer to update the IKE_SA endpoints.
Decugis Expires June 21, 2008 [Page 3]
Internet-Draft Use of the (K) flag December 2007
1.4. Requirements Language
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 RFC 2119 [RFC2119].
2. Problem statement
It has already been proved that if both peers (MN and HA) behave in
the same way with regards to updating their IKE_SA endpoints or not,
then the sequence of signaling messages on movements results in
smooth operation.
This document will consider the situation where the peers behave
differently (one peer updates the IKE_SA endpoint, the other does
not.) The purpose is to highlight the value of the information
negociated through the (K) flag.
The initial state for both scenario is as follow:
MN is on a Foreign Link 1 (with CoA1) and registered to its HA.
We have the following links:
* IKE_SA established between CoA1 and HA
* SA1 (transport) between HoA and HA.
* SA2 (tunnel) between CoA1 and HA.
Then MN moves to Foreign Link 2 with CoA2.
2.1. Scenario 1: HA updates its endpoints (K=1), MN does not (K=0).
Step 1: The BU message is sent using SA1.
* SA2 is updated on the MN to CoA2.
Step 2: The HA receives the BU.
* It updates its IKE_SA remote endpoint
* It updates its SA2 remote endpoint.
* It sends the BA using SA1.
Now, we have two possibilities concerning the next IKE message:
Decugis Expires June 21, 2008 [Page 4]
Internet-Draft Use of the (K) flag December 2007
1. The MN needs to send an IKE message to the HA.
In this case, since the IKE_SA source address is not valid
anymore, we have to establish a new IKE_SA using the CoA2
address. This is the same behavior as case K=0 for both hosts.
Instead of establishing a new IKE_SA, the MN may choose to use
another available address as source address to send the IKE
message. This must be done with care, since the HoA must not be
used. In that case it is the same as case K=1 for both hosts.
2. The HA needs to send an IKE message to the MN.
In this case, the MN receives the message. It may choose to
update its IKE_SA local endpoint according to the dst address in
the message, in which case the exchange will succeed. It may
also choose to discard the message silently. In that case, the
HA will end up in being unable to negociate the SA and therefore
mark the IKE_SA (and all its CHILD_SA in IKEv2) as dead.
Negotiation of a new IKE_SA will happen only when a new ACQUIRE
message occurs.
Note that the second case is less likely to happen than the first,
since the MN is always the initiator of first IKE exchanges and
shorter lifetime values should be used for SA on the MN.
2.2. Scenario 2: MN updates its endpoints(K=1), HA does not (K=0).
Step 1: The BU message is sent using SA1.
* SA2 is updated on the MN to CoA2.
* IKE_SA is updated on the MN to CoA2.
Step 2: The HA receives the BU.
* SA2 is updated on the HA.
Then, again, we have two possibilities concerning the next IKE
message:
1. If MN wants to send an IKE message to HA.
HA receives a message from a new unknown address, with a valid
SPI identifier. Implementation may choose to discard silently
the message (to protect against DoS attacks for example). In
this case, the MN receives no answer and invalidates the IKE_SA
and the dependent SA. New negotiation will have to occur later,
which is time-consuming. During this timeframe, upper-layer flow
is interrupted. Implementation may also choose to accept the
message from the unknown IP address. In that case, the reply
will be sent to the new address, and it is equivalent as if the
Decugis Expires June 21, 2008 [Page 5]
Internet-Draft Use of the (K) flag December 2007
HA had updated the IKE_SA endpoints.
2. If HA wants to send an IKE message to MN.
It sends the message to the wrong address (CoA1). It results in
the IKE_SA (and CHILD_SAs) being invalidated after the timeout
(and retries, which may last for some minutes). This situation
will prevent the HA from being able to forward packets to the MN
and may be complicated to resolve (will need to wait for MN to
detect dead peer and re-establish a new IKE_SA). This will
result in an even bigger interruption in upper-layer flow.
3. Conclusion
Here is a summary of the several possibilities in dynamic keying
after a movement.
o If both MN and HA have the capability of updating the IKE session
endpoints, then there is no need to re-create a session after
movement and we have no additionnal interuption in the upper-layer
flow, but the handover time.
o If both peers do not have this ability, then next time an IKE
message needs to be exchanged, it will results in creating a new
IKE session. In the usual case, we do not need to wait for an IKE
timeout, since the MN can not use the old address anymore.
o If one peer updates the IKE session endpoint and the other does
not, it results in a bad situation where we have to wait for IKE
timeout (several minutes) before re-establishing a clean IKE
session. Upper-layer traffic may be interrupted during this
delay.
To ensure smooth operation, when the (K) flag negotiation after BU/BA
exchange has shown that the remote peer does not support the IKE
session movement, the local host MUST NOT update its IKE session
endpoints after a movement.
We can shorten the delay by deleting the broken IKE_SA after the
movement occurs (after BA has been emitted and received). An
implementation SHOULD require this deletion when the remote peer does
not support the IKE_SA movement. This would force next message to
trigger an ACQUIRE and a new IKE session to be established.
Note that if the support for migrating the IKE session is mandatory,
as is the support for migrating the tunnel-mode SA, then is
simplifies the problem and removes the need for (K) flag.
Decugis Expires June 21, 2008 [Page 6]
Internet-Draft Use of the (K) flag December 2007
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
This is not relevant for this draft.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-08 (work in
progress), October 2007.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
Decugis Expires June 21, 2008 [Page 7]
Internet-Draft Use of the (K) flag December 2007
Author's Address
Sebastien Decugis
University of Tokyo
Keio University Murai Lab., 144-8 Ogura, Saiwai-ku
Kawasaki, Kanagawa 212-0054
JP
Phone: +81 44 580 1600
Email: sdecugis@hongo.wide.ad.jp
Decugis Expires June 21, 2008 [Page 8]
Internet-Draft Use of the (K) flag December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Decugis Expires June 21, 2008 [Page 9]