< draft-ietf-mip6-ikev2-ipsec-07.txt   draft-ietf-mip6-ikev2-ipsec-08.txt >
MIP6 Working Group V. Devarapalli MIP6 Working Group V. Devarapalli
Internet-Draft Azaire Networks Internet-Draft Azaire Networks
Updates: 3776 (if approved) F. Dupont Updates: 3776 (if approved) F. Dupont
Intended status: Standards Track CELAR Intended status: Standards Track CELAR
Expires: April 25, 2007 October 22, 2006 Expires: June 19, 2007 December 16, 2006
Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
draft-ietf-mip6-ikev2-ipsec-07.txt draft-ietf-mip6-ikev2-ipsec-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 April 25, 2007. This Internet-Draft will expire on June 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes Mobile IPv6 operation with the revised IPsec This document describes Mobile IPv6 operation with the revised IPsec
architecture and IKEv2. architecture and IKEv2.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 4 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 4
4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5 4.2. Policy Requirements . . . . . . . . . . . . . . . . . . . 5
4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7 4.3. IPsec Protocol Processing Requirements . . . . . . . . . . 7
4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 8 4.4. Dynamic Keying Requirements . . . . . . . . . . . . . . . 9
5. Selector Granularity Considerations . . . . . . . . . . . . . 9 5. Selector Granularity Considerations . . . . . . . . . . . . . 9
6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 10 6. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 11
6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 11 6.1. Binding Updates and Acknowledgements . . . . . . . . . . . 11
6.2. Return Routabililty Messages . . . . . . . . . . . . . . . 11 6.2. Return Routabililty Messages . . . . . . . . . . . . . . . 12
6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 12 6.3. Mobile Prefix Discovery Messages . . . . . . . . . . . . . 13
6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 13 6.4. Payload Packets . . . . . . . . . . . . . . . . . . . . . 14
7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 13 7. Dynamic Configuration . . . . . . . . . . . . . . . . . . . . 14
7.1. Security Policy Database Entries . . . . . . . . . . . . . 13 7.1. Peer Authorization Database Entries . . . . . . . . . . . 15
7.1.1. Binding Updates and Acknowledgements . . . . . . . . . 14 7.2. Security Policy Database Entries . . . . . . . . . . . . . 15
7.1.2. Return Routability Messages . . . . . . . . . . . . . 15 7.2.1. Binding Updates and Acknowledgements . . . . . . . . . 15
7.1.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 15 7.2.2. Return Routability Messages . . . . . . . . . . . . . 16
7.1.4. Payload Packets . . . . . . . . . . . . . . . . . . . 16 7.2.3. Mobile Prefix Discovery Messages . . . . . . . . . . . 17
7.2. Security Association negotiation using IKEv2 . . . . . . . 17 7.2.4. Payload Packets . . . . . . . . . . . . . . . . . . . 18
7.3. Movements and Dynamic Keying . . . . . . . . . . . . . . . 19 7.3. Security Association negotiation using IKEv2 . . . . . . . 18
8. The use of EAP authentication . . . . . . . . . . . . . . . . 20 7.4. Movements and Dynamic Keying . . . . . . . . . . . . . . . 20
9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 21 8. The use of EAP authentication . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Dynamic Home Address Configuration . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used
with Mobile IPv6 [2] to protect the signaling messages. It also with Mobile IPv6 [2] to protect the signaling messages. It also
illustrates examples of Security Policy Database and Security illustrates examples of Security Policy Database and Security
Association Database entries that can be used to protect Mobile IPv6 Association Database entries that can be used to protect Mobile IPv6
signaling messages. signaling messages.
The IPsec architecture has been revised in RFC 4301 [5]. Among the The IPsec architecture has been revised in RFC 4301 [5]. Among the
skipping to change at page 3, line 32 skipping to change at page 3, line 32
includes ICMP message type and code as selectors. This makes it includes ICMP message type and code as selectors. This makes it
possible to protect Mobile Prefix Discovery messages without applying possible to protect Mobile Prefix Discovery messages without applying
the same security associations to all ICMPv6 messages. the same security associations to all ICMPv6 messages.
This document discusses new requirements for the home agent and the This document discusses new requirements for the home agent and the
mobile node to use the revised IPsec architecture and IKEv2. mobile node to use the revised IPsec architecture and IKEv2.
Section 4 lists the requirements. Section 6 and Section 7 describe Section 4 lists the requirements. Section 6 and Section 7 describe
the required Security Policy Database (SPD) and Security Association the required Security Policy Database (SPD) and Security Association
Database (SAD) entries. Database (SAD) entries.
The Internet Key Exchange (IKE) has also been substantially revised The Internet Key Exchange (IKE) protocol has also been substantially
and simplified [4]. Section 7.2 of this document describes how IKEv2 revised and simplified [4]. Section 7.3 of this document describes
can be used to setup security associations for Mobile IPv6. how IKEv2 can be used to setup security associations for Mobile IPv6.
The use of EAP within IKEv2 is allowed to authenticate the mobile The use of EAP within IKEv2 is allowed to authenticate the mobile
node to the home agent. This is described in Section 8. A method node to the home agent. This is described in Section 8. A method
for dynamically configuring a home address from the home agent using for dynamically configuring a home address from the home agent using
the Configuration Payload in IKEv2 is described in Section 9. the Configuration Payload in IKEv2 is described in Section 9.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 42 skipping to change at page 4, line 42
very similar with the home address as the source address in the inner very similar with the home address as the source address in the inner
IP header. IP header.
The support for the above tunneled packet format is optional on the The support for the above tunneled packet format is optional on the
mobile node and the home agent. mobile node and the home agent.
4. Requirements 4. Requirements
This section describes mandatory rules and requirements for all This section describes mandatory rules and requirements for all
Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as Mobile IPv6 mobile nodes and home agents so that IPsec, with IKEv2 as
the key negotiation protocol, can be used to protect traffic between the key management protocol, can be used to protect traffic between
the mobile node and the home agent. Many of the requirements are the mobile node and the home agent. Many of the requirements are
repeated from RFC 3776 to make this document self-contained and repeated from RFC 3776 to make this document self-contained and
complete. complete.
4.1. General Requirements 4.1. General Requirements
o RFC 3775 states that manual configuration of IPsec security o RFC 3775 states that manual configuration of IPsec security
associations MUST be supported and automated key management MAY be associations MUST be supported and automated key management MAY be
supported. This document does not make any recommendations supported. This document does not make any recommendations
regarding the support of manual IPsec configuration and dynamic regarding the support of manual IPsec configuration and dynamic
skipping to change at page 5, line 49 skipping to change at page 5, line 49
The following requirements are related to the configuration of The following requirements are related to the configuration of
security policy database on the home agent and the mobile node. security policy database on the home agent and the mobile node.
o RFC 3776 required configuration of the security policies per o RFC 3776 required configuration of the security policies per
interface in order to be able to differentiate between mobility interface in order to be able to differentiate between mobility
header messages sent to the home agent and tunneled through the header messages sent to the home agent and tunneled through the
home agent to the correspondent node. Since the Mobility Header home agent to the correspondent node. Since the Mobility Header
message type is a selector, it is now easy to differentiate message type is a selector, it is now easy to differentiate
between HoTi and HoT messages from other mobility header messages. between HoTi and HoT messages from other mobility header messages.
Therefore per-interface configuration of security policies is not Therefore per-interface configuration of security policies is not
required. required for protecting mobility header messages. Note that
without per-interface security policies. payload packet protection
is limited to packets originating/terminating at the home address.
Traffic using link local address within the Mobile IP tunnel
cannot be provided IPsec protection without per-interface security
policies.
o The home agent MUST be able to prevent a mobile node from using o The home agent MUST be able to prevent a mobile node from using
its security association to send a Binding Update on behalf of its security association to send a Binding Update on behalf of
another mobile node. With manual IPsec configuration, the home another mobile node. With manual IPsec configuration, the home
agent MUST be able to verify that a security association was agent MUST be able to verify that a security association was
created for a particular home address. With dynamic keying, the created for a particular home address. With dynamic keying, the
home agent MUST be able to verify that the identity presented in home agent MUST be able to verify that the identity presented in
the IKE_AUTH exchange is allowed to create security associations the IKE_AUTH exchange is allowed to create security associations
for a particular home address. for a particular home address.
o The home agent MAY use the Peer Authorization Database (PAD) [5] o The home agent uses the Peer Authorization Database (PAD) [5] to
to store per-mobile node state. The PAD entry for a mobile node store per-mobile node state. More specifically the per-mobile
MAY contain a shared key, public key or a trust anchor to verify state stores information that is used to authenticate the mobile
the mobile node's certificate for authenticating the mobile node. node and the authorization information that ties the mobile node's
identity to the home address of the mobile node. This will allow
the home agent to prevent a mobile node from creating IPsec
security associations for another mobile node's home address. In
case of dynamic home address assignment, the home agent creates a
temporary PAD entry linking the authenticated peer identity and
the newly allocated home address.
o As required in the base specification [2], when a packet destined o As required in the base specification [2], when a packet destined
to the receiving node is matched against IPsec security policy or to the receiving node is matched against IPsec security policy or
selectors of a security association, an address appearing in a selectors of a security association, an address appearing in a
Home Address destination option is considered as the source Home Address destination option is considered as the source
address of the packet. address of the packet.
Note that the home address option appears before IPsec headers. Note that the home address option appears before IPsec headers.
Section 11.3.2 of the base specification describes one possible Section 11.3.2 of the base specification describes one possible
implementation approach for this: The IPsec policy operations can implementation approach for this: The IPsec policy operations can
skipping to change at page 6, line 47 skipping to change at page 7, line 9
or selectors of a security association. or selectors of a security association.
Similar implementation considerations apply to the Routing header Similar implementation considerations apply to the Routing header
processing as was described above for the Home Address destination processing as was described above for the Home Address destination
option. option.
o When the mobile node returns home and de-registers with the Home o When the mobile node returns home and de-registers with the Home
Agent, the tunnel between the home agent and the mobile node's Agent, the tunnel between the home agent and the mobile node's
care-of address is torn down. The security policy entries, which care-of address is torn down. The security policy entries, which
were used for protecting tunneled traffic between the mobile node were used for protecting tunneled traffic between the mobile node
and the home agent MUST be made inactive (for instance, by and the home agent SHOULD be made inactive (for instance, by
removing them and installing them back later through an API). The removing them and installing them back later through an API). The
corresponding security associations could be kept as they are or corresponding security associations could be kept as they are or
deleted depending on how they were created. If the security deleted depending on how they were created. If the security
associations were created dynamically using IKE, they are associations were created dynamically using IKE, they are
automatically deleted when they expire. If the security automatically deleted when they expire. If the security
associations were created through manual configuration, they MUST associations were created through manual configuration, they MUST
be retained and used later when the mobile node moves away from be retained and used later when the mobile node moves away from
home again. The security associations protecting Binding Updates home again. The security associations protecting Binding Updates
and Acknowledgements, and prefix discovery SHOULD NOT be deleted and Acknowledgements, and prefix discovery SHOULD NOT be deleted
as they do not depend on care-of addresses and can be used again. as they do not depend on care-of addresses and can be used again.
o The mobile node MUST use the Home Address destination option in o The mobile node MUST use the Home Address destination option in
Binding Updates and Mobile Prefix Solicitations, sent to the home Binding Updates and Mobile Prefix Solicitations when transport
agent from a care-of address, so that the home address is visible mode IPsec protection is used, so that the home address is visible
when the IPsec policy checks are made. when the IPsec policy checks are made.
o The home agent MUST use the Type 2 Routing header in Binding o The home agent MUST use the Type 2 Routing header in Binding
Acknowledgements and Mobile Prefix Advertisements sent to the Acknowledgements and Mobile Prefix Advertisements sent to the
mobile node, again due to the need to have the home address mobile node when transport mode IPsec protection is used, again
visible when the policy checks are made. due to the need to have the home address visible when the policy
checks are made.
4.3. IPsec Protocol Processing Requirements 4.3. IPsec Protocol Processing Requirements
The following lists requirements for IPsec processing at the Home The following lists requirements for IPsec processing at the Home
Agent and the mobile node. Agent and the mobile node.
o The home agent and mobile node SHOULD support Mobility Header o The home agent and mobile node SHOULD support Mobility Header
message type as an IPsec selector. message type as an IPsec selector.
o The home agent and mobile node SHOULD support ICMPv6 message type o The home agent and mobile node SHOULD support ICMPv6 message type
skipping to change at page 7, line 41 skipping to change at page 8, line 4
o The home agent MUST be able to distinguish between HoTi messages o The home agent MUST be able to distinguish between HoTi messages
sent to itself, when it is acting as a Correspondent Node, from sent to itself, when it is acting as a Correspondent Node, from
those sent to Correspondent Nodes when it is acting as a home those sent to Correspondent Nodes when it is acting as a home
agent, based on the destination address of the packet. agent, based on the destination address of the packet.
o When securing Binding Updates, Binding Acknowledgements, and o When securing Binding Updates, Binding Acknowledgements, and
Mobile Prefix Discovery messages, both the mobile node and the Mobile Prefix Discovery messages, both the mobile node and the
home agent MUST support the use of Encapsulating Security Payload home agent MUST support the use of Encapsulating Security Payload
(ESP) [6] header in transport mode and MUST use a non-null payload (ESP) [6] header in transport mode and MUST use a non-null payload
authentication algorithm to provide data origin authentication, authentication algorithm to provide data origin authentication,
connectionless integrity and optional anti-replay protection. connectionless integrity and optional anti-replay protection. The
use of sequence number in the ESP header to provide anti-replay
protection is optional because the sequence numbers in the Binding
Updates provide anti-replay protection. However, the anti-replay
protection fails if the home agent looses the binding cache state,
for example, due to a reboot. Since the IPsec security
association state can be also be assumed to be lost, ESP cannot
provide anti-replay protection in this case. Complete anti-replay
protection can only be provided by the use of a dynamic keying
mechanism, like IKEv2.
Support for protecting these messages using ESP in tunnel mode is Support for protecting these messages using ESP in tunnel mode is
optional. optional.
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the
protection of packets belonging to the return routability protection of packets belonging to the return routability
procedure. A non-null encryption transform and a non-null procedure. A non-null encryption transform and a non-null
authentication algorithm MUST be applied. authentication algorithm MUST be applied.
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 that appears in the IPv6 header protection for the care-of address that appears in the IPv6 header
skipping to change at page 8, line 48 skipping to change at page 9, line 18
agent and protected by the use of IPsec. Address modifications agent and protected by the use of IPsec. Address modifications
based on other sources, such as Binding Updates to the based on other sources, such as Binding Updates to the
correspondent nodes protected by return routability, or open correspondent nodes protected by return routability, or open
access to an API from any application may result in security access to an API from any application may result in security
vulnerabilities. vulnerabilities.
4.4. Dynamic Keying Requirements 4.4. Dynamic Keying Requirements
The following requirements are related to the use of a dynamic key The following requirements are related to the use of a dynamic key
management protocol by the mobile node and the home agent. management protocol by the mobile node and the home agent.
Section 7.2 describes the use of IKEv2 as the dynamic key management Section 7.3 describes the use of IKEv2 as the dynamic key management
protocol. protocol.
o The mobile node MUST use its care-of address as source address in o The mobile node MUST use its care-of address as source address in
protocol exchanges, when using dynamic keying. protocol exchanges, when using dynamic keying.
o The mobile node and the home agent MUST create security o The mobile node and the home agent MUST create security
associations based on the home address, so that the security associations based on the home address, so that the security
associations survive change in care-of address. When using IKEv2 associations survive change in care-of address. When using IKEv2
as the key exchange protocol, the home address should be carried as the key exchange protocol, the home address should be carried
as the initiator IP address in the TSi payload during the as the initiator IP address in the TSi payload during the
CREATE_CHILD_SA exchange [4]. CREATE_CHILD_SA exchange [4].
o If the mobile node has used IKEv2 to establish security o If the mobile node has used IKEv2 to establish security
associations with its home agent, it should follow the procedures associations with its home agent, it should follow the procedures
discussed in Section 11.7.1 and 11.7.3 of the base specification discussed in Section 11.7.1 and 11.7.3 of the base specification
[2] to determine whether the IKE endpoints can be moved or if the [2] to determine whether the IKE endpoints can be moved or if the
IKE SA has to be re-established. SAs, including the IKEv2 SA, have to be re-established.
o If the home agent has used IKEv2 to establish security o If the home agent has used IKEv2 to establish security
associations with the mobile node, it should follow the procedures associations with the mobile node, it should follow the procedures
discussed in Section 10.3.1 and 10.3.2 of the base specification discussed in Section 10.3.1 and 10.3.2 of the base specification
[2] to determine whether the IKE endpoints can be moved or if the [2] to determine whether the IKE endpoints can be moved or if the
IKE SA has to be re-established. SAs, including the IKEv2 SA, have to be re-established.
5. Selector Granularity Considerations 5. Selector Granularity Considerations
IPsec implementations are compatible with this document even if they IPsec implementations are compatible with this document even if they
do not support fine grain selectors such as the Mobility Header do not support fine grain selectors such as the Mobility Header
message type and ICMPv6 message type. For various reasons, some message type and ICMPv6 message type. Note that such IPsec
implementations may choose to support only coarse grain selectors implementations are not compliant to RFC 4301 [5]. For various
(i.e., addresses and in some cases the protocol field) for forwarded reasons, some implementations may choose to support only coarse grain
traffic. As finer grain selectors give better control, i.e., the selectors (i.e., addresses and in some cases the protocol field) for
protection is only applied when required, the examples in the forwarded traffic. As finer grain selectors give better control,
document always use the finest granularity. i.e., the protection is only applied when required, the examples in
the document always use the finest granularity.
The following describes different ways of setting up IPsec policies The following describes different ways of setting up IPsec policies
for protecting Mobile IPv6 messages: for protecting Mobile IPv6 messages:
o The IPsec implementations on the mobile node and the home agent o The IPsec implementations on the mobile node and the home agent
support fine grain selectors, including the Mobility Header support fine grain selectors, including the Mobility Header
message type. This is the case assumed in the IPsec SPD and SAD message type. This is the case assumed in the IPsec SPD and SAD
examples in this document. examples in this document.
o The IPsec implementations only support selectors at a protocol o The IPsec implementations only support selectors at a protocol
skipping to change at page 10, line 11 skipping to change at page 10, line 29
individual mobility header messages. In this case, the protection individual mobility header messages. In this case, the protection
of Return Routability Messages uses a setup similar to the regular of Return Routability Messages uses a setup similar to the regular
payload packets to the correspondent node with the protocol payload packets to the correspondent node with the protocol
selector set to Mobility Header messages. All tunneled Mobility selector set to Mobility Header messages. All tunneled Mobility
Header messages will be protected. Header messages will be protected.
o The third case is where the protocol selector is not available in o The third case is where the protocol selector is not available in
the IPsec implementation. In this case all traffic sent by the the IPsec implementation. In this case all traffic sent by the
mobile node reverse tunneled through the home agent is protected mobile node reverse tunneled through the home agent is protected
using ESP in tunnel mode. This case is also applicable when the using ESP in tunnel mode. This case is also applicable when the
mobile node, due to privacy considerations tunnels all traffic to mobile node, due to privacy considerations, tunnels all traffic to
the home agent. This includes Mobile IPv6 signaling messages the home agent. This includes Mobile IPv6 signaling messages
exchanged between the mobile node and the home agent and all exchanged between the mobile node and the home agent and all
traffic exchanged between the mobile node and the correspondent traffic exchanged between the mobile node and the correspondent
node. This case uses IPsec tunnel mode SA with the protocol node. This case uses IPsec tunnel mode SA with the protocol
selector set to 'any'. selector set to 'any'.
The third case where all tunneled traffic is protected introduces The third case where all tunneled traffic is protected introduces
some additional considerations: some additional considerations:
o If there is just one IPsec SA providing protection for all o If there is just one IPsec SA providing protection for all
traffic, then the SA MUST fulfill the requirements for protecting traffic, then the SA MUST fulfill the requirements for protecting
the Return Routability messages which require confidentiality the Return Routability messages which require confidentiality
protection. If the third case is being used for privacy protection. If the third case is being used for privacy
considerations, then there can also be separate tunnel mode SPD considerations, then there can also be separate tunnel mode SPD
entries for protecting the Return Routability messages with a entries for protecting the Return Routability messages with a
higher priority. higher priority in the SPD so that the SPD entry with the higher
priority gets applied first.
o The receipt of a Binding Update from the new care-of address o The receipt of a Binding Update from the new care-of address
updates the tunnel end point of the IPsec SA as described in updates the tunnel endpoint of the IPsec SA as described in
Section 4.3. Since the Binding Update that updates the tunnel end Section 4.3. Since the Binding Update that updates the tunnel
point is received through the same tunnel interface that needs to endpoint is received through the same tunnel interface that needs
be updated, special care should be taken on the home agent to to be updated, special care should be taken on the home agent to
ensure that the Binding Update is not dropped. This can be ensure that the Binding Update is not dropped. This can be
achieved by either performing the source address check on the achieved by either performing the source address check on the
outer IPv6 header after the binding update is processed or have outer IPv6 header after the binding update is processed or have
exception handling to check the inner packet for a Binding Update exception handling to check the inner packet for a Binding Update
when the source address match on the outer source address fails. when the source address match on the outer source address fails.
Typical IPsec processing does not check the outer source address. Typical IPsec processing does not check the outer source address
when the originator of the packet has already been authenticated.
6. Manual Configuration 6. Manual Configuration
This section describes the SPD and SAD entries that can be used to This section describes the SPD and SAD entries that can be used to
protect Mobile IPv6 signaling messages. The SPD and SAD entries are protect Mobile IPv6 signaling messages. The SPD and SAD entries are
only example configurations. A particular mobile node implementation only example configurations. A particular mobile node implementation
and a home agent implementation could configure different SPD and SAD and a home agent implementation could configure different SPD and SAD
entries as long as they provide the required security of the Mobile entries as long as they provide the required security of the Mobile
IPv6 signaling messages. IPv6 signaling messages.
For the examples described in this document, a mobile node with home For the examples described in this document, a mobile node with home
address, "home_address_1", primary care-of address, address, "home_address_1", primary care-of address,
"care_of_address_1", a home agent with address, "home_agent_1" and a "care_of_address_1", a home agent with address, "home_agent_1" and a
user of the mobile node with identity "user_1" are assumed. If the user of the mobile node with identity "user_1" are assumed. If the
home address of the mobile node changes, the SPD and SAD entries need home address of the mobile node changes, the SPD and SAD entries need
to be re-created or updated for the new home address. to be re-created or updated for the new home address.
The Peer Authorization Database is not used when manual IPsec
configuration is used for setting up security associations for
protecting Mobile IPv6 signaling messages.
6.1. Binding Updates and Acknowledgements 6.1. Binding Updates and Acknowledgements
The following are the SPD and SAD entries on the mobile node and the The following are the SPD and SAD entries on the mobile node and the
home agent to protect Binding Updates and Acknowledgements. home agent to protect Binding Updates and Acknowledgements.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 & - IF local_address = home_address_1 &
proto = MH & local_mh_type =BU & remote_mh_type = remote_address = home_agent_1 & proto = MH &
BAck local_mh_type = BU & remote_mh_type = BAck
Then use SA SA1 (OUT) and SA2 (IN) Then use SA SA1 (OUT) and SA2 (IN)
mobile node SAD: mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU proto = MH & mh_type = BU
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck proto = MH & mh_type = BAck
home agent SPD-S: home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 & - IF local_address = home_agent_1 &
proto = MH & local_mh_type = BAck & remote_mh_type remote_address = home_address_1 & proto = MH &
= BU local_mh_type = BAck & remote_mh_type = BU
Then use SA SA2 (OUT) and SA1 (IN) Then use SA SA2 (OUT) and SA1 (IN)
home agent SAD: home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & mh_type = BAck proto = MH & mh_type = BAck
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & mh_type = BU proto = MH & mh_type = BU
6.2. Return Routabililty Messages 6.2. Return Routabililty Messages
The following are the SPD and SAD entries on the mobile node and the The following are the SPD and SAD entries on the mobile node and the
home agent to protect Return Routability messages. home agent to protect Return Routability messages.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = any & - IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & remote_mh_type = HoT proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
Then use SA SA3 (OUT) and SA4 (IN) Then use SA SA3 (OUT) and SA4 (IN)
mobile node SAD: mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH & local_address = home_address_1 & remote_address = any &
mh_type = HoTi proto = MH & mh_type = HoTi
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL): - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH & local_address = any & remote_address = home_address_1 &
mh_type = HoT proto = MH & mh_type = HoT
home agent SPD-S: home agent SPD-S:
- IF destination = home_address_1 & source = any & - IF remote_address = home_address_1 & local_address = any &
proto = MH & local_mh_type = HoT & remote_mh_type = proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
HoTi
Then use SA SA4 (OUT) and SA3 (IN) Then use SA SA4 (OUT) and SA3 (IN)
home agent SAD: home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL): - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH & local_address = any & remote_address = home_address_1 &
mh_type = HoT proto = MH & mh_type = HoT
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH & local_address = home_address_1 & remote_address = any &
mh_type = HoTi proto = MH & mh_type = HoTi
6.3. Mobile Prefix Discovery Messages 6.3. Mobile Prefix Discovery Messages
The following are the SPD and SAD entries used to protect Mobile The following are the SPD and SAD entries used to protect Mobile
Prefix Discovery messages. Prefix Discovery messages.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 & - IF local_address = home_address_1 &
proto = ICMPv6 & local_icmp6_type = MPS & remote_address = home_agent_1 & proto = ICMPv6 &
remote_icmp6_type = MPA local_icmp6_type = MPS & remote_icmp6_type = MPA
Then use SA SA5 (OUT) and SA6 (IN) Then use SA SA5 (OUT) and SA6 (IN)
mobile node SAD: mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS proto = ICMPv6 & icmp6_type = MPS
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA proto = ICMPv6 & icmp6_type = MPA
home agent SPD-S: home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 & - IF local_address = home_agent_1 &
proto = ICMPv6 & local_icmp6_type = MPA & remote_address = home_address_1 & proto = ICMPv6 &
remote_icmp6_type = MPS local_icmp6_type = MPA & remote_icmp6_type = MPS
Then use SA SA6 (OUT) and SA5 (IN) Then use SA SA6 (OUT) and SA5 (IN)
home agent SAD: home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & local_address = home_agent_1 &
remote_address = home_address_1 &
proto = ICMPv6 & icmp6_type = MPA proto = ICMPv6 & icmp6_type = MPA
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & local_address = home_address_1 &
remote_address = home_agent_1 &
proto = ICMPv6 & icmp6_type = MPS proto = ICMPv6 & icmp6_type = MPS
6.4. Payload Packets 6.4. Payload Packets
Regular payload traffic between the mobile node and the correspondent Regular payload traffic between the mobile node and the correspondent
node tunneled through the home agent can be protected by IPsec, if node tunneled through the home agent can be protected by IPsec, if
required. The mobile node and the home agent use ESP in tunnel mode required. The mobile node and the home agent use ESP in tunnel mode
to protect the tunneled traffic. The SPD and SAD entries shown in to protect the tunneled traffic. The SPD and SAD entries shown in
Section 5.2.4 of [3] are applicable here. Section 5.2.4 of [3] are applicable here.
7. Dynamic Configuration 7. Dynamic Configuration
This section describes the use of IKEv2 to setup the required This section describes the use of IKEv2 to setup the required
security associations. security associations.
7.1. Security Policy Database Entries 7.1. Peer Authorization Database Entries
The following describes PAD entries on the mobile node and the home
agent. The PAD entries are only example configurations. Note that
the PAD is a logical concept and a particular mobile node and a home
agent implementation can implement the PAD in an implementation
specific manner. The PAD state may also be distributed across
various databases in a specific implementation.
mobile node PAD:
- IF remote_identity = home_agent_identity_1
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address home_agent_1
home agent PAD:
- IF remote_identity = user_1
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for remote address home_address_1
The list of authentication mechanisms in the above examples is not
exhaustive. There could be other credentials used for authentication
stored in the PAD.
In case of dynamic home address assignment, the home agent creates a
temporary PAD entry linking the authenticated peer identity and the
newly allocated home address.
7.2. Security Policy Database Entries
The following sections describe the security policy entries on the The following sections describe the security policy entries on the
mobile node and the home agent. The SPD entries are only example mobile node and the home agent. The SPD entries are only example
configurations. A particular mobile node implementation and a Home configurations. A particular mobile node implementation and a Home
Agent implementation could configure different SPD entries as long as Agent implementation could configure different SPD entries as long as
they provide the required security of the Mobile IPv6 signaling they provide the required security of the Mobile IPv6 signaling
messages. messages.
In the examples shown below, the identity of the user of the mobile In the examples shown below, the identity of the user of the mobile
node is assumed to be user_1, the home address of the mobile node is node is assumed to be user_1, the home address of the mobile node is
assumed to be home_address_1, he primary care-of address of the assumed to be home_address_1, the primary care-of address of the
mobile node is assumed to be care_of_address_1 and the IPv6 address mobile node is assumed to be care_of_address_1 and the IPv6 address
of the Home Agent is assumed to be home_agent_1. of the Home Agent is assumed to be home_agent_1.
7.1.1. Binding Updates and Acknowledgements 7.2.1. Binding Updates and Acknowledgements
The following are the SPD entries on the mobile node and the home The following are the SPD entries on the mobile node and the home
agent for protecting Binding Updates and Acknowledgements. agent for protecting Binding Updates and Acknowledgements.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 & - IF local_address = home_address_1 &
remote_address = home_agent_1 &
proto = MH & local_mh_type = BU & remote_mh_type = BAck proto = MH & local_mh_type = BU & remote_mh_type = BAck
Then use SA ESP transport mode Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1, Initiate using IDi = user_1 to address home_agent_1
TSi = home_address_1, MH, BU
TSr = home_agent_1, MH, BAck
home agent SPD-S: home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 & - IF local_address = home_agent_1 &
remote_address = home_address_1 &
proto = MH & local_mh_type = BAck & remote_mh_type = BU proto = MH & local_mh_type = BAck & remote_mh_type = BU
Then use SA ESP transport mode Then use SA ESP transport mode
IDi = home_agent_1, IDr = user_1
TSi = home_agent_1, MH, BAck
TSr = home_address_1, MH, BU
In the examples shown above, the home address of the mobile node In the examples shown above, the home address of the mobile node
might not be available all the time. For instance, the mobile node might not be available all the time. For instance, the mobile node
might have not configured a home address yet. When the mobile node might have not configured a home address yet. When the mobile node
acquires a new home address, it must either add the address to the acquires a new home address, it must either add the address to the
corresponding SPD entries or create the SPD entries for the home corresponding SPD entries or create the SPD entries for the home
address. address.
The home agent should have named SPD entries per mobile node, based The home agent should have named SPD entries per mobile node, based
on the identity of the mobile node. The identity of the mobile node on the identity of the mobile node. The identity of the mobile node
skipping to change at page 15, line 14 skipping to change at page 16, line 46
mobile node authenticates to the home agent and configures a home mobile node authenticates to the home agent and configures a home
address, appropriate SPD entries are created for the mobile node. address, appropriate SPD entries are created for the mobile node.
The Mobility Header message type is negotiated by placing it in the The Mobility Header message type is negotiated by placing it in the
most significant eight bits of the 16 bit local "port" selector most significant eight bits of the 16 bit local "port" selector
during IKEv2 exchange. For more details, refer to [5]. The TSi and during IKEv2 exchange. For more details, refer to [5]. The TSi and
TSr payloads in the above examples will contain many other selectors TSr payloads in the above examples will contain many other selectors
apart from home_address_1. For the sake of brevity, we show only apart from home_address_1. For the sake of brevity, we show only
those values that are relevant for Mobile IPv6. those values that are relevant for Mobile IPv6.
7.1.2. Return Routability Messages 7.2.2. Return Routability Messages
The following are the SPD entries on the mobile node and the home The following are the SPD entries on the mobile node and the home
agent for protecting the Return Routability messages. agent for protecting the Return Routability messages.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = any & - IF local_address = home_address_1 & remote_address = any &
proto = MH & local_mh_type = HoTi & proto = MH & local_mh_type = HoTi & remote_mh_type = HoT
remote_mh_type = HoT
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
IDi = user_1, IDr = home_agent_1, Initiate using IDi = user_1 to address home_agent_1
TSi = home_address_1, MH, HoTi
TSr = any, MH, HoT
outer src addr = care_of_address_1,
outer dst addr = home_agent_1,
inner src addr = home_address_1
home agent SPD-S: home agent SPD-S:
- IF source = any & destination = home_address_1 & - IF local_address = any & remote_address = home_address_1 &
proto = MH & local_mh_type = HoT & proto = MH & local_mh_type = HoT & remote_mh_type = HoTi
remote_mh_type = HoTi
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
IDi = home_agent_1, IDr = user_1
TSi = any, MH, HoT
TSr = home_address_1, MH, HoTi
outer src addr = home_agent_1,
outer dst addr = care_of_address_1,
inner dst addr = home_address_1
When the mobile node's care-of address changes the SPD entries on When the mobile node's care-of address changes the SPD entries on
both the mobile node and the home agent must be updated. The home both the mobile node and the home agent must be updated. The home
agent knows about the change in care-of address of the mobile node agent knows about the change in care-of address of the mobile node
when it receives a Binding Update from the mobile node. when it receives a Binding Update from the mobile node.
7.1.3. Mobile Prefix Discovery Messages 7.2.3. Mobile Prefix Discovery Messages
The following are the SPD entries on the mobile node and the home The following are the SPD entries on the mobile node and the home
agent for protecting Mobile Prefix Discovery messages. agent for protecting Mobile Prefix Discovery messages.
mobile node SPD-S: mobile node SPD-S:
- IF source = home_address_1 & destination = home_agent_1 & - IF local_address = home_address_1 &
proto = ICMPv6 & local_mh_type = MPS & remote_address = home_agent_1 &
remote_mh_type = MPA proto = ICMPv6 & local_icmp6_type = MPS &
remote_icmp6_type = MPA
Then use SA ESP transport mode Then use SA ESP transport mode
IDi = user_1, IDr = home_agent_1, Initiate using IDi = user_1 to address home_agent_1
TSi = home_address_1, ICMPv6, MPS
TSr = home_agent_1, ICMPv6, MPA
home agent SPD-S: home agent SPD-S:
- IF source = home_agent_1 & destination = home_address_1 & - IF local_address = home_agent_1 &
proto = ICMPv6 & local_mh_type = MPA & remote_address = home_address_1 &
remote_mh_type = MPS proto = ICMPv6 & local_icmp6_type = MPA &
remote_icmp6_type = MPS
Then use SA ESP transport mode Then use SA ESP transport mode
IDi = home_agent_1, IDr = user_1
TSi = home_agent_1, ICMPv6, MPA
TSr = home_address_1, ICMPv6, MPS
In the examples shown above, the home address of the mobile node In the examples shown above, the home address of the mobile node
might not be available all the time. When the mobile node acquires a might not be available all the time. When the mobile node acquires a
new home address, it must add the address to the corresponding SPD new home address, it must add the address to the corresponding SPD
entries. entries.
The TSi and TSr payloads in the above examples will contain many The TSi and TSr payloads in the above examples will contain many
other selectors apart from home_address_1. For brevity, they are not other selectors apart from home_address_1. For brevity, they are not
show here. show here.
7.1.4. Payload Packets 7.2.4. Payload Packets
The following are the SPD entries on the mobile node and the home The following are the SPD entries on the mobile node and the home
agent if payload traffic exchanged between the mobile node and its agent if payload traffic exchanged between the mobile node and its
Correspondent Node needs to be protected. The SPD entries are Correspondent Node needs to be protected. The SPD entries are
similar to the entries for protecting Return Routability messages and similar to the entries for protecting Return Routability messages and
have lower priority than the above SPD entries. have lower priority than the above SPD entries.
mobile node SPD-S: mobile node SPD-S:
- IF interface = IPv6 tunnel to home_agent_1 & proto = X - IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & proto = X
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
IDi = user_1, IDr = home_agent_1, Initiate using IDi = user_1 to address home_agent_1
TSi = home_address_1, X, port
TSr = any, X, port
outer src addr = care_of_address_1
outer dst addr = home_agent_1,
inner src addr = home_address_1
home agent SPD-S: home agent SPD-S:
- IF interface = IPv6 tunnel to home_address_1 & proto = X - IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X
Then use SA ESP tunnel mode Then use SA ESP tunnel mode
IDi = home_agent_1, IDr = user_1,
TSi = any, X, port
TSr = home_address_1, X, port
outer src addr = home_agent_1,
outer dst addr = care_of_address_1,
inner dst addr = home_address_1
7.2. Security Association negotiation using IKEv2 7.3. Security Association negotiation using IKEv2
Mobile IPv6 signaling messages are typically initiated by the mobile Mobile IPv6 signaling messages are typically initiated by the mobile
node. The mobile node sends a Binding Update to the home agent node. The mobile node sends a Binding Update to the home agent
whenever it moves and acquires a new care-of address. whenever it moves and acquires a new care-of address.
The mobile node initiates an IKEv2 protocol exchange if the required The mobile node initiates an IKEv2 protocol exchange if the required
security associations are not present. A possible mechanism used for security associations are not present. A possible mechanism used for
mutual authentication is a shared secret between the mobile node and mutual authentication is a shared secret between the mobile node and
the home agent. The home agent uses the identity of the mobile node the home agent. The home agent uses the identity of the mobile node
to identify the corresponding shared secret. When a public key based to identify the corresponding shared secret. When a public key based
skipping to change at page 18, line 44 skipping to change at page 19, line 44
payload to negotiate IPsec security associations for protecting the payload to negotiate IPsec security associations for protecting the
Binding Update and Binding Acknowledgement messages. The mobile node Binding Update and Binding Acknowledgement messages. The mobile node
MAY use a range of selectors that includes the mobility message types MAY use a range of selectors that includes the mobility message types
for Binding Update and Binding Acknowledgement to use the same pair for Binding Update and Binding Acknowledgement to use the same pair
of IPsec security association for both messages. of IPsec security association for both messages.
After the IKE_AUTH exchange completes, the mobile node initiates After the IKE_AUTH exchange completes, the mobile node initiates
CREATE_CHILD_SA exchanges to negotiate additional security CREATE_CHILD_SA exchanges to negotiate additional security
associations for protecting Return Routability signaling, Mobile associations for protecting Return Routability signaling, Mobile
Prefix Discovery messages and optionally payload traffic. The Prefix Discovery messages and optionally payload traffic. The
CREATE_CHILD_SA exchanges are protected by the security association CREATE_CHILD_SA exchanges are protected by IKEv2 security association
created during the IKE_AUTH exchange. If a correspondent node, that created during the IKE_SA_INIT exchange. If a correspondent node,
is also a mobile node, initiates the return routability exchange, that is also a mobile node, initiates the return routability
then the home agent initiates the CREATE_CHILD_SA exchange to exchange, then the home agent initiates the CREATE_CHILD_SA exchange
negotiate security associations for protecting Return Routabilty to negotiate security associations for protecting Return Routabilty
messages. messages.
It is important that the security associations are created based on It is important that the security associations are created based on
the home address of the mobile node, so that the security the home address of the mobile node, so that the security
associations survive care-of address change. The mobile node MUST associations survive care-of address change. The mobile node MUST
use its home address as the initiator IP address in the TSi payload use its home address as the initiator IP address in the TSi payload
in the CREATE_CHILD_SA exchange in order to create the security in the CREATE_CHILD_SA exchange in order to create the IPsec security
associations for the home address. associations for the home address.
Mobile Node Home Agent Mobile Node Home Agent
----------- ---------- ----------- ----------
HDR, SK {[N], SA, Ni, [KEi], HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} --> [TSi, TSr]} -->
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
[TSi, TSr]} [TSi, TSr]}
When PKI based authentication is used between the mobile node and the When PKI based authentication is used between the mobile node and the
Home Agent, the identity presented by the mobile node in the IDi Home Agent, the identity presented by the mobile node in the IDi
payload must correspond to the identity in the certificate obtained payload MUST correspond to the identity in the certificate obtained
by the Home Agent. The home agent uses the identity presented in the by the Home Agent. The home agent uses the identity presented in the
IDi payload to lookup the policy and the certificate that corresponds IDi payload to lookup the policy and the certificate that corresponds
to the mobile node. If the mobile node presents its home address in to the mobile node. If the mobile node presents its home address in
the IDi payload, then the home agent MUST verify that the home the IDi payload, then the home agent MUST verify that the home
address matches the address in the iPAddress field in the address matches the address in an iPAddress field in the
SubjectAltName extension [8]. SubjectAltName extension [8].
When the mobile node uses its home address in the IDi field, When the mobile node uses its home address in the IDi field,
implementations are required to match the source address in the implementations are not required to match the source address in the
outermost IP header with the IP address in the IDi field [8]. This outermost IP header with the IP address in the IDi field. According
verification step, however, should be configurable [8]. With Mobile to RFC 4306 [4], the IP header fields in the IKEv2 messages are
IPv6, this verification step will always fail because the source ignored and used only in the IP headers for IKEv2 messages sent as
address in the IP header is the care-of address and the IP address in replies.
the IDi field is the home address. Therefore, this verification step
MUST be disabled.
7.3. Movements and Dynamic Keying 7.4. Movements and Dynamic Keying
If the mobile node moves and its care-of address changes, the IKEv2 If the mobile node moves and its care-of address changes, the IKEv2
SA might not be valid. RFC 3775 defines a mechanism based on the SA might not be valid. RFC 3775 defines a mechanism based on the
successful exchange of Binding Update and Binding Acknowledgement successful exchange of Binding Update and Binding Acknowledgement
messages. The mobile node establishes the IKE SA with the home agent messages. The mobile node establishes the IKE SA with the home agent
using its primary care-of address. The IKE SA endpoints are updated using its primary care-of address. The IKE SA endpoints are updated
on the home agent when it receives the Binding Update from the mobile on the home agent when it receives the Binding Update from the mobile
node's new care-of address and on the mobile node when it sends the node's new care-of address and on the mobile node when it sends the
Binding Update to the home agent or when it receives the Binding Binding Update to the home agent or when it receives the Binding
acknowledgement sent by the home agent. This capability to change acknowledgement sent by the home agent. This capability to change
skipping to change at page 20, line 18 skipping to change at page 21, line 17
In addition to using public key signatures and shared secrets, EAP In addition to using public key signatures and shared secrets, EAP
[10] can be used with IKEv2 for authenticating the mobile node to the [10] can be used with IKEv2 for authenticating the mobile node to the
home agent. home agent.
The mobile node indicates that it wants to use EAP by including the The mobile node indicates that it wants to use EAP by including the
IDi payload but leaving out the AUTH payload in the first message IDi payload but leaving out the AUTH payload in the first message
during the IKE_AUTH exchange. The home agent then includes an EAP during the IKE_AUTH exchange. The home agent then includes an EAP
payload if it is willing to use an extensible authentication method. payload if it is willing to use an extensible authentication method.
Security associations are not created until the subsequent IKE_AUTH Security associations are not created until the subsequent IKE_AUTH
exchange after successful EAP authentication. The use of EAP adds at exchange after successful EAP authentication. The use of EAP adds at
least two round trips to the IKE negotiation. least two round trips to the IKE negotiation. The number of round
trips depends on the EAP method used.
Mobile Node Home Agent Mobile Node Home Agent
------------ ---------- ------------ ----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,] HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr}--> SAi2, TSi, TSr}-->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
.
.
.
HDR, SK {EAP} --> HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)} <-- HDR, SK {EAP (success)}
HDR, SK {AUTH} --> HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, <-- HDR, SK {AUTH, SAr2, TSi,
TSr} TSr}
When EAP is used, the identity presented by the mobile node in the When EAP is used, the identity presented by the mobile node in the
IDi field may not be the actual identity of the mobile node. It IDi field may not be the actual identity of the mobile node. It
could be set to an identity that is used only for AAA routing could be set to an identity that is used only for AAA routing
purposes and selecting the right EAP method. The actual identity is purposes and selecting the right EAP method. It is possible that the
carried inside EAP payloads that is not visible to the home agent. actual identity is carried inside EAP, invisible to the home agent.
The home agent MUST acquire the mobile node's identity from the While IKEv2 does not allow an EAP Identity Request/Response message
corresponding AAA server. More details can be found in [13]. exchange, EAP methods may exchange identities within themselves. In
this case the home agent MUST acquire the mobile node's identity from
the corresponding AAA server. How the home agent acquires the mobile
node's identity is out of scope for this document.
Some EAP methods generate a shared key on the mobile node and the Some EAP methods, when used with IKEv2, generate a shared key on the
Home Agent once the EAP authentication succeeds. In this case, the mobile node and the Home Agent once the EAP authentication succeeds.
shared key is used to generate the AUTH payloads in the subsequent This shared key is used to generate the AUTH payloads in the
messages. The shared key, if used to generate the AUTH payloads, subsequent IKEv2 messages. The shared key, if used to generate the
MUST NOT be used for any other purpose. For more details, refer to AUTH payloads, MUST NOT be used for any other purpose. For more
[4]. details, refer to [4].
The use of EAP between the mobile node and the home agent might The use of EAP between the mobile node and the home agent might
require the home agent to contact an authorization server like the require the home agent to contact an authorization server like the
AAA Home server, on the home link, to authenticate the mobile node. AAA Home server, on the home link, to authenticate the mobile node.
Please refer to [7] for more details. Please refer to [7] for more details.
9. Dynamic Home Address Configuration 9. Dynamic Home Address Configuration
The mobile node can dynamically configure a home address by including The mobile node can dynamically configure a home address by including
a Configuration Payload in the IKE_AUTH exchange, with a request for a Configuration Payload in the IKE_AUTH exchange, with a request for
skipping to change at page 21, line 30 skipping to change at page 22, line 34
Payload. The mobile node MAY include multiple instances of the Payload. The mobile node MAY include multiple instances of the
INTERNAL_IP6_ADDRESS to request multiple home address to the assigned INTERNAL_IP6_ADDRESS to request multiple home address to the assigned
by the home agent. by the home agent.
When the home agent receives a configuration payload with a When the home agent receives a configuration payload with a
CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home
address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in
the CFG_REPLY contains the prefix length of the home prefix in the CFG_REPLY contains the prefix length of the home prefix in
addition to a 128 bit home address. The home agent could use a local addition to a 128 bit home address. The home agent could use a local
database or contact a DHCPv6 server on the home link to allocate a database or contact a DHCPv6 server on the home link to allocate a
home address. The Home Agent should also include an home address. The duration for which the home address is allocated
INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the to the mobile node is the same as duration for which an IKEv2
duration for which the dynamically allocated home address is valid. security association exists between the mobile node and the home
agent. If the IKEv2 security association is rekeyed, the home
address lifetime is also extended.
Mobile Node Home Agent Mobile Node Home Agent
----------- ---------- ----------- ----------
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, CP(CFG_REQUEST), [IDr,] AUTH, CP(CFG_REQUEST),
SAi2, TSi, TSr} SAi2, TSi, TSr}
--> -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
CP(CFG_REPLY), SAr2, CP(CFG_REPLY), SAr2,
skipping to change at page 22, line 12 skipping to change at page 23, line 19
could let the mobile node use the same home address by setting the could let the mobile node use the same home address by setting the
INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same
home address. If the home agent wants the mobile node to use a home address. If the home agent wants the mobile node to use a
different home address, it sends a new home address in the different home address, it sends a new home address in the
INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload. The Mobile
Node MUST stop using its old home address and start using the newly Node MUST stop using its old home address and start using the newly
allocated home address. allocated home address.
In case the home agent is unable to allocate a home address for the In case the home agent is unable to allocate a home address for the
mobile node during the IKE_AUTH exchange, it MUST send a Notify mobile node during the IKE_AUTH exchange, it MUST send a Notify
Payload with an INTERNAL_ADDRESS_FAILURE message. Payload with an INTERNAL_ADDRESS_FAILURE message. When the mobile
node receives a Notify Payload with an INTERNAL_ADDRESS_FAILURE
message, it SHOULD terminate the IKE_AUTH exchange. The mobile node
then should initiate a new IKE_SA_INIT and IKE_AUTH exchange and try
to auto-configure a home address as described in [13]. The mobile
node MAY also switch to another home agent. The new home agent
address can be obtained by consulting a home agent list received
during a previous home agent discovery phase or, if such list is
empty or not available, by attempting a new home agent discovery.
If the mobile node wants to configure a DNS server from the home link If the mobile node wants to configure a DNS server from the home link
it can request for the DNS server information by including an it can request for the DNS server information by including an
INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload. INTERNAL_IP6_DNS attribute in the CFG_REQUEST payload.
10. Security Considerations 10. Security Considerations
This document describes how IPsec can be used to secure Mobile IPv6 This document describes how IPsec can be used to secure Mobile IPv6
signaling messages. Please refer to RFC 3775 for security signaling messages. Please refer to RFC 3775 for security
considerations related to the use of IPsec with Mobile IPv6. considerations related to the use of IPsec with Mobile IPv6.
skipping to change at page 22, line 44 skipping to change at page 24, line 12
is described in Section 8. Security considerations related to the is described in Section 8. Security considerations related to the
use of EAP with IKEv2 are described in [4]. use of EAP with IKEv2 are described in [4].
11. IANA Considerations 11. IANA Considerations
This document requires no action from IANA. This document requires no action from IANA.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari The authors would like to thank Mika Joutsenvirta, Pasi Eronen, Jari
Arkko, Gerardo Giaretta and Shinta Sugimoto for reviewing the draft. Arkko, Gerardo Giaretta, Shinta Sugimoto, Tero Kivinen, Steve
Bellovin, Kilian Weniger and Vijay Gurbani for reviewing the
document.
Many of the requirements listed in Section 4 are copied from RFC Many of the requirements listed in Section 4 are copied from RFC
3776. Therefore, the authors of RFC 3776 are acknowledged. 3776. Therefore, the authors of RFC 3776 are acknowledged.
13. References 13. References
13.1. Normative References 13.1. 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 24, line 5 skipping to change at page 25, line 20
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[11] Kent, S. and R. Atkinson, "Security Architecture for the [11] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile [12] Sugimoto, S., "PF_KEY Extension as an Interface between Mobile
IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-03 (work IPv6 and IPsec/IKE", draft-sugimoto-mip6-pfkey-migrate-03 (work
in progress), September 2006. in progress), September 2006.
[13] Hoffman, P. and P. Eronen, "IKEv2 Clarifications and [13] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
Implementation Guidelines", draft-ietf-mip6-bootstrapping-split-03 (work in progress),
draft-eronen-ipsec-ikev2-clarifications-09 (work in progress), October 2006.
May 2006.
Authors' Addresses Authors' Addresses
Vijay Devarapalli Vijay Devarapalli
Azaire Networks Azaire Networks
4800 Great America Pkwy 4800 Great America Pkwy
Santa Clara, CA 95054 Santa Clara, CA 95054
USA USA
Email: vijay.devarapalli@azairenet.com Email: vijay.devarapalli@azairenet.com
Francis Dupont Francis Dupont
CELAR CELAR
Email: Francis.Dupont@point6.net Email: Francis.Dupont@fdupont.fr
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 79 change blocks. 
185 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/