MIP6 Working Group F. Dupont
Internet-Draft CELAR
Expires: January 27, 2008 J-M. Combes
Orange Labs/France Telecom R&D
July 26, 2007
Using IPsec between Mobile and Correspondent IPv6 Nodes
draft-ietf-mip6-cn-ipsec-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 January 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Mobile IPv6 uses IPsec to protect signaling between the Mobile Node
and the Home Agent. This document defines how IPsec can be used
between the Mobile Node and Correspondent Nodes for Home Address
Option validation (aka. triangular routing) and protection of
mobility signaling for Route Optimization. The configuration details
for IPsec and IKE are also provided.
Dupont & Combes Expires January 27, 2008 [Page 1]
Internet-Draft Using IPsec between MN and CN July 2007
1. Introduction
Mobile IPv6 documents [RFC3775][RFC3776][RFC4877] specifies IPsec
[RFC4301] for the protection of the signaling between the Mobile Node
(MN) and its Home Agent (HA), and the return routability procedure
between the Mobile Node and its Correspondent Nodes (CN) for Route
Optimization. This document defines an alternative mechanism based
on strong authentication and IPsec.
This document specifies which IPsec configurations can be useful in a
Mobile IPv6 context and how they can validate Home Address Options
(enabling triangular routing) and protect mobility signaling
(enabling Route Optimization). It gives detailed IKE
[RFC2409][RFC4306] configuration guidelines for common cases.
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].
IKE terminology is copied from IKEv2 [RFC4306].
2. Applicability
The purpose of this document is not to replace the [RFC3775] return
routability procedure by the use of IPsec/IKE. It is unrealistic to
expect credentials to be available today for strong authentication
between any pair of Internet nodes.
The idea is to enable the use of the superior security provided by
IPsec when it is already in use (i.e., comes at no extra cost), when
obstacles (i.e., authentication) to its use no more stand in the way,
or simply when it can be considered as highly desirable.
This mechanism should only be turned on by explicit configuration
between specific peers. It does not support automatic capability
negociation at this time.
3. IPsec in a Mobile IPv6 context
This document considers only suitable IPsec Security Associations,
i.e., anything which does not fulfill the following requirements is
out of scope:
- IPsec Security Association pairs MUST be between the Mobile Node
and one of its Correspondent Nodes.
Dupont & Combes Expires January 27, 2008 [Page 2]
Internet-Draft Using IPsec between MN and CN July 2007
- origin authentication, payload integrity and anti-replay services
MUST be selected.
- the Traffic Selectors MUST match exclusively the Home Address of
the Mobile Node and an address of the Correspondent Node (the
address used for communication between peers).
- the transport mode MUST be used.
- for Route Optimization, the Mobility Header "upper protocol" with
at least Binding Update (BU, from the MN) and Binding
Acknowledgment (BA, from the CN) message types MUST be accepted by
the Traffic Selectors.
The purpose of the first three requirements is to allow to use IPsec
as a proof of origin.
4. Home Address Option validation
This document amends the Mobile IPv6 [RFC3775] section 9.3.1 by
adding a second way (other than Binding Cache Entry check) to provide
Home Address Option validation.
When a packet carrying a Home Address Option is protected by a
suitable IPsec Security Association, the Home Address Option SHOULD
be considered valid.
A way to implement this is to mark the Home Address Option as "to be
validated" when it is processed. When the upper protocol is reached,
in order either:
- an IPsec header was processed according to [RFC4301] section 5.2
with a suitable IPsec Security Association, or
- a Binding Cache Entry check is successfully performed, or
- the packet contains a Binding Update, or
- the packet MUST be dropped.
By just setting up an IPsec SA with the CN, the MN is able to send
packets directly to the CN, i.e., triangular routing is enabled. The
CN does the Home Address Option validation by successful IPsec
processing of the packet. The Care-of Address in the source address
field of the IPv6 header is not used by IPsec at all as the IPsec
policy checks happen against the Home Address. The CN continues to
send the packets via the home network until a Binding Update is
processed.
5. Route Optimization
A suitable IPsec Security Association can protect Binding Updates and
Acknowledgments. In Binding Updates the new requirements are:
Dupont & Combes Expires January 27, 2008 [Page 3]
Internet-Draft Using IPsec between MN and CN July 2007
- Nonce Indices and Binding Authorization Data options SHOULD NOT be
sent by the Mobile Node and MUST be ignored by the Correspondent
Node.
- when an Alternate Care-of Address option is present, the alternate
Care-of Address MUST match the source address in the IP header or
the Home Address itself. Any Binding Update which does not
fulfill this requirement MUST be rejected.
In Binding Acknowledgments the new requirement is:
- Binding Authorization Data option SHOULD NOT be sent by the
Correspondent Node and MUST be ignored by the Mobile Node.
The use of the K (Key Management Mobility Capability) bit with
Correspondent Nodes is not defined. This bit is always set to zero
on sending a Binding Update or Binding Acknowledgment, and ignored on
receipt.
Note that a relatively long lifetime compatible with the IPsec policy
(i.e., by default up to the IPsec Security Association lifetime) MAY
be used with correspondent registrations, in contrast to the short
lifetime required by standard RFC 3775 mechanisms.
6. IKE configurations
This document considers only IKE where it is used for mobility
purpose. Peer addresses (addresses IKE runs over) are the addresses
seen at the transport or application layer, i.e., when the mobile
node uses its Home Address as the source of an IKE message, the
source address in the IP header can (should!) be a Care-of Address.
IKE MUST be run over the Home Address for the Mobile Node side when
the Home Address is usable. The case where the Home Address in
unusable is the subject of Appendix A.
The Home Address MAY be used in (phase 1) Mobile Node Identification
payloads. But this does not work well with dynamic Home Addresses,
so when it is acceptable by the Correspondent Node policy, name based
Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306]
section 3.5) payloads SHOULD be used by the Mobile Node.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Dupont & Combes Expires January 27, 2008 [Page 4]
Internet-Draft Using IPsec between MN and CN July 2007
8. Security Considerations
The Mobile IPv6 Route Optimization security design background
document [RFC4225] describes the unauthorized creation of Binding
Cache entries as the main avenue of attack. The authentication and
authorization of the Mobile Node provided by IPsec/IKE is a strong
defense against this threat.
Where the means to create suitable IPsec security associations exist,
this mechanism provides origin authentication, integrity protection,
replay protection and optional confidentiality services for the
Mobile IPv6 signalling. This improves the security over RFC 3775
route optimization, as the signaling packets in the latter are
vulnerable to man-in-the-middle attacks. The implications of this
vulnerability are that an attacker performing the man-in-the-middle
attack can have access to the security material needed to create
MIPv6 signalling instead of the Mobile Node. On the other hand, an
attacker in the same position is also capable of seeing all the
payload packets and could launch other attacks with similar
implications. For instance, such an attacker could see or modify the
contents of payload packets not protected with end-to-end security
and cause denial-of-service for others. However, the RFC 3775
mechanism allows such attacks in a short time window even after the
attacker is no longer in a position to see the payload packets
themselves. The mechanism defined in this specification removes this
vulnerability.
However, unlike RFC 3775 this mechanism should only be used when the
correspondent node has good reason to trust the actions of the mobile
node. In particular, the correspondent node needs to be certain that
the mobile node will not launch flooding attacks against a third
party as described in [RFC4225]. Without such trust the only
protection comes from the application of ingress filtering in the
network where the attacker resides. However, at the moment ingress
filtering has not been universally deployed. This mechanism is
vulnerable to flooding attacks as it does not verify the validity of
a claimed new care-of address. Note, however, the following:
- The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE
peer, which is supposed to be the subject of a minimal level of
trust.
- The attack can be easily traced back to the Mobile Node.
In order to avoid granting extra privileges by a side effect, the
application of this mechanism must not lead to allowing any new,
previously unauthorized traffic to flow between the peers beyond
mobility signaling with the Mobility Header (MH) protocol. The IPsec
peer policy MAY also restrict IPsec Security Associations to the
protection of Mobile IPv6 signaling, i.e., restrict the Traffic
Dupont & Combes Expires January 27, 2008 [Page 5]
Internet-Draft Using IPsec between MN and CN July 2007
Selectors to MH with at least Binding Update and Binding
Acknowledgment message types.
9. Acknowledgments
The authors would like to thank many people for believing in IPsec as
a right way to secure Mobile IPv6. Special thanks to Wassim Haddad
and Claude Castelluccia for keeping our attention to special cases
where Home Addresses are derived from public keys. Thanks to Mohan
Parthasarathy for the peer address clarification.
10. Possible enhancements
A number of potential enhancements of this method are possible,
including, for instance, various mechanisms for verification of
Care-of Addresses or use of addresses bound to keys. [RFC4651]
describes many proposals for the general Route Optimization problem.
[I-D.dupont-mipv6-rrcookie] is an alternate approach to testing
Care-of Addresses.
When the Home Address is bound to a public key, for instance when the
Home Address is a Cryptographically Generated Address [RFC3972],
[I-D.laganier-ike-ipv6-cga] describes an alternative approach to the
use of strong authentication.
11. Changes from the previous version
To be removed prior to publication as an RFC.
The security considerations and the possible enhancements sections
were rewritten.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
Dupont & Combes Expires January 27, 2008 [Page 6]
Internet-Draft Using IPsec between MN and CN July 2007
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., Ed., "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.
12.2. Informative References
[I-D.dupont-mipv6-rrcookie]
Dupont, F. and J-M. Combes, "Care-of Address Test for
MIPv6 using a State Cookie",
draft-dupont-mipv6-rrcookie-04.txt (work in progress),
January 2007.
[I-D.laganier-ike-ipv6-cga]
Laganier, J. and G. Montenegro, "Using IKE with IPv6
Cryptographically Generated Addresses",
draft-laganier-ike-ipv6-cga-02.txt (work in progress),
July 2007.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
February 2007.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007.
Dupont & Combes Expires January 27, 2008 [Page 7]
Internet-Draft Using IPsec between MN and CN July 2007
Appendix A. IKE running over a Care-of Address
In special circumstances where the Home Address can be unusable, as
when the Home Address is ORCHID [RFC4843] based and not routable, IKE
must be run over a Care-of Address but this has many known drawbacks:
- a Care-of Address can not be used for authentication nor
authorization.
- Security Associations do not survive handoffs.
- the establishment of transport mode IPsec Security Association
using the Home Address as the Mobile Node Traffic Selector raises
a policy / authorization issue as IKE runs over another address.
Authors' Addresses
Francis Dupont
CELAR
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 January 27, 2008 [Page 8]
Internet-Draft Using IPsec between MN and CN July 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 January 27, 2008 [Page 9]