MN-1-1-2-1-001 - Use the manual configuration of security association between MN and HA
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
- IPsec support between MN and HA : YES
- IPsec key management between MN and HA : manual configuration
2. Position of Mobile Node
- none
HA0 NUT0 R1 R2 CN0
| | | | |
| ----> | | | | 1.Router Advertisement
| | | | |
| NUTX | | |
| | | | |
| | <---- | | | 2.Router Advertisement
| | | | |
| <---- | | | | 3.Neighbor Solicitations(NUD)
| | | | | 4.(no reply)
| | | | |
| <---- | | | | 5.Binding Update
| ----> | | | | 6.Binding Acknowledgement
| | | | |
| NUT0 | | |
| | | | |
| ----> | | | | 7.Router Advertisement
| | | | |
| | ----> | | | 8.Neighbor Solicitations(NUD)
| | | | | 9.(no reply)
| | | | |
| <---- | | | | 10.Binding Update
| ----> | | | | 11.Binding Acknowledgement
| | | | |
| <---- | | | | 12.Neighbor Advertisement
| | | | |
| NUTX | | |
| | | | |
| | <---- | | | 13.Router Advertisement
| | | | |
| <---- | | | | 14.Neighbor Solicitations(NUD)
| | | | | 15.(no reply)
| | | | |
| <---- | | | | 16.Binding Update (*1)
| ----> | | | | 17.Binding Acknowledgement
| | | | | 18.(wait) (*2)
| | | | |
1. Send Router Advertisement. (HA0 -> HA0_allnode_multi)
2. Send Router Advertisement. (R1 -> R1_allnode_multi)
3. Receive Neighbor Solicitations(NUD). (NUT0 -> HA0)
4. (no reply)
# Wait during a maximum of 3 seconds(RFC2461).
5. Receive Binding Update to HA0. (NUTX -> HA0)
6. Send Binding Acknowledgement. (HA0 -> NUTX)
7. Send Router Advertisement. (HA0 -> HA0_allnode_multi)
8. Receive Neighbor Solicitations(NUD). (NUTX -> R1)
9. (no reply)
# Wait during a maximum of 3 seconds(RFC2461).
10. Receive Binding Update to HA0. (NUT0 -> HA0)
11. Send Binding Acknowledgement. (HA0 -> NUT0)
12. Receive Neighbor Advertisement. (NUT0 -> NUT0_allnode_multi)
13. Send Router Advertisement. (R1 -> R1_allnode_multi)
14. Receive Neighbor Solicitations(NUD). (NUT0 -> HA0)
15. (no reply)
# Wait during a maximum of 3 seconds(RFC2461).
16. Receive Binding Update to HA0. (NUTX -> HA0)
17. Send Binding Acknowledgement. (HA0 -> NUTX)
18. (wait)
# Wait during enough retransmission timer.
Packet Format is:
16. Binding Update
17. Binding Acknowledgement
(*1) PASS: HA0 receives Binding Update.
Then, check whether this packet fills all of the following.
- The ESP header is included.
- The Acknowledge(A) bit is set to ON.
- The Home Registration(H) bit is set to ON.
- The Alternate Care-of Address mobility option is included.
- The Care-of Aaddress fiels is set to the care-of address.
(*2) PASS: HA0 does not receive the retransmitting of Binding Update.
(draft-ietf-mobileip-ipv6-24.txt)
11.7.1 Sending Binding Updates to the Home Agent
(snip)
To register a care-of address or to extend the lifetime of an
existing registration, the mobile node sends a packet to its home
agent containing a Binding Update, with the packet constructed as
follows:
o The Home Registration (H) bit MUST be set in the Binding Update.
o The Acknowledge (A) bit MUST be set in the Binding Update.
o The packet MUST contain a Home Address destination option, giving
the mobile node's home address for the binding.
o The care-of address for the binding MUST be used as the Source
Address in the packet's IPv6 header, unless an Alternate Care-of
Address mobility option is included in the Binding Update. This
option MUST be included in all home registrations, as the ESP
protocol will not be able to protect care-of addresses in the IPv6
header. (Mobile IPv6 implementations that know they are using
IPsec AH to protect a particular message might avoid this option.
For brevity the usage of AH is not discussed in this document.)
o If the mobile node's link-local address has the same interface
identifier as the home address for which it is supplying a new
care-of address, then the mobile node SHOULD set the Link-Local
Address Compatibility (L) bit.
o If the home address was generated using RFC 3041 [18], then the
link local address is unlikely to have a compatible interface
identifier. In this case, the mobile node MUST clear the
Link-Local Address Compatibility (L) bit.
o If the IPsec security associations between the mobile node and the
home agent have been established dynamically, and the mobile node
has the capability to update its endpoint in the used key
management protocol to the new care-of address every time it
moves, the mobile node SHOULD set the Key Management Mobility
Capability (K) bit in the Binding Update. Otherwise, the mobile
node MUST clear the bit.
o The value specified in the Lifetime field SHOULD be less than or
equal to the remaining valid lifetime of the home address and the
care-of address specified for the binding.
Mobile nodes that use dynamic home agent address discovery should
be careful with long lifetimes. If the mobile node loses the
knowledge of its binding with a specific home agent, registering a
new binding with another home agent may be impossible as the
previous home agent is still defending the existing binding.
Therefore, mobile nodes that use home agent address discovery
SHOULD ensure information about their bindings is not lost,
de-register before losing this information, or use small
lifetimes.
6.1.7 Binding Update Message
(snip)
Key Management Mobility Capability (K)
If this bit is cleared, the protocol used for establishing the
IPsec security associations between the mobile node and the home
agent does not survive movements. It may then have to be rerun.
(Note that the IPsec security associations themselves are expected
to survive movements.) If manual IPsec configuration is used, the
bit MUST be cleared.
This bit is valid only in Binding Updates sent to the home agent,
and MUST be cleared in other Binding Updates. Correspondent nodes
MUST ignore this bit.
(draft-ietf-mobileip-mipv6-ha-ipsec-06.txt)
4.2 Policy Requirements
(snip)
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 aways 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.