mipvhaipsec.txt		mipvhaipsec-292.txt
Skipping to change at page 2, line 17:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8		3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Binding Updates and Acknowledgements . . . . . . . . . 8		3.1 Binding Updates and Acknowledgements . . . . . . . . . 8
3.2 Return Routability Signaling . . . . . . . . . . . . . 9		3.2 Return Routability Signaling . . . . . . . . . . . . . 9
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10		3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 11		3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 11
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12		4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12		4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 14		4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 15
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 16		4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 17
5. Example Configurations . . . . . . . . . . . . . . . . . . . 19		5. Example Configurations . . . . . . . . . . . . . . . . . . . 19
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 19		5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 20		5.2 Manual Configuration . . . . . . . . . . . . . . . . . 20
5.2.1 Binding Updates and Acknowledgements . . . . . . 20		5.2.1 Binding Updates and Acknowledgements . . . . . . 20
5.2.2 Return Routability Signaling . . . . . . . . . . 21		5.2.2 Return Routability Signaling . . . . . . . . . . 21
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 22		5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 22
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 23		5.2.4 Payload Packets . . . . . . . . . . . . . . . . 23
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 25		5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 25
5.3.1 Binding Updates and Acknowledgements . . . . . . 25		5.3.1 Binding Updates and Acknowledgements . . . . . . 25
5.3.2 Return Routability Signaling . . . . . . . . . . 26		5.3.2 Return Routability Signaling . . . . . . . . . . 26
Skipping to change at page 2, line 41:
6. Processing Steps within a Node . . . . . . . . . . . . . . . 29		6. Processing Steps within a Node . . . . . . . . . . . . . . . 29
6.1 Binding Update to the Home Agent . . . . . . . . . . . 29		6.1 Binding Update to the Home Agent . . . . . . . . . . . 29
6.2 Binding Update from the Mobile Node . . . . . . . . . 30		6.2 Binding Update from the Mobile Node . . . . . . . . . 30
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 30		6.3 Binding Acknowledgement to the Mobile Node . . . . . . 30
6.4 Binding Acknowledgement from the Home Agent . . . . . 31		6.4 Binding Acknowledgement from the Home Agent . . . . . 31
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 32		6.5 Home Test Init to the Home Agent . . . . . . . . . . . 32
6.6 Home Test Init from the Mobile Node . . . . . . . . . 33		6.6 Home Test Init from the Mobile Node . . . . . . . . . 33
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 33		6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 33
6.8 Home Test from the Home Agent . . . . . . . . . . . . 34		6.8 Home Test from the Home Agent . . . . . . . . . . . . 34
6.9 Prefix Solicitation Message to the Home Agent . . . . 34		6.9 Prefix Solicitation Message to the Home Agent . . . . 34
6.10 Prefix Solicitation Message from the Mobile Node . . . 34		6.10 Prefix Solicitation Message from the Mobile Node . . . 35
6.11 Prefix Advertisement Message to the Mobile Node . . . 34		6.11 Prefix Advertisement Message to the Mobile Node . . . 35
6.12 Prefix Advertisement Message from the Home Agent . . . 35		6.12 Prefix Advertisement Message from the Home Agent . . . 35
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 35		6.13 Payload Packet to the Home Agent . . . . . . . . . . . 35
6.14 Payload Packet from the Mobile Node . . . . . . . . . 35		6.14 Payload Packet from the Mobile Node . . . . . . . . . 35
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 35		6.15 Payload Packet to the Mobile Node . . . . . . . . . . 35
6.16 Payload Packet from the Home Agent . . . . . . . . . . 35		6.16 Payload Packet from the Home Agent . . . . . . . . . . 35
6.17 Establishing New Security Associations . . . . . . . . 35		6.17 Establishing New Security Associations . . . . . . . . 35
6.18 Rekeying Security Associations . . . . . . . . . . . . 36		6.18 Rekeying Security Associations . . . . . . . . . . . . 36
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37		6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37
7. Implementation Considerations . . . . . . . . . . . . . . . 39		7. Implementation Considerations . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
Skipping to change at page 4, line 52:
replaced by IPsec tunnels [2].		replaced by IPsec tunnels [2].
Mobile IPv6 also provides support for the reconfiguration of the home		Mobile IPv6 also provides support for the reconfiguration of the home
network. Here the home subnet prefixes may change over time. Mobile		network. Here the home subnet prefixes may change over time. Mobile
nodes can learn new information about home subnet prefixes through		nodes can learn new information about home subnet prefixes through
the "prefix discovery" mechanism.		the "prefix discovery" mechanism.
This document discusses security mechanisms for the control traffic		This document discusses security mechanisms for the control traffic
between the mobile node and the home agent. If this traffic is not		between the mobile node and the home agent. If this traffic is not
protected, mobile nodes and correspondent nodes are vulnerable to		protected, mobile nodes and correspondent nodes are vulnerable to
Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and		man-in-the-middle, hijacking, passive wiretapping, impersonation, and
Denial-of-Service attacks. Any third parties are also vulnerable to		denial-of-service attacks. Any third parties are also vulnerable to
Denial-of-Service attacks. These threats are discussed in more		denial-of-service attacks, for instance if an attacker could direct
detail in Section 15.1 of the Mobile IPv6 base specification [8].		the traffic flowing through the home agent to a innocent third party.
		These attacks are discussed in more detail in Section 15.1 of the
		Mobile IPv6 base specification [8].
In order to avoid these attacks, the base specification uses IPsec		In order to avoid these attacks, the base specification uses IPsec
[2] to protect control traffic between the home agent and the mobile		[2] to protect control traffic between the home agent and the mobile
node. This control traffic consists of various messages carried by		node. This control traffic consists of various messages carried by
the Mobility Header protocol in IPv6 [6]. The traffic takes the		the Mobility Header protocol in IPv6 [6]. The traffic takes the
following forms:		following forms:
o Binding Update and Acknowledgement messages exchanged between the		o Binding Update and Acknowledgement messages exchanged between the
mobile node and the home agent, as described in Sections 10.3.1,		mobile node and the home agent, as described in Sections 10.3.1,
10.3.2, 11.7.1, and 11.7.3 of the base specification [8].		10.3.2, 11.7.1, and 11.7.3 of the base specification [8].
Skipping to change at page 5, line 35:
The nodes may also optionally protect payload traffic passing through		The nodes may also optionally protect payload traffic passing through
the home agent, as described in Section 5.3 of the base specification		the home agent, as described in Section 5.3 of the base specification
[8]. If multicast group membership control protocols or stateful		[8]. If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data		address autoconfiguration protocols are supported, payload data
protection support is required.		protection support is required.
The control traffic between the mobile node and the home agent		The control traffic between the mobile node and the home agent
requires message authentication, integrity, correct ordering and		requires message authentication, integrity, correct ordering and
replay protection. The mobile node and the home agent must have a		replay protection. The mobile node and the home agent must have a
security association to protect this traffic. Furthermore, great		security association to protect this traffic. In addition, Mobile
care is needed when using IKE [5] to establish security associations		IPv6 messages assist in ensuring correct ordering, as IPsec can only
to Mobile IPv6 home agents. The right kind of addresses must be used		provide protection against replayed messages. Full protection
for transporting IKE. This is necessary to avoid circular		against replay and ordering attacks is possible only when IKE is
dependencies in which the use of a Binding Update triggers the need		used, however.
for an IKE exchange that cannot complete prior to the Binding Update
having been completed.		Great care is needed when using IKE [5] to establish security
		associations to Mobile IPv6 home agents. The right kind of addresses
		must be used for transporting IKE. This is necessary to avoid
		circular dependencies in which the use of a Binding Update triggers
		the need for an IKE exchange that cannot complete prior to the
		Binding Update having been completed.
The mobile IPv6 base document defines the main requirements the		The mobile IPv6 base document defines the main requirements the
mobile nodes and home agents must follow when securing the above		mobile nodes and home agents must follow when securing the above
traffic. This document discusses these requirements in more depth,		traffic. This document discusses these requirements in more depth,
illustrates the used packet formats, describes suitable configuration		illustrates the used packet formats, describes suitable configuration
procedures, and shows how implementations can process the packets in		procedures, and shows how implementations can process the packets in
the right order.		the right order.
We begin our description by showing the required wire formats for the		We begin our description by showing the required wire formats for the
protected packets in Section 3. Section 4 describes rules which		protected packets in Section 3. Section 4 describes rules which
Skipping to change at page 8, line 17:
3.1 Binding Updates and Acknowledgements		3.1 Binding Updates and Acknowledgements
When the mobile node is away from its home, the BUs sent by it to the		When the mobile node is away from its home, the BUs sent by it to the
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 in transport mode
Mobility header		Mobility header
Binding Update		Binding Update
Alternate Care-of Address option (care-of address)		Alternate Care-of Address option (care-of address)
Note that the Alternate Care-of Address option is used to ensure that		Note that the Alternate Care-of Address option is used to ensure that
the care-of address is protected by ESP. The home agent considers		the care-of address is protected by ESP. The home agent considers
the address within this option as the current care-of address for the		the address within this option as the current care-of 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 support 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 in transport mode
Mobility header		Mobility header
Binding Acknowledgement		Binding Acknowledgement
When the mobile node is at home, the above rules are different as the		When the mobile node is at home, the above rules are different as the
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 in transport mode
Mobility header		Mobility header
Binding Update		Binding Update
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 in transport mode
Mobility header		Mobility header
Binding Acknowledgement		Binding Acknowledgement
3.2 Return Routability Signaling		3.2 Return Routability Signaling
When the Home Test Init messages tunneled to the home agent are		When the Home Test Init messages tunneled to the home agent are
protected by IPsec, they MUST support at least the following headers		protected by IPsec, they MUST support at least the following headers
in the following order:		in the following order:
IPv6 header (source = care-of address,		IPv6 header (source = care-of address,
destination = home agent)		destination = home agent)
ESP header		ESP header in tunnel mode
IPv6 header (source = home address,		IPv6 header (source = home address,
destination = correspondent node)		destination = correspondent node)
Mobility Header		Mobility Header
Home Test Init		Home Test Init
This format assumes that the mobile node's current care-of address is		This format assumes that the mobile node's current care-of address is
used as one of the gateway addresses in the security association. As		used as one of the gateway addresses in the security association. As
discussed in Section 4.3, this requires the home agent to update the		discussed in Section 4.3, this requires the home agent to update the
gateway address when the mobile node moves. Policy entries and		gateway address when the mobile node moves. Policy entries and
security association selectors stay the same, however, as the inner		security association selectors stay the same, however, as the inner
Skipping to change at page 9, line 44:
additional Home Address destination option and/or Routing header to		additional Home Address destination option and/or Routing header to
the packets. The basis for requiring support for at least the		the packets. The basis for requiring support for at least the
care-of address case has been discussed in Section 7.		care-of address case has been discussed in Section 7.
Similarly, when the Home Test messages tunneled from the home agent		Similarly, when the Home Test messages tunneled from the home agent
are protected by IPsec, they MUST support at least the following		are protected by IPsec, they MUST support at least the following
headers in the following order:		headers in the following order:
IPv6 header (source = home agent,		IPv6 header (source = home agent,
destination = care-of address)		destination = care-of address)
ESP header		ESP header in tunnel mode
IPv6 header (source = correspondent node,		IPv6 header (source = correspondent node,
destination = home address)		destination = home address)
Mobility Header		Mobility Header
Home Test		Home Test
The format used to protect return routability packets relies on the		The format used to protect return routability packets relies on the
destination of the tunnel packets to change for the mobile node as it		destination of the tunnel packets to change for the mobile node as it
moves. The home agent's address stays the same, but the mobile		moves. The home agent's address stays the same, but the mobile
node's address changes upon movements, as if the security		node's address changes upon movements, as if the security
association's tunnel gateway address had changed. When the mobile		association's tunnel gateway address had changed. When the mobile
Skipping to change at page 10, line 30:
agent has stored the previous care-of address in its Security		agent has stored the previous care-of address in its Security
Association Database as the gateway address. When IKE is being used,		Association Database as the gateway address. When IKE is being used,
the mobile node runs it on top of its then current care-of address,		the mobile node runs it on top of its then current care-of address,
and the resulting tunnel-mode security associations will use the same		and the resulting tunnel-mode security associations will use the same
addresses as IKE was transported on. In order for the home agent to		addresses as IKE was transported on. In order for the home agent to
be able to tunnel a Home Test message to the mobile node, it uses the		be able to tunnel a Home Test message to the mobile node, it uses the
current care-of address as the destination of the tunnel packets, as		current care-of address as the destination of the tunnel packets, as
if the home agent had modified the gateway address of the security		if the home agent had modified the gateway address of the security
association used for this protection. This implies that the same		association used for this protection. This implies that the same
security association can be used in multiple locations, and no new		security association can be used in multiple locations, and no new
configuration or IKE rekeying is needed per movement.		configuration or IKE rekeying is needed per movement. Section 5.2.2
		discusses the security policy and security association database
		entries that are needed to accomplish this.
3.3 Prefix Discovery		3.3 Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefixes		If IPsec is used to protect prefix discovery, requests for prefixes
from the mobile node to the home agent MUST support at least the		from the mobile node to the home agent MUST support at least the
following headers in the following order.		following headers in the 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 in transport mode
ICMPv6		ICMPv6
Mobile Prefix Solicitation		Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix information		Again if IPsec is used, solicited and unsolicited prefix information
advertisements from the home agent to the mobile node MUST support at		advertisements from the home agent to the mobile node MUST support at
least the following headers in the following order.		least the following headers in the 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 in transport mode
ICMPv6		ICMPv6
Mobile Prefix Advertisement		Mobile Prefix Advertisement
3.4 Payload Packets		3.4 Payload Packets
If IPsec is used to protect payload packets tunneled to the home		If IPsec is used to protect payload packets tunneled to the home
agent from the mobile node, a similar format is used as in the case		agent from the mobile node, a similar format is used as in the case
of tunneled Home Test Init messages. However, instead of the		of tunneled Home Test Init messages. However, instead of the
Mobility Header these packets may contain any legal IPv6 protocol(s):		Mobility Header these packets may contain any legal IPv6 protocol(s):
IPv6 header (source = care-of address,		IPv6 header (source = care-of address,
destination = home agent)		destination = home agent)
ESP header		ESP header in tunnel mode
IPv6 header (source = home address,		IPv6 header (source = home address,
destination = correspondent node)		destination = correspondent node)
Any protocol		Any protocol
Similarly, when the payload packets are tunneled from the home agent		Similarly, when the payload packets are tunneled from the home agent
to the mobile node with IPsec protection, they MUST support at least		to the mobile node with IPsec protection, they MUST support at least
the following headers in the following order:		the following headers in the following order:
IPv6 header (source = home agent,		IPv6 header (source = home agent,
destination = care-of address)		destination = care-of address)
ESP header		ESP header in tunnel mode
IPv6 header (source = correspondent node,		IPv6 header (source = correspondent node,
destination = home address)		destination = home address)
Any protocol		Any protocol
4. Requirements		4. Requirements
This section describes mandatory rules for all Mobile IPv6 mobile		This section describes mandatory rules for all Mobile IPv6 mobile
nodes and home agents. These rules are necessary in order for it to		nodes and home agents. These rules are necessary in order for it to
be possible to enable IPsec communications despite movements,		be possible to enable IPsec communications despite movements,
guarantee sufficient security, and to ensure correct processing order		guarantee sufficient security, and to ensure correct processing order
Skipping to change at page 13, line 11:
4.2 Policy Requirements		4.2 Policy Requirements
The following requirements apply to both home agents and mobile		The following requirements apply to both home agents and mobile
nodes:		nodes:
o When a packet is matched against IPsec security policy or		o When a packet 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 MUST be considered as the source		Home Address destination option MUST be considered as the source
address of the packet.		address of the packet.
		Note that the home address option appears before IPsec headers.
		Section 11.3.2 of the base specification [8] describes one
		possible implementation approach for this: The IPsec policy
		operations can be performed at the time when the packet has not
		yet been modified per Mobile IPv6 rules.
o Similarly, a home address within a Type 2 Routing header MUST be		o Similarly, a home address within a Type 2 Routing header MUST be
considered as the destination address of the packet, when a packet		considered as the destination address of the packet, when a packet
is matched against IPsec security policy or selectors of a		is matched against IPsec security policy or selectors of a
security association.		security association.
		Similar implementation considers apply to the Routing header
		processing as was described above for the Home Address destination
		option.
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 security policy database entries SHOULD be		payload packets, the security policy database entries SHOULD be
defined as if they were specifically for the tunnel interface		defined as if they were specifically for the tunnel interface
between the mobile node and the home agent. That is, the policy		between the mobile node and the home agent. That is, the policy
entries are not generally applied on all traffic on the physical		entries are not generally applied on all traffic on the physical
interface(s) of the nodes, but rather only on traffic that enters		interface(s) of the nodes, but rather only on traffic that enters
this tunnel.		this tunnel.
Note that this requirement is similar to the approach taken in		Note that this requirement is similar to the approach taken in
dynamically routed VPNs [14].		dynamically routed VPNs [14].
Skipping to change at page 13, line 39:
typically allow all users of a node to use any of the IP addresses		typically allow all users of a node to use any of the IP addresses
assigned to the node. This limits the capability of the home		assigned to the node. This limits the capability of the home
agent to restrict the use of a home address to a particular user		agent to restrict the use of a home address to a particular user
in such environment. Where user credentials are applied in a		in such environment. Where user credentials are applied in a
multi-user environment, the configuration should authorize all		multi-user environment, the configuration should authorize all
users of the node to control all home addresses assigned to the		users of the node to control all home addresses assigned to the
node.		node.
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 SPD entries, which were used		care-of address is torn down. The security policy entries, which
for protecting tunneled traffic between the mobile node and the		were used for protecting tunneled traffic between the mobile node
home agent become inactive. The corresponding security		and the home agent MUST be made inactive (for instance, by
associations could be stored or deleted depending on how they were		removing them and installing them back later through an API). The
created. If the security associations were created dynamically		corresponding security associations could be kept as they are or
using IKE, they are automatically deleted when they expire. If		deleted depending on how they were created. If the security
the security associations were created through manual		associations were created dynamically using IKE, they are
configuration, they MUST be retained and used later when the		automatically deleted when they expire. If the security
mobile node moves aways from home again. The security		associations were created through manual configuration, they MUST
associations protecting Binding Updates and Acknowledgements, and		be retained and used later when the mobile node moves aways from
prefix discovery SHOULD not be deleted as they do not depend on		home again. The security associations protecting Binding Updates
care-of addresses and can be used again.		and Acknowledgements, and prefix discovery SHOULD not be deleted
		as they do not depend on care-of addresses and can be used again.
The following rules apply to mobile nodes:		The following rules apply to mobile nodes:
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, sent to the home
agent from a care-of address.		agent from a care-of address.
o When the mobile node receives a changed set of prefixes from the		o When the mobile node receives a changed set of prefixes from the
home agent during prefix discovery, there is a need to configure		home agent during prefix discovery, there is a need to configure
new security policy entries, and there may be a need to configure		new security policy entries, and there may be a need to configure
Skipping to change at page 15, line 9:
The following requirements apply to both home agents and mobile		The following requirements apply to both home agents and mobile
nodes:		nodes:
o When securing Binding Updates, Binding Acknowledgements, and		o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents MUST		prefix discovery, both the mobile nodes and the home agents MUST
support and SHOULD use the Encapsulating Security Payload (ESP)		support and SHOULD use the Encapsulating Security Payload (ESP)
[4] header in transport mode and MUST use a non-null payload		[4] 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.
Note that Authentication Header (AH) [3] is also possible but for		Note that Authentication Header (AH) [3] may also be possible but
brevity is not discussed in this specification.		for brevity is not discussed in this specification.
Mandatory support for encryption and integrity protection		Mandatory support for encryption and integrity protection
algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC		algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC
2406 [4]. Care is needed when selecting suitable encryption		2406 [4]. Care is needed when selecting suitable encryption
algorithms for ESP, however. Currently available integrity		algorithms for ESP, however. Currently available integrity
protection algorithms are in general considered to be secure. The		protection algorithms are in general considered to be secure. The
encryption algorithm, DES, mandated by the current IPsec standards		encryption algorithm, DES, mandated by the current IPsec standards
is not, however. This is particularly problematic when security		is not, however. This is particularly problematic when security
associations are configured manually, as the same key is used for		associations are configured manually, as the same key is used for
a long time.		a long time.
This document makes the non-normative recommendation of using the		This document makes the non-normative recommendation of using the
HMAC_SHA1 and AES CBC algorithms [9][12].		HMAC_SHA1 and AES CBC algorithms [9][12].
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 authentication		procedure. A non-null encryption transform and authentication
algorithm MUST be applied.		algorithm MUST be applied.
		Note that the return routability procedure involves two message
		exchanges from the mobile node to the corresspondent node. The
		purpose of these exchanges is to assure that the mobile node is
		live at the claimed home and care-of addresses. One of the
		exchanges is sent directly to and from the correspondent node,
		while another one is tunneled through the home agent. If an
		attacker is on the mobile node's link and the mobile node's
		current link is an unprotected wireless link, the attacker would
		able to see both sets of messages, and launch attacks based on it
		(these attacks are discussed further in Section 15.4 of the base
		specification [8]. One can prevent the attack by making sure that
		the packets tunneled through the home agent are encrypted.
Note that this specification concerns itself only with on-the-wire		Note that this specification concerns itself only with on-the-wire
formats, and does not dictate specific implementations mechanisms.		formats, and does not dictate specific implementations mechanisms.
In the case of IPsec tunnel mode, the use of IP-in-IP		In the case of IPsec tunnel mode, the use of IP-in-IP
encapsulation followed by IPsec transport mode encapsulation may		encapsulation followed by IPsec transport mode encapsulation may
also be possible. The tradeoffs related to the use of tunnel mode		also be possible. The tradeoffs related to the use of tunnel mode
and IP-in-IP encapsulation have been discussed in [14].		and IP-in-IP encapsulation have been discussed in [14].
o IPsec AH [3] authenticator calculation MUST be performed as if a		o IPsec AH [3] authenticator calculation MUST be performed as if a
packet with a Type 2 Routing header would have the home address in		packet with a Type 2 Routing header would have the home address in
the IPv6 destination address field and the care-of address in the		the IPv6 destination address field and the care-of address in the
Skipping to change at page 16, line 49:
routability, or open access to an API from any application may		routability, or open access to an API from any application may
result in security vulnerabilities.		result in security vulnerabilities.
4.4 Dynamic Keying		4.4 Dynamic Keying
The following requirements apply to both home agents and mobile		The following requirements apply to both home agents and mobile
nodes:		nodes:
o If replay protection is required, dynamic keying MUST be used.		o If replay protection is required, dynamic keying MUST be used.
IPsec can provide replay protection only if dynamic keying is		IPsec can provide replay protection only if dynamic keying is
used. This may not always be possible, and manual keying would be		used. Dynamic keying may not always be available. IPsec also
preferred in some cases. IPsec also does not guarantee correct		does not guarantee correct ordering of packets, only that they
ordering of packets, only that they have not been replayed.		have not been replayed. Because of this, sequence numbers within
Because of this, sequence numbers within the Mobile IPv6 messages		the Mobile IPv6 messages ensure correct ordering. However, if a
ensure correct ordering. However, if a home agent reboots and		home agent reboots and loses its state regarding the Mobile IPv6
loses its state regarding the sequence numbers, replay attacks		sequence numbers, replay attacks become possible. Dynamic IPsec
become possible. The use of a key management mechanism together		keying can be used to prevent such attacks.
with IPsec can be used to prevent such replay attacks.
o If IKE version 1 is used with preshared secrets in main mode, it		o If IKE version 1 is used with preshared secrets in main mode, it
determines the shared secret to use from the IP address of the		determines the shared secret to use from the IP address of the
peer. With Mobile IPv6, however, this may be a care-of address		peer. With Mobile IPv6, however, this may be a care-of address
and does not indicate which mobile node attempts to contact the		and does not indicate which mobile node attempts to contact the
home agent. Therefore, if preshared secret authentication is used		home agent. Therefore, if preshared secret authentication is used
in IKEv1 between the mobile node and the home agent then		in IKEv1 between the mobile node and the home agent then
aggressive mode MUST be used. Note also that care needs to be		aggressive mode MUST be used. Note also that care needs to be
taken with phase 1 identity selection. Where the ID_IPV6_ADDR		taken with phase 1 identity selection. Where the ID_IPV6_ADDR
Identity Payloads is used, unambiguous mapping of identities to		Identity Payloads is used, unambiguous mapping of identities to
Skipping to change at page 17, line 33:
Note that the difficulties with main mode and preshared secrets in		Note that the difficulties with main mode and preshared secrets in
IKE version 1 are well known for dynamic addresses. With static		IKE version 1 are well known for dynamic addresses. With static
addresses, there has not been a problem. With Mobile IPv6,		addresses, there has not been a problem. With Mobile IPv6,
however, the use of the care-of addresses to run IKE towards the		however, the use of the care-of addresses to run IKE towards the
home agent presents a problem even when the home address stays		home agent presents a problem even when the home address stays
stable. Further discussion about the use of care-of addresses in		stable. Further discussion about the use of care-of addresses in
this way appears in Section 7.		this way appears in Section 7.
The following rules apply to mobile nodes:		The following rules apply to mobile nodes:
o Where dynamic keying is used, the key management protocol MUST use		o In addition to the rules above, if dynamic keying is used, the key
the care-of address as the source address in the protocol		management protocol MUST use the care-of address as the source
exchanges with the mobile node's home agent.		address in the protocol exchanges with the mobile node's home
		agent.
o However, the IPsec security associations with the mobile node's		o However, the IPsec security associations with the mobile node's
home agent use home addresses. That is, the IPsec security		home agent use home addresses. That is, the IPsec security
associations MUST be requested from the key management protocol		associations MUST be requested from the key management protocol
using the home address of the mobile node as the client identity.		using the home address of the mobile node as the client identity.
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. No
Similarly, the security associations for protecting prefix		other selectors are used. Similarly, the security associations
discovery are requested for the ICMPv6 protocol. Security		for protecting prefix discovery are requested for the ICMPv6
associations for payload and return routability protection are		protocol and the specific IP addresses, again without other
requested for a specific tunnel interface and either the payload		selectors. Security associations for payload and return
protocol or the Mobility header protocol, in tunnel mode. In this		routability protection are requested for a specific tunnel
case one requested endpoint is an IP address and another one is a		interface and either the payload protocol or the Mobility header
wildcard.		protocol, in tunnel mode. In this case one requested endpoint is
		an IP address and the other one is a wildcard, and there are no
o If the mobile node has used IKE to establish security associations		other selectors.
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		o If the mobile node has used IKE version 1 to establish security
whether the IKE endpoints can be moved or if rekeying is needed.		associations with its home agent, it should follow the procedures
		discussed in Section 11.7.1 and 11.7.3 of the base specification
		[8] to determine 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 version 1 to establish security
with the mobile node, it should follow the procedures discussed in		associations with the mobile node, it should follow the procedures
Section 10.3.1 and 10.3.2 of the base specification to determine		discussed in Section 10.3.1 and 10.3.2 of the base specification
whether the IKE endpoints can be moved or if rekeying is needed.		[8] to determine whether the IKE endpoints can be moved or if
		rekeying is needed.
5. Example Configurations		5. Example Configurations
In the following we describe the Security Policy Database (SPD) and		In the following we describe the Security Policy Database (SPD) and
Security Association Database (SAD) entries necessary to protect		Security Association Database (SAD) entries necessary to protect
Binding Updates and Binding Acknowledgements exchanged between the		Binding Updates and Binding Acknowledgements exchanged between the
mobile node and the home agent. Our examples assume the use of ESP,		mobile node and the home agent. Our examples assume the use of ESP,
but a similar configuration could also be used to protect the		but a similar configuration could also be used to protect the
messages with AH.		messages with AH.
Skipping to change at page 20, line 12:
...		...
"-" <sadentry>		"-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has the		Where <node> represents the name of the node, and <sadentry> has the
following format:		following format:
<sa> "(" <dir> ","		<sa> "(" <dir> ","
<spi> ","		<spi> ","
<destination> ","		<destination> ","
<ahesp> ","		<ahesp> ","
<mode> ")" ":"		<mode> ")" ":"
<selectors>		<rule>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security		Where <dir> is "IN" or "OUT", <spi> is the SPI of the security
association, <destination> is its destination, <ahesp> is normally		association, <destination> is its destination, <ahesp> is normally
"ESP" in our case but could also be "AH", <mode> is either "TUNNEL"		"ESP" in our case but could also be "AH", <mode> is either "TUNNEL"
or "TRANSPORT", and <selectors> is a boolean expression about the		or "TRANSPORT", and <rule> is an expression which describes the IPsec
fields of the IPv6 packet.		selectors, i.e., which fields of the IPv6 packet must have which
		values.
We will be using an example mobile node in this section with the home		We will be using an example mobile node in this section with the home
address "home_address_1". The user's identity in this mobile node is		address "home_address_1". The user's identity in this mobile node is
"user_1". The home agent's address is "home_agent_1".		"user_1". The home agent's address is "home_agent_1".
5.2 Manual Configuration		5.2 Manual Configuration
5.2.1 Binding Updates and Acknowledgements		5.2.1 Binding Updates and Acknowledgements
Here are the contents of the SPD and SAD for protecting Binding		Here are the contents of the SPD and SAD for protecting Binding
Skipping to change at page 21, line 49:
proto = MH		proto = MH
In the above, "MH" refers to the protocol number for the Mobility		In the above, "MH" refers to the protocol number for the Mobility
Header [8].		Header [8].
5.2.2 Return Routability Signaling		5.2.2 Return Routability Signaling
In the following we describe the necessary SPD and SAD entries to		In the following we describe the necessary SPD and SAD entries to
protect return routability signaling between the mobile node and the		protect return routability signaling between the mobile node and the
home agent. Note that the rules in the SPD are ordered, and the ones		home agent. Note that the rules in the SPD are ordered, and the ones
in the previous section must take precedence over these ones:		in the previous section must take precedence over these ones. In
		other words, the higher precedence entries must occur first in the
		RFC 2401 [2] ordered list of SPD entries.
mobile node SPD OUT:		mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &		- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &		source = home_address_1 & destination = any &
proto = MH		proto = MH
THEN USE SA3		THEN USE SA3
mobile node SPD IN:		mobile node SPD IN:
- IF interface = tunnel from home_agent_1 &		- IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 &		source = any & destination = home_address_1 &
Skipping to change at page 25, line 45:
home agent SPD IN:		home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &		- IF source = home_address_1 & destination = home_agent_1 &
proto = MH		proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1		THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the above, and		We have omitted details of the proposed transforms in the above, and
all details related to the particular authentication method such as		all details related to the particular authentication method such as
certificates beyond listing a specific identity that must be used.		certificates beyond listing a specific identity that must be used.
We require IKE to be run using the care-of addresses but still		We require IKE version 1 to be run using the care-of addresses but
negotiate IPsec SAs that use home addresses. The extra conditions		still negotiate IPsec SAs that use home addresses. The extra
set by the home agent SPD for the peer phase 1 identity to be		conditions set by the home agent SPD for the peer phase 1 identity to
"user_1" must be verified by the home agent. The purpose of the		be "user_1" must be verified by the home agent. The purpose of the
condition is to ensure that the IKE phase 2 negotiation for a given		condition is to ensure that the IKE phase 2 negotiation for a given
user's home address can't be requested by another user. In the		user's home address can't be requested by another user. In the
mobile node, we simply set our local identity to be "user_1".		mobile node, we simply set our local identity to be "user_1".
These checks also imply that the configuration of the home agent is		These checks also imply that the configuration of the home agent is
user-specific: every user or home address requires a specific		user-specific: every user or home address requires a specific
configuration entry. It would be possible to alleviate the		configuration entry. It would be possible to alleviate the
configuration tasks by using certificates that have home addresses in		configuration tasks by using certificates that have home addresses in
the Subject AltName field. However, it isn't clear if all IKE		the Subject AltName field. However, it isn't clear if all IKE
implementations allow one address to be used for carrying the IKE		implementations allow one address to be used for carrying the IKE
negotiations when another address is mentioned in the used		negotiations when another address is mentioned in the used
certificates. In any case, even this approach would have required		certificates. In any case, even this approach would have required
user-specific tasks in the certificate authority.		user-specific tasks in the certification authority.
5.3.2 Return Routability Signaling		5.3.2 Return Routability Signaling
Protection for the return routability signaling can be configured in		Protection for the return routability signaling can be configured in
a similar manner as above.		a similar manner as above.
mobile node SPD OUT:		mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 &		- IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any &		source = home_address_1 & destination = any &
proto = MH		proto = MH
Skipping to change at page 29, line 17:
6.1 Binding Update to the Home Agent		6.1 Binding Update to the Home Agent
Step 1. At the mobile node, Mobile IPv6 module first produces the		Step 1. At the mobile node, Mobile IPv6 module first produces the
following packet:		following packet:
IPv6 header (source = home address,		IPv6 header (source = home address,
destination = home agent)		destination = home agent)
Mobility header		Mobility header
Binding Update		Binding Update
Step 2. This packet is matched against the IPsec policy data base on		Step 2. This packet is matched against the IPsec SPD on the mobile
the mobile node and we make a note that IPsec must be applied.		node and we make a note that IPsec must be applied.
Step 3. Then, we add the necessary Mobile IPv6 options but do not		Step 3. Then, we add the necessary Mobile IPv6 options but do not
change the addresses yet, as described in Section 11.2.2 of the base		change the addresses yet, as described in Section 11.2.2 of the base
specification [8]. This results in:		specification [8]. This results in:
IPv6 header (source = home address,		IPv6 header (source = home address,
destination = home agent)		destination = home agent)
Destination Options header		Destination Options header
Home Address option (care-of address)		Home Address option (care-of address)
Mobility header		Mobility header
Skipping to change at page 29, line 42:
authenticator values are calculated:		authenticator values are calculated:
IPv6 header (source = home address,		IPv6 header (source = home address,
destination = home agent)		destination = home agent)
Destination Options header		Destination Options header
Home Address option (care-of address)		Home Address option (care-of address)
ESP header (SPI = spi_a)		ESP header (SPI = spi_a)
Mobility header		Mobility header
Binding Update		Binding Update
		Here spi_a is the SPI value that was either configured manually, or
		agreed upon in an earlier IKE negotiation.
Step 5. Before sending the packet, the addresses in the IPv6 header		Step 5. Before sending the packet, the addresses in the IPv6 header
and the Destination Options header are changed:		and the Destination Options header are changed:
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 (SPI = spi_a)		ESP header (SPI = spi_a)
Mobility header		Mobility header
Binding Update		Binding Update