MIP6 Working Group F. Dupont
Internet-Draft Point6
Expires: December 29, 2005 J-M. Combes
France Telecom DR&D
June 27, 2005
Using IPsec between Mobile and Correspondent IPv6 Nodes
draft-ietf-mip6-cn-ipsec-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 December 29, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
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, including home
address option validation (aka. triangular routing), protection of
mobility signaling for routing optimization and suitable
configurations.
Dupont & Combes Expires December 29, 2005 [Page 1]
Internet-Draft Using IPsec between MN and CN June 2005
1. Introduction
Mobile IPv6 documents [RFC3775][RFC3776] specifies IPsec [RFC2401]
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 routing
optimization. But any stronger mechanism (i.e., more secure than the
return routability procedure) MAY be used, including of course IPsec
(cf. [RFC3775] Appendix 3 "New Authorization Methods").
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 routing optimization). It gives detailed IKE
[RFC2409][IKEv2] configuration guidelines for common cases.
This document uses the "MUST", "SHOULD", "MAY", ..., key words
according to [RFC2119]. IKE terminology is copied from IKEv2
[IKEv2].
2. 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.
- authentication, 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 routing optimization, the mobility header "upper protocol"
with at least binding update (BU) and acknowledgment (BA) message
type 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.
3. 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
Dupont & Combes Expires December 29, 2005 [Page 2]
Internet-Draft Using IPsec between MN and CN June 2005
be considered as validated.
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 [RFC2401] section 5.2.1
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.
Note this enables triangular routing from any unicast routable
care-of address, i.e., half optimization without any mobility
signaling.
4. Routing Optimization
A suitable IPsec security association can protect binding updates and
acknowledgments. In binding updates the new requirements are:
- the H (home registration) and K (key management mobility
capability) bits MUST be cleared.
- 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 and is not
checked using the state cookie mechanism [cookie], 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.
- as ESP can only protect the payload, an alternate care-of address
option MUST be used in conjunction with ESP (cf [RFC3775] section
11.7.1).
In binding acknowledgments the new requirements are:
- the K (key management mobility capability) bit MUST be cleared.
- Binding authorization data option SHOULD NOT be sent by the
correspondent node and MUST be ignored by the mobile node.
- "long" lifetime compatible with the IPsec policy (i.e., by default
up to the IPsec security association lifetime) MAY be granted.
As explained in [bombing], ingress filtering either is not used and
bombing attacks are possible without the "help" of any Mobile IPv6
mechanism, or is used and provides protection against fake care-of
addresses from a rogue mobile node. So the only constraint is to
accept real alternate care-of addresses only when they are
successfully checked using the state cookie mechanism.
This mechanism [cookie] MUST NOT be used when the new care-of address
Dupont & Combes Expires December 29, 2005 [Page 3]
Internet-Draft Using IPsec between MN and CN June 2005
is the home address, MUST be used when the alternate care-of address
is a real one, i.e., is not the same than the source address in the
IPv6 header nor the home address. It MAY be used in other cases but
in general in the context of this document the mobile node is enough
trusted to make this check not necessary or even not useful.
5. 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 layers, 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. In special circumstances where the home
address can be unusable, 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.
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, [IKEv2]
section 3.5) payloads SHOULD be used by the mobile node.
When the home address is bound to a public key, for instance when the
home address is a Cryptographically Generated Addresses [RFC3972],
the strong authentication MAY be replaced by an address ownership
proof. In this case the public key MAY be transported by IKE from
the mobile node to the correspondent node, for instance in a
Certificate payload of type 11 ([IKEv2] section 3.6). Auxiliary
parameters MAY be transported in an Identification payload of type
ID_KEY_ID...
The IKE peer policy MAY restrict IPsec security associations to the
protection of Mobile IPv6 signaling, i.e., restrict the traffic
selectors to the mobility header "upper protocol" with at least
binding update and acknowledgment message types. This SHOULD be the
default policy when authentication or authorization can be considered
as being weak, for instance when the previous paragraph is applied.
Dupont & Combes Expires December 29, 2005 [Page 4]
Internet-Draft Using IPsec between MN and CN June 2005
6. Security Considerations
IPsec is far more secure than the return routability procedure, thus
it should be used where it is applicable. So this document can
increase at least the overall security of Mobile IPv6. Note that
some operators can not propose Mobile IPv6 based services knowing
that the Mobile IPv6 security is based on assumptions.
Two points are worthy of special considerations:
- no care-of address test is required when ingress filtering can
reject fake care-of addresses from a rogue mobile node but a
correspondent node can use the return routability state cookie
procedure to get extra insurance as well as the support of real
alternate care-of addresses.
- in order to avoid granting any extra privilege by a side effect of
using IPsec, the peers (i.e., the mobile and correspondent nodes)
may restrict the traffic selectors to the protection of mobility
signaling only. This should be applied to any dubious cases,
including by default when security administration is known to be
too light.
7. 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 the Mobile IPv6 IETF working group for discussions about
the third party bombing issue, including for no convincing arguments
in favor of a requirement for the care-of address test in all cases.
No thanks to router vendors who do not support ingress filtering with
reasonable performance on some models, and to Internet service
provider managers who could enable ingress filtering but do not.
8. Changes from previous versions
The care-of address test annex was moved to its own document
[cookie].
Peer address clarification (thanks to Mohan Parthasarathy). Change
SHOULD/MAY to MUST/MUST for mobile node peer address.
9. References
Dupont & Combes Expires December 29, 2005 [Page 5]
Internet-Draft Using IPsec between MN and CN June 2005
9.1 Normative References
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17.txt (work in
progress), September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[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
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.
[cookie] Dupont, F. and J-M. Combes, "Care-of Address Test for
MIPv6 using a State Cookie",
draft-dupont-mipv6-rrcookie-01.txt (work in progress),
June 2005.
9.2 Informative References
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[bombing] Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-02.txt (work in
progress), June 2005.
Dupont & Combes Expires December 29, 2005 [Page 6]
Internet-Draft Using IPsec between MN and CN June 2005
Authors' Addresses
Francis Dupont
Point6
c/o GET/ENST Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Fax: +33 2 99 12 70 30
Email: Francis.Dupont@enst-bretagne.fr
Jean-Michel Combes
France Telecom DR&D
38/40 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Fax: +33 1 45 29 65 19
Email: jeanmichel.combes@francetelecom.com
Dupont & Combes Expires December 29, 2005 [Page 7]
Internet-Draft Using IPsec between MN and CN June 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.
Dupont & Combes Expires December 29, 2005 [Page 8]
