document does not address the issues related to them.
o ESP encapsulation of Binding Updates and Acknowledgements between
the mobile node and home agent MUST be supported and MUST be used.
o ESP encapsulation of the Home Test Init and Home Test messages
tunneled between the mobile node and home agent MUST be supported
and SHOULD be used.
o ESP encapsulation of the ICMPv6 messages related to prefix
discovery MUST be supported and SHOULD be used.
o ESP encapsulation of the payload packets tunneled between the
mobile node and home agent MAY be supported and used.
o If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data
protection MUST be supported for those protocols.
4.2. Policy Requirements
The following requirements apply to both home agents and mobile
nodes:
o As required in the base specification [7], when a packet destined
to the receiving node is matched against IPsec security policy or
selectors of a security association, an address appearing in a
Home Address destination option is considered as the source
address of the packet.
Note that the home address option appears before IPsec headers.
Section 11.3.2 of the base specification 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, or has been brought back to its normal form
after Mobile IPv6 processing. That is, the processing of the Home
Address option is seen as a fixed transformation of the packets
that does not affect IPsec processing.
o Similarly, a home address within a Type 2 Routing header destined
to the receiving node is considered as the destination address of
the packet, when a packet is matched against IPsec security policy
or selectors of a 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
payload packets, this protection MUST only be applied to the
return routability packets entering the IPv6 encapsulated tunnel
interface between the mobile node and the home agent. This can be
achieved, for instance, by defining the security policy database
entries specifically for the tunnel interface. That is, the
policy entries are not generally applied on all traffic on the
physical interface(s) of the nodes, but rather only on traffic
that enters this tunnel.
o The authentication of mobile nodes MAY be based either on machine
or user credentials. Note that multi-user operating systems
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
agent to restrict the use of a home address to a particular user
in such environment. Where user credentials are applied in a
multi-user environment, the configuration should authorize all
users of the node to control all home addresses assigned to the
node.
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
care-of address is torn down. The security policy entries, which
were used for protecting tunneled traffic between the mobile node
and the home agent MUST be made inactive (for instance, by
removing them and installing them back later through an API). The
corresponding security associations could be kept as they are or
deleted depending on how they were created. If the security
associations were created dynamically using IKE, they are
automatically deleted when they expire. If the security
associations were created through manual configuration, they MUST
be retained and used later when the mobile node moves away from
home again. The security associations protecting Binding Updates
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:
o The mobile node MUST use the Home Address destination option in
Binding Updates and Mobile Prefix Solicitations, sent to the home
agent from a care-of address.
o When the mobile node receives a changed set of prefixes from the
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 associations. It is outside the scope of this
specification to discuss automatic methods for this.
The following rules apply to home agents:
o The home agent MUST use the Type 2 Routing header in Binding
Acknowledgements and Mobile Prefix Advertisements sent to the
mobile node, again due to the need to have the home address
visible when the policy checks are made.
o It is necessary to avoid the possibility that a mobile node could
use its security association to send a Binding Update on behalf of
another mobile node using the same home agent. In order to do
this, the security policy database entries MUST unequivocally
identify a single security association for protecting Binding
Updates between any given home address and home agent when
manually keyed IPsec security associations are used. When dynamic
keying is used, the security policy database entries MUST
unequivocally identify the IKE phase 1 credentials which can be
used to authorize the creation of security associations for
protecting Binding Updates for a particular home address. How
these mappings are maintained is outside the scope of this
specification, but they may be maintained, for instance, as a
locally administered table in the home agent. If the phase 1
identity is a Fully Qualified Domain Name (FQDN), secure forms of
DNS may also be used.
o When the set of prefixes advertised by the home agent changes,
there is a need to configure new security policy entries, and
there may be a need to configure new security associations. It is
outside the scope of this specification to discuss automatic
methods for this, if new home addresses are required.
4.3. IPsec Protocol Processing
The following requirements apply to both home agents and mobile
nodes:
o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents MUST
support and SHOULD use the Encapsulating Security Payload (ESP)
[3] header in transport mode and MUST use a non-null payload
authentication algorithm to provide data origin authentication,
connectionless integrity and optional anti-replay protection.
Mandatory support for encryption and integrity protection
algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC
2406 [3]. Care is needed when selecting suitable encryption
algorithms for ESP, however. Currently available integrity
protection algorithms are in general considered to be secure. The
encryption algorithm, DES, mandated by the current IPsec standards
is not, however. This is particularly problematic when IPsec
security associations are configured manually, as the same key is
used for a long time.
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the
protection of packets belonging to the return routability
procedure. A non-null encryption transform and a non-null
authentication algorithm MUST be applied.
Note that the return routability procedure involves two message
exchanges from the mobile node to the correspondent 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 [7].) 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
formats, and does not dictate specific implementations mechanisms.
In the case of IPsec tunnel mode, the use of IP-in-IP
encapsulation followed by IPsec transport mode encapsulation may
also be possible.
The following rules apply to mobile nodes:
o When ESP is used to protect Binding Updates, there is no
protection for the care-of address which appears in the IPv6
header outside the area protected by ESP. It is important for the
home agent to verify that the care-of address has not been
tampered with. As a result, the attacker would have redirected
the mobile node’s traffic to another address. In order to prevent
this, Mobile IPv6 implementations MUST use the Alternate Care-of
Address mobility option in Binding Updates sent by mobile nodes
while away from home. The exception to this is when the mobile
node returns home and sends a Binding Update to the home agent in
order to de-register. In this case no Alternate Care-of Address
option is needed, as described in Section 3.1.
When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it
uses for the outgoing tunnel packets to the current primary care-
of address. The mobile node starts to use a new primary care-of
address immediately after sending a Binding Update to the home
agent to register this new address. Similarly, it starts to use
the new address as the required destination address of tunneled
packets received from the home agent.
The following rules apply to home agents:
o When IPsec is used to protect return routability signaling or
payload packets, IPsec security associations are needed to provide
this protection. When the care-of address for the mobile node
changes as a result of an accepted Binding Update, special
treatment is needed for the next packets sent using these security
associations. The home agent MUST set the new care-of address as
the destination address of these packets, as if the outer header
destination address in the security association had changed.
Similarly, the home agent starts to expect the new source address
in the tunnel packets received from the mobile node.
Such address changes can be implemented, for instance, through an
API from the Mobile IPv6 implementation to the IPsec
implementation. It should be noted that the use of such an API
and the address changes MUST only be done based on the Binding
Updates received by the home agent and protected by the use of
IPsec. Address modifications based on other sources, such as
Binding Updates to the correspondent nodes protected by return
routability, or open access to an API from any application may
result in security vulnerabilities.
4.4. Dynamic Keying
The following requirements apply to both home agents and mobile
nodes:
o If anti-replay protection is required, dynamic keying MUST be
used. IPsec can provide anti-replay protection only if dynamic
keying is used (which may not always be the case). IPsec also
does not guarantee correct ordering of packets, only that they
have not been replayed. Because of this, sequence numbers within
the Mobile IPv6 messages are used to ensure correct ordering.
However, if the 16 bit Mobile IPv6 sequence number space is cycled
through, or the home agent reboots and loses its state regarding
the sequence numbers, replay and reordering attacks become
possible. The use of dynamic keying, IPsec anti-replay
protection, and the Mobile IPv6 sequence numbers can together
prevent such attacks.
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
peer. With Mobile IPv6, however, this may be a care-of address
and does not indicate which mobile node attempts to contact the
home agent. Therefore, if preshared secret authentication is used
in IKEv1 between the mobile node and the home agent then
aggressive mode MUST be used. Note also that care needs to be
taken with phase 1 identity selection. Where the ID_IPV6_ADDR
Identity Payloads is used, unambiguous mapping of identities to
keys is not possible. (The next version of IKE may not have these
limitations.)
Note that the difficulties with main mode and preshared secrets in
IKE version 1 are well known for dynamic addresses. With static
addresses, there has not been a problem. With Mobile IPv6, however,
the use of the care-of addresses to run IKE to the home agent
presents a problem even when the home address stays stable. Further
discussion about the use of care-of addresses in this way appears in
Section 7.
The following rules apply to mobile nodes:
o In addition to the rules above, if dynamic keying is used, the key
management protocol MUST use the care-of address as the source
address in the protocol exchanges with the mobile node’s home
agent.
o However, the IPsec security associations with the mobile node’s
home agent use home addresses. That is, the IPsec security
associations MUST be requested from the key management protocol
using the home address of the mobile node as the client identity.
The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints. No
other selectors are used. Similarly, the security associations
for protecting prefix discovery are requested for the ICMPv6
protocol and the specific IP addresses, again without other
selectors. Security associations for payload and return
routability protection are requested for a specific tunnel
interface and either the payload protocol or the Mobility header
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
other selectors.
o If the mobile node has used IKE version 1 to establish security
associations with its home agent, it should follow the procedures
discussed in Section 11.7.1 and 11.7.3 of the base specification
[7] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
The following rules apply to home agents:
o If the home agent has used IKE version 1 to establish security
associations with the mobile node, it should follow the procedures
discussed in Section 10.3.1 and 10.3.2 of the base specification
[7] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
5. Example Configurations
In the following we describe the Security Policy Database (SPD) and
Security Association Database (SAD) entries necessary to protect
Binding Updates and Binding Acknowledgements exchanged between the
mobile node and the home agent.
Section 5.1 introduces the format we use in the description of the
SPD and the SAD. Section 5.2 describes how to configure manually
keyed IPsec security associations without dynamic keying, and Section
5.3 describes how to use dynamic keying.
5.1. Format
The format used in the examples is as follows. The SPD description
has the format
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has the
following format:
"IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN USE SA " <pattern> |
Where <condition> is a boolean expression about the fields of the
IPv6 packet, <sa> is the name of a specific security association, and
<pattern> is a specification for a security association to be
negotiated via IKE [4]. The SAD description has the format
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has the
following format:
<sa> "(" <dir> ","
<spi> ","
<destination> ","
<ipsec-proto> ","
<mode> ")" ":"
<rule>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security
association, <destination> is its destination, <ipsec-proto> is in
our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule>
is an expression which describes the IPsec 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
address "home_address_1". The user’s identity in this mobile node is
"user_1". The home agent’s address is "home_agent_1".
5.2. Manual Configuration
5.2.1. Binding Updates and Acknowledgements
Here are the contents of the SPD and SAD for protecting Binding
Updates and Acknowledgements:
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA SA2
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA SA1
home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
In the above, "MH" refers to the protocol number for the Mobility
Header [7].
5.2.2. Return Routability Signaling
In the following we describe the necessary SPD and SAD entries to
protect return routability signaling between the mobile node and the
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
other words, the higher precedence entries must occur first in the
RFC 2401 [2] ordered list of SPD entries.
mobile node SPD OUT:
- IF interface = IPv6 IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA SA4
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA SA3
home agent SAD:
- SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH
The security association from the home agent to the mobile node uses
the current care-of address as the destination. As discussed
earlier, this address is updated in the SAD as the mobile node moves.
It can be initialized to the home address before the mobile node has
registered.
5.2.3. Prefix Discovery
In the following we describe some additional SPD and SAD entries to
protect prefix discovery. Note that the SPDs described above protect
all ICMPv6 traffic between the mobile node and the home agent, as
IPsec may not have the ability to distinguish between different
ICMPv6 types.
mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5.
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA SA6
mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &