draft-ietf-mobileip-mipv6-ha-ipsec-03.txt   draft-ietf-mobileip-mipv6-ha-ipsec-04.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: August 19, 2003 V. Devarapalli Expires: September 18, 2003 V. Devarapalli
Nokia Research Center Nokia Research Center
F. Dupont F. Dupont
ENST Bretagne ENST Bretagne
February 18, 2003 March 20, 2003
Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents Home Agents
draft-ietf-mobileip-mipv6-ha-ipsec-03.txt draft-ietf-mobileip-mipv6-ha-ipsec-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 19, 2003. This Internet-Draft will expire on September 18, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Mobile IPv6 uses IPsec to protect signaling between the home agent Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. Mobile IPv6 base document defines the main and the mobile node. Mobile IPv6 base document defines the main
requirements these nodes must follow. This document discusses these requirements these nodes must follow. This document discusses these
skipping to change at page 2, line 52 skipping to change at page 2, line 52
6.11 Prefix Advertisement Message to the Mobile Node . . . 33 6.11 Prefix Advertisement Message to the Mobile Node . . . 33
6.12 Prefix Advertisement Message from the Home Agent . . . 34 6.12 Prefix Advertisement Message from the Home Agent . . . 34
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 34 6.13 Payload Packet to the Home Agent . . . . . . . . . . . 34
6.14 Payload Packet from the Mobile Node . . . . . . . . . 34 6.14 Payload Packet from the Mobile Node . . . . . . . . . 34
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 34 6.15 Payload Packet to the Mobile Node . . . . . . . . . . 34
6.16 Payload Packet from the Home Agent . . . . . . . . . . 34 6.16 Payload Packet from the Home Agent . . . . . . . . . . 34
6.17 Establishing New Security Associations . . . . . . . . 34 6.17 Establishing New Security Associations . . . . . . . . 34
6.18 Rekeying Security Associations . . . . . . . . . . . . 35 6.18 Rekeying Security Associations . . . . . . . . . . . . 35
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 36 6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 36
7. Implementation Considerations . . . . . . . . . . . . . . . 38 7. Implementation Considerations . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . . 42 Normative References . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 Informative References . . . . . . . . . . . . . . . . . . . 43
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43
B. Changes from Previous Version . . . . . . . . . . . . . . . 44 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45 B. Changes from Previous Version . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46
1. Introduction 1. Introduction
This document illustrates the use of IPsec in securing control This document illustrates the use of IPsec in securing control
traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node
is always expected to be addressable at its home address, whether it is always expected to be addressable at its home address, whether it
is currently attached to its home link or is away from home. The is currently attached to its home link or is away from home. The
"home address" is an IP address assigned to the mobile node within "home address" is an IP address assigned to the mobile node within
its home subnet prefix on its home link. While a mobile node is at its home subnet prefix on its home link. While a mobile node is at
home, packets addressed to its home address are routed to the mobile home, packets addressed to its home address are routed to the mobile
skipping to change at page 8, line 20 skipping to change at page 8, line 20
home agent MUST support at least the following headers in the home agent MUST support at least the following headers in the
following order: following order:
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header ESP header
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address) Alternate Care-of Address option (care-of address)
Note that the Alternative Care-of Address option is used to ensure Note that the Alternate Care-of Address option is used to ensure that
that the care-of address is protected by ESP. The home agent the care-of address is protected by ESP. The home agent considers
considers the address within this option as the current care-of the address within this option as the current care-of address for the
address for the mobile node. mobile node.
The Binding Acknowledgements sent back to the mobile node when it is The Binding Acknowledgements sent back to the mobile node when it is
away from home MUST have at least the following headers in the away from home MUST support at least the following headers in the
following order: following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header ESP header
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
skipping to change at page 8, line 50 skipping to change at page 8, line 50
mobile node can use its home address as a source address. This mobile node can use its home address as a source address. This
typically happens for the de-registration Binding Update when the typically happens for the de-registration Binding Update when the
mobile is returning home. In this situation, the Binding Updates mobile is returning home. In this situation, the Binding Updates
MUST support at least the following headers in the following order: MUST support at least the following headers in the following order:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
ESP header ESP header
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address)
The Binding Acknowledgement messages sent to the home address MUST The Binding Acknowledgement messages sent to the home address MUST
support at least the following headers in the following order: support at least the following headers in the following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = home address) destination = home address)
ESP header ESP header
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
skipping to change at page 15, line 42 skipping to change at page 15, line 42
The following rules apply to mobile nodes: The following rules apply to mobile nodes:
o When ESP is used to protect Binding Updates, there is no o When ESP is used to protect Binding Updates, there is no
protection for the care-of address which appears in the IPv6 protection for the care-of address which appears in the IPv6
header outside the area protected by ESP. It is important for the header outside the area protected by ESP. It is important for the
home agent to verify that the care-of address has not been home agent to verify that the care-of address has not been
tampered. As a result, the attacker would have redirected the tampered. As a result, the attacker would have redirected the
mobile node's traffic to another address. In order to prevent mobile node's traffic to another address. In order to prevent
this, Mobile IPv6 implementations MUST use the Alternate Care-of this, Mobile IPv6 implementations MUST use the Alternate Care-of
Address mobility option in all Binding Updates sent to the home Address mobility option in registrations sent to the home agent.
agent. (Note that AH protects also the IPv6 header, and some (Note that AH protects also the IPv6 header, and some
implementations might avoid the option if they know AH is being implementations might avoid the option if they know AH is being
used.) used.)
o When IPsec is used to protect return routability signaling or o When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it payload packets, the mobile node MUST set the source address it
uses for the outgoing tunnel packets to the current primary uses for the outgoing tunnel packets to the current primary
care-of address. The mobile node starts to use a new primary care-of address. The mobile node starts to use a new primary
care-of address immediately after sending a Binding Update to the care-of address immediately after sending a Binding Update to the
home agent to register this new address. home agent to register this new address.
skipping to change at page 17, line 13 skipping to change at page 17, line 13
exchanges with the mobile node's home agent. exchanges with the mobile node's home agent.
o Conversely, the IPsec security associations with the mobile node's o Conversely, the IPsec security associations with the mobile node's
home agent MUST be requested from the key management protocol with home agent MUST be requested from the key management protocol with
the home address as the mobile node's address. the home address as the mobile node's address.
The security associations for protecting Binding Updates and The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints. transport mode and for specific IP addresses as endpoints.
Similarly, the security associations for protecting prefix Similarly, the security associations for protecting prefix
discovery are requested for the ICMPv6 protocol. Payload and discovery are requested for the ICMPv6 protocol. Security
return routability protection requests security associations for a associations for payload and return routability protection are
specific tunnel interface and either the payload protocol or the requested for a specific tunnel interface and either the payload
Mobility header protocol, in tunnel mode. In this case one protocol or the Mobility header protocol, in tunnel mode. In this
requested endpoint is an IP address and another one is a wildcard. case one requested endpoint is an IP address and another one is a
wildcard.
o If the mobile node has used IKE to establish security associations o If the mobile node has used IKE to establish security associations
with its home agent, it should follow the procedures discussed in with its home agent, it should follow the procedures discussed in
Section 11.7.1 and 11.7.3 of the base specification to determine Section 11.7.1 and 11.7.3 of the base specification to determine
whether the IKE endpoints can be moved or if rekeying is needed. whether the IKE endpoints can be moved or if rekeying is needed.
The following rules apply to home agents: The following rules apply to home agents:
o If the home agent has used IKE to establish security associations o If the home agent has used IKE to establish security associations
with the mobile node, it should follow the procedures discussed in with the mobile node, it should follow the procedures discussed in
skipping to change at page 40, line 5 skipping to change at page 40, line 5
against an access list. Where fragmentation occurs, the endpoints against an access list. Where fragmentation occurs, the endpoints
will not always be able to establish a security association. will not always be able to establish a security association.
Fortunately, typical Mobile IPv6 deployment uses short certificate Fortunately, typical Mobile IPv6 deployment uses short certificate
chains, as the mobile node is communicating directly with its home chains, as the mobile node is communicating directly with its home
network. Nevertheless, where the problem appears, one solution is to network. Nevertheless, where the problem appears, one solution is to
replace the firewalls or routers with equipment that can properly replace the firewalls or routers with equipment that can properly
support fragments. If this cannot be done, it may help to store the support fragments. If this cannot be done, it may help to store the
peer certificates locally, or to obtain them through other means. peer certificates locally, or to obtain them through other means.
8. Security Considerations 8. IANA Considerations
No IANA actions are necessary based on this document. IANA actions
for the Mobile IPv6 protocol itself have been covered in [8].
9. Security Considerations
The Mobile IPv6 base specification [8] requires strong security The Mobile IPv6 base specification [8] requires strong security
between the mobile node and the home agent. This memo discusses how between the mobile node and the home agent. This memo discusses how
that security can be arranged in practice, using IPsec. that security can be arranged in practice, using IPsec.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 44, line 10 skipping to change at page 45, line 10
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin The authors would like to thank Greg O'Shea, Michael Thomas, Kevin
Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, and Gabriel Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, and Gabriel
Montenegro for interesting discussions in this problem space. Montenegro for interesting discussions in this problem space.
Appendix B. Changes from Previous Version Appendix B. Changes from Previous Version
The following changes have been made to this document from version The following changes have been made to this document from version
02: 02:
o It is now better explained why the mobile node can change its o The wire format for de-registration when returning home has been
source address in security associations before such a change is updated. The Alternate Care-of Address option is no longer used
told to the home agent (tracked issue 249). in this situation (tracked issue 270).
o The support for protecting prefix discovery with IPsec has been
made mandatory, but use is still a SHOULD (tracked issue 249).
o Requirements for security association and policy configuration for o An IANA considerations section has been added (tracked issue 265).
new home addresses received through prefix discovery have been
specified (tracked issue 243).
o IPsec protocol and mode requirements have now been stated as o IPsec protocol and mode requirements have now been stated as
minimal requirements and no longer prevent the use of other minimal requirements and no longer prevent the use of other
protocols (AH) and modes (tracked issue 228). protocols (AH) and modes (tracked issue 228).
o The specification explicitly discourages the use of nested IPsec o Some editorial modifications have been performed.
encapsulation (tracked issue 219).
o The different types of requests for phase 2 security associations
have been explained in the requirements section. This relates to
using IKE for creating security associations for Binding Update
protection or other tasks (tracked issue 219).
o Many editorial modifications have been performed.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/