NAME

MN-4-1-1-2-007 - Use IPsec to protect the payload packets between MN and CN


TARGET

Host


TOPOLOGY

                    
                                  |
                                  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  


INITIALIZATION

 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)


TEST PROCEDURE

                    
       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.
                    


JUDGEMENT

 (*1) PASS: CN0 receives ICMP Echo Reply.
            Then, check whether this packet fills all of the following,
             - The ESP Header is included.


REFERENCE

                    
(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.