MN-4-1-1-2-007 - Use IPsec to protect the payload packets between MN and CN
Host
|
R CN0
| |
-----+-------+--------+---------------- LinkZ
|
R2 NUTY
| |
-----+-------+-----------------+------- LinkY
|
R1 NUTX
| |
-----+-------+-----------------+------- LinkX
|
HA0 Node0 NUT0
| | |
----------------------+---------------+---------+------- Link0
| Link0 |
3ffe:501:ffff:100::/64 |
home link |
| LinkX |
3ffe:501:ffff:102::/64 |
|
| LinkY |
3ffe:501:ffff:103::/64 |
|
| LinkZ |
3ffe:501:ffff:104::/64 |
|
| HA0(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a0a0 |
|
| Node0(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a3a3 |
|
| R1(LinkX) |
3ffe:501:ffff:102:200:ff:fe00:a4a4 |
|
| R2(LinkY) |
3ffe:501:ffff:103:200:ff:fe00:a6a6 |
|
| CN0(LinkZ) |
3ffe:501:ffff:104:200:ff:fe00:a8a8 |
|
1. Selection Option
- Route Optimization support : YES
- IPsec support between MN and CN : YES
2. Position of Mobile Node
HA0 NUT0 R1 R2 CN0
| | | | |
| ----> | | | | 1.Router Advertisement
| | | | |
| NUTX | | |
| | | | |
| | <---- | | | 2.Router Advertisement
| | | | |
| <---- | | | | 3.Neighbor Solicitations
| | | | | 4.(no reply:3 seconds)
| | | | |
| <---- | | | | 5.Binding Update
| ----> | | | | 6.Binding Acknowledgement
| | | | |
1. Send Router Advertisement. (HA0 -> HA0_allnode_multi)
2. Send Router Advertisement. (R1 -> R1_allnode_multi)
3. Receive Neighbor Solicitations. (NUT0 -> HA0)
4. (no reply)
# Wait during a maximum of 3 seconds(RFC2461).
5. Receive Binding Update. (NUTX -> HA0)
6. Send Binding Acknowledgement. (HA0 -> NUTX)
HA0 NUTX R1 R2 CN0
| | | | |
| ====> | <--------------------- | 1.ICMP Echo Request
| | | | |
| <==== | ---------------------> | 2.Home Test Init
| | ---------------------> | 3.Care-of Test Init
| | <--------------------- | 4.Care-of Test
| ====> | <--------------------- | 5.Home Test
| | | | |
| <==== | ---------------------> | 6.ICMP Echo Reply
| | ---------------------> | 7.Binding Update
| | ---------------------> | 8.ICMP Echo Reply
| | | | |
| | <--------------------- | 9.ICMP Echo Request
| | ---------------------> | 10.ICMP Echo Reply (*1)
| | | | |
1. Send ICMP Echo Request. (out: HA0 -> NUTX, in: CN0 -> NUT0)
# The ESP Header is included in the inner packet.
2. Receive Home Test Init. (out: NUTX -> HA0, in: NUT0 -> CN0)
3. Receive Care-of Test Init. (NUTX -> CN0)
4. Send Care-of Test. (CN0 -> NUTX)
5. Send Home Test. (out: HA0 -> NUTX, in: CN0 -> NUT0)
6. Receive reverse tunneled ICMP Echo Reply or [8]. (out: NUTX -> HA0, in: NUT0 -> CN0)
# The ESP Header is included in the inner packet.
7. Receive Binding Update to CN0. (NUTX -> CN0)
8. [6] or Receive ICMP Echo Reply. (NUTX -> CN0)
# The ESP Header is included.
# Home Address destination option is included.
9. Send ICMP Echo Request. (CN0 -> NUTX)
# The ESP Header is included.
# Type2 Routing Header is included.
10. Receive ICMP Echo Reply. (NUTX -> CN0)
# The ESP Header is included.
# Home Address destination option is included.
(*1) PASS: CN0 receives ICMP Echo Reply.
Then, check whether this packet fills all of the following,
- The ESP Header is included.
(draft-ietf-mobileip-ipv6-24.txt)
11.3.2 Interaction with Outbound IPsec Processing
This section sketches the interaction between outbound Mobile IPv6
processing and outbound IP Security (IPsec) processing for packets
sent by a mobile node while away from home. Any specific
implementation MAY use algorithms and data structures other than
those suggested here, but its processing MUST be consistent with the
effect of the operation described here and with the relevant IPsec
specifications. In the steps described below, it is assumed that
IPsec is being used in transport mode [4] and that the mobile node is
using its home address as the source for the packet (from the point
of view of higher protocol layers or applications, as described in
Section 11.3.1):
o The packet is created by higher layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IPv6
were not being used.
o Determine the outgoing interface for the packet. (Note that the
selection between reverse tunneling and route optimization may
imply different interfaces, particularly if tunnels are considered
interfaces as well.)
o As part of outbound packet processing in IP, the packet is
compared against the IPsec security policy database to determine
what processing is required for the packet [4].
o If IPsec processing is required, the packet is either mapped to an
existing Security Association (or SA bundle), or a new SA (or SA
bundle) is created for the packet, according to the procedures
defined for IPsec.
o Since the mobile node is away from home, the mobile is either
using reverse tunneling or route optimization to reach the
correspondent node.
If reverse tunneling is used, the packet is constructed in the
normal manner and then tunneled through the home agent.
If route optimization is in use, the mobile node inserts a Home
Address destination option into the packet, replacing the Source
Address in the packet's IP header with the care-of address used
with this correspondent node, as described in Section 11.3.1. The
Destination Options header in which the Home Address destination
option is inserted MUST appear in the packet after the routing
header, if present, and before the IPsec (AH [5] or ESP [6])
header, so that the Home Address destination option is processed
by the destination node before the IPsec header is processed.
Finally, once the packet is fully assembled, the necessary IPsec
authentication (and encryption, if required) processing is
performed on the packet, initializing the Authentication Data in
the IPsec header.
RFC 2402 treatment of destination options is extended as follows.
The AH authentication data MUST be calculated as if the following
were true:
* the IPv6 source address in the IPv6 header contains the mobile
node's home address,
* the Home Address field of the Home Address destination option
(Section 6.3) contains the new care-of address.
o This allows, but does not require, the receiver of the packet
containing a Home Address destination option to exchange the two
fields of the incoming packet to reach the above situation,
simplifying processing for all subsequent packet headers.
However, such an exchange is not required, as long as the result
of the authentication calculation remains the same.
When an automated key management protocol is used to create new
security associations for a peer, it is important to ensure that the
peer can send the key management protocol packets to the mobile node.
This may not be possible if the peer is the home agent of the mobile
node, and the purpose of the security associations would be to send a
Binding Update to the home agent. Packets addressed to the home
address of the mobile node cannot be used before the Binding Update
has been processed. For the default case of using IKE [9] as the
automated key management protocol, such problems can be avoided by
the following requirements when communicating with its home agent:
o When the mobile node is away from home, it MUST use its care-of
address as the Source Address of all packets it sends as part of
the key management protocol (without use of Mobile IPv6 for these
packets, as suggested in Section 11.3.1).
o In addition, for all security associations bound to the mobile
node's home address established by IKE, the mobile node MUST
include an ISAKMP Identification Payload [8] in the IKE exchange,
giving the mobile node's home address as the initiator of the
Security Association [7].
The Key Management Mobility Capability (K) bit in Binding Updates and
Acknowledgements can be used avoid the need to rerun IKE upon
movements.