Network Working Group F. Dupont
Internet-Draft ISC
Intended status: Experimental J-M. Combes
Expires: May 16, 2008 Orange Labs/France Telecom R&D
November 13, 2007
Care-of Address Test for MIPv6 using a State Cookie
draft-dupont-mipv6-rrcookie-05.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 May 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a procedure which performs a "care-of address
test" using a state cookie for routing optimization in Mobile IPv6
not protected by the routing routability procedure, i.e., protected
by some alternative mechanisms like pre-shared secret or pre-
established IPsec security associations.
Dupont & Combes Expires May 16, 2008 [Page 1]
Internet-Draft CoA Test Cookie November 2007
1. Introduction
The Mobile IPv6 specifications [RFC3775] defines a default protection
for routing optimization, the routing routability procedure, which
includes an explicit "care-of address test". Alternative protection
mechanisms like pre-shared secret [RFC4449] or pre-established IPsec
security associations [CNIPsec] are more efficient and secure but
require in some cases a care-of address test to avoid a "3rd party
bombing" vulnerability.
This document proposes a care-of address test procedure at the
initiative of the correspondent node using a state cookie as in SCTP
[RFC4960] or IKEv2 [RFC4306].
2. Keywords
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].
3. A signaling extension for a care-of address test using a state
cookie
3.1. Applicability
The care-of address test procedure defined by this document MAY be
used in order to check whether the mobile node can really receive
packets sent to the care-of address of a new binding update. It
SHOULD NOT be used for entry deletion, i.e., when the care-of address
is the home address. It MUST be used for real alternate care-of
address, i.e., when the address carried by an alternate care-of
address option is not the source address of the IP header nor the
home address of the mobile node (following the recommendation of
[bombing]).
3.2. Protocol
The procedure is based on the state cookie idea of SCTP [RFC4960]
which can be found again in IKEv2 [RFC4306]. The binding update is
in a first time (1) rejected by a binding acknowledgment with a
transient error or a new dedicated status, and a cookie option sent
to the tested care-of address. Upon the reception (2) of this
binding acknowledgment, the mobile node retransmits (3) the binding
update with the exact received cookie placed in a cookie option.
When the correspondent node receives (4) the augmented binding
update, it can check by recomputing the cookie and comparing it to
Dupont & Combes Expires May 16, 2008 [Page 2]
Internet-Draft CoA Test Cookie November 2007
the cookie option data that the binding update is from the same
mobile node and for the same care-of address (so it can infer the
mobile node is reachable at this care-of address, i.e., a "care-of
address test" has been successfully performed).
The cookie MUST reflect the mobile node identity or the binding cache
entry or an equivalent, and MUST reflect the tested care-of address.
It MUST NOT be easy to infer by the mobile node, including with the
knowledge of previous cookies from the same node.
The last point is what to do waiting the retransmitted and augmented
binding update. Possibilities are:
- apply the binding update with the new care-of address. It defeats
the purpose of the care-of address test so it SHOULD NOT be done,
and it MUST NOT be done for a real alternate care-of address.
- keep the previous care-of address. As it is not possible to know
whether the previous care-of address is still usable, i.e.,
whether the mobile node is still reachable at this previous
care-of address, the default policy SHOULD NOT be to keep the
previous care-of address. The correspondent node MAY keep the
previous care-of address in special cases where this is known to
be the best solution.
- temporarily disable the binding cache entry, i.e., by using the
home address for communication to the mobile node until another
binding update is received. This SHOULD be the default policy.
3.3. Mobile Node Requirement
There is only one requirement for mobile nodes: a mobile node MUST
include in retries a copy of the cookie option carried by a binding
acknowledgment signaling a transient error (examples of such a
transient error is of course the new status or a sequence number out
of window).
3.4. Cookie Generation Example
This method assumes a global secret key is available and uses in
sequence:
- a 16 bit timestamp of when the cookie is created
- the tested care-of address
- the truncated HMAC [RFC2104], keyed by a secret key, of the
preceding two fields, the home address and the correspondent
address.
The secret key SHOULD be random or pseudo-random and SHOULD be
changed reasonably frequently. The timestamp MAY be used to
determine which key was used. The HMAC has to be truncated in order
to keep the cookie option length less than the maximum, the higher 96
bits of the HMAC should be enough.
Dupont & Combes Expires May 16, 2008 [Page 3]
Internet-Draft CoA Test Cookie November 2007
4. Acknowledgments
This document was extracted from [CNIPsec] because what it provides
is needed by any alternative to the return routability procedure
which has no built-in care-of address test.
5. Security Considerations
Without a test of the care-of address or an other way to trust it,
the care-of address presented by the mobile node can be a fake one
and offers a 3rd party bombing attack.
Binding updates and acknowledgments are validated using an
alternative protection mechanisms so they can't be injected by third
parties. The cookie sub-option is small enough to make this
procedure a poor candidate for a third party bombing mechanism.
6. IANA Considerations
This document requires:
- a new status for binding acknowledgment.
- a new option for mobility messages used in binding update and
acknowledgment messages.
7. References
7.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
7.2. Informative References
[CNIPsec] Dupont, F. and J-M. Combes, "Using IPsec between Mobile
and Correspondent IPv6 Nodes",
draft-ietf-mip6-cn-ipsec-06.txt (work in progress),
November 2007.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Dupont & Combes Expires May 16, 2008 [Page 4]
Internet-Draft CoA Test Cookie November 2007
Protocol", RFC 4306, December 2005.
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
Using a Static Shared Key", RFC 4449, June 2006.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[bombing] Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-05.txt (work in
progress), January 2007.
Authors' Addresses
Francis Dupont
ISC
Email: Francis.Dupont@fdupont.fr
Jean-Michel Combes
Orange Labs/France Telecom R&D
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Email: jeanmichel.combes@gmail.com
Dupont & Combes Expires May 16, 2008 [Page 5]
Internet-Draft CoA Test Cookie November 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).
Dupont & Combes Expires May 16, 2008 [Page 6]