[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3776

     Network Working Group                                       Jari Arkko
     INTERNET-DRAFT                                                Ericsson
     Category: Standards Track                            Vijay Devarapalli
     <draft-ietf-mobileip-mipv6-ha-ipsec-01.txt>                      Nokia
                                                             Francis Dupont
                                                              ENST Bretagne
     15 October 2002



           Using IPsec to Protect Mobile IPv6 Signaling between
                       Mobile Nodes and Home Agents


1.  Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026. Internet-Drafts are
     working documents of the Internet Engineering Task Force (IETF),
     its areas, and its working groups.  Note that other groups may
     also distribute working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or made obsolete by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as work
     in progress.

     The list of current Internet-Drafts may be found at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories may be found at
     http://www.ietf.org/shadow.html.

     The distribution of this memo is unlimited.  It is filed as
     <draft-ietf-mobileip-mipv6-haipsec-00.txt>, and  expires March
     10, 2003.  Please send comments to the author or to the Mobile IP
     working group mailing list.

2.  Abstract

     Mobile IPv6 uses IPsec to protect signaling between the home
     agent and the mobile node. Mobile IPv6 base document defines the
     main requirements these nodes must follow. This draft discusses
     these requirements in more depth, illustrates the used packet
     formats, describes suitable configuration procedures, and shows
     how implementations can process the packets in the right order.










Arkko et al                                         [Page 1]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


3.  Contents


       1.          Status of this Memo..................................1
       2.          Abstract.............................................1
       3.          Contents.............................................2
       4.          Introduction.........................................3
       5.          Packet Formats.......................................4
         5.1.      Binding Updates and Acknowledgements.................4
         5.2.      Return Routability Signaling.........................5
         5.3.      Prefix Discovery.....................................5
         5.4.      Payload Packets......................................5
       6.          Requirements.........................................7
       7.          Example Configurations...............................10
         7.1.      Format...............................................10
         7.2.      Manual Configuration.................................11
         7.3.      Dynamic Keying.......................................14
         7.4.      Mobile Node Returning Home...........................17
       8.          Processing Steps within a Node.......................18
         8.1.      Binding Update to the Home Agent.....................18
         8.2.      Binding Update from the Mobile Node..................18
         8.3.      Binding Acknowledgement to the Mobile Node...........19
         8.4.      Binding Acknowledgement from the Home Agent..........20
         8.5.      Home Test Init to the Home Agent.....................20
         8.6.      Home Test Init from the Mobile Node..................21
         8.7.      Home Test to the Mobile Node.........................21
         8.8.      Home Test from the Home Agent........................22
         8.9.      Prefix Solicitation Message to the Home Agent........22
         8.10.     Prefix Solicitation Message from the Mobile Node.....22
         8.11.     Prefix Advertisement Message to the Mobile Node......22
         8.12.     Prefix Advertisement Message from the Home Agent.....23
         8.13.     Payload Packet to the Home Agent.....................23
         8.14.     Payload Packet from the Mobile Node..................23
         8.15.     Payload Packet to the Mobile Node....................23
         8.16.     Payload Packet from the Home Agent...................23
       9.          Implementation Considerations........................24
       10.         Security Considerations..............................25
       11.         References...........................................26
       12.         Acknowledgements.....................................27
       13.         Author's Address.....................................28

















Arkko et al                                         [Page 2]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


4.  Introduction

     Mobile IPv6 [1] uses IPsec [2] to protect signaling between the
     home agent and the mobile node. This signaling consists of
     various messages carried by the Mobility Header protocol in
     IPv6. This signaling traffic takes the following forms:

          (1) Binding Update and Acknowledgement messages exchanged
          between the mobile node and the home agent, as described in
          Sections 10.2, 10.3, 11.6.1, and 11.6.3 of [1].

          (2) Home Test Init and Home Test messages that pass through
          the home agent on their way to a correspondent node, as
          described in Section 10.7 of [1].

          (3) ICMPv6 messages exchanged between the mobile node and
          the home agent for the purposes of prefix discovery, as
          described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1].

     The nodes MAY also optionally protect payload traffic passing
     through the home agent, as described in Section 5.3 of [1].

     Signaling between the mobile node and the home agent requires
     message authentication, integrity, correct ordering and replay
     protection.  The mobile node and the home agent must have an
     security association to protect this signaling.

     Mobile IPv6 base document defines the main requirements the
     mobile nodes and home agents must follow when securing the above
     traffic. This draft discusses these requirements in more depth,
     illustrates the used packet formats, describes suitable
     configuration procedures, and shows how implementations can
     process the packets in the right order.

     We begin our description by showing the required wire formats for
     the protected packets in Section 5.  Section 6 describes rules
     which associated Mobile IPv6, IPsec, and IKE implementations must
     observe.  Section 7 discusses how IPsec can be configured to use
     either manual or automatically established security associations.
     Section 8 shows examples of how packets are processed within the
     nodes.

     All implementations of Mobile IPv6 mobile node and home agent
     MUST support the formats described in Section 5 and obey the
     rules in Section 6.












Arkko et al                                         [Page 3]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


5.  Packet Formats

     In this section we describe the order of headers within the
     protected and tunneled packets over the wire. Support for the
     described ordering is mandatory for nodes that implement Mobile
     IPv6 mobile node or home agent functionality.

5.1.  Binding Updates and Acknowledgements

     When the mobile node is away from its home, the BUs sent by it to
     the home agent MUST have at least the following headers in the
     following order:

        IPv6 header (source = care-of address, destination = home agent)
        Destination Options header
           Home Address option (home address)
        ESP header or AH header
        Mobility header
           Binding Update

     The Binding Acknowledgements sent back to the mobile node when it
     is away from home MUST have at least the following headers in the
     following order:

        IPv6 header (source = home agent, destination = care-of address)
        Routing header (type 2)
           home address
        ESP header or AH header
        Mobility header
           Binding Acknowledgement

     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 typically happens for the de-registration Binding Update
     when the mobile is returning home. In this situation, the Binding
     Updates MUST have at least the following headers in the following
     order:

        IPv6 header (source = home address, destination = home agent)
        ESP header or AH header
        Mobility header
           Binding Update

     The Binding Acknowledgement messages sent to the home address
     MUST have at least the following headers in the following order:

        IPv6 header (source = home agent, destination = home address)
        ESP header or AH header
        Mobility header
           Binding Acknowledgement







Arkko et al                                         [Page 4]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


5.2.  Return Routability Signaling

     When the Home Test Init messages tunneled to the home agent are
     protected by IPsec, they MUST have at least the following headers
     in the following order:

        IPv6 header (source = care-of address, destination = home agent)
        ESP header
        IPv6 header (source = home address, destination = correspondent node)
        Mobility Header
           Home Test Init

     Similarly, when the Home Test messages tunneled from the home
     agent are protected by IPsec, they MUST have at least the
     following headers in the following order:

        IPv6 header (source = home agent, destination = care-of address)
        ESP header
        IPv6 header (source = correspondent node, destination = home address)
        Mobility Header
           Home Test

     Note that these formats rely on the SA destination address
     (tunnel gateway address) to change for the mobile node as it
     moves. This is discussed further in the requirements in Section 6.

5.3.  Prefix Discovery

     If IPsec is used to protect prefix discovery, requests for prefix
     from the mobile node to the home agent MUST have at least the
     following headers in the following order.

        IPv6 header (source = care-of address, destination = home agent)
        Destination Options header
           Home Address option (home address)
        ESP header or AH header
        ICMPv6
           Mobile Prefix Solicitation

     Again if IPsec is used, solicited and unsolicited prefix
     information advertisements from the home agent to the mobile node
     MUST have at least the following headers in the following order.

        IPv6 header (source = home agent, destination = care-of address)
        Routing header (type 2)
           home address
        ESP header or AH header
        ICMPv6
           Mobile Prefix Advertisement

5.4.  Payload Packets

     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



Arkko et al                                         [Page 5]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


     case of tunneled Home Test Init messages. However, instead of the
     Mobility Header these packets may contain any legal IPv6
     protocol(s), and it is possible to use both AH and ESP for the
     protection:

        IPv6 header (source = care-of address, destination = home agent)
        ESP header or AH header
        IPv6 header (source = home address, destination = correspondent node)
        Any protocol

     Similarly, when the payload packets are tunneled from the home
     agent to the mobile node with IPsec protection, they MUST have at
     least the following headers in the following order:

        IPv6 header (source = home agent, destination = care-of address)
        ESP header or AH header
        IPv6 header (source = correspondent node, destination = home address)
        Any protocol







































Arkko et al                                         [Page 6]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


6.  Requirements

     This section describes mandatory rules for all Mobile IPv6 mobile
     nodes and home agents. These rules are necessary in order for it
     to be possible to enable IPsec communications despite movements,
     guarantee sufficient security, and to ensure correct processing
     order of packets.

     We will start with the main requirements:

          - IPsec protection for Binding Updates and Acknowledgements
          between the mobile node and home agent MUST be supported and
          MUST be used.

          - IPsec protection for the Home Test Init and Home Test
          messages tunneled between the mobile node and home agent
          MUST be supported and SHOULD be used.

          - IPsec protection for the ICMPv6 messages related to prefix
          discovery MUST be supported and SHOULD be used.

          - IPsec protection of the payload packets tunneled between
          the mobile node and home agent MAY be supported and used.

          - Manual configuration of security associations MUST be
          supported and dynamic establishment MAY be supported.

     The following rules apply to both home agents and mobile nodes:

          - When ESP is used for protecting ICMPv6 or Mobility Header
          messages, a non-null authentication algorithm MUST be
          applied.

          - When ESP is used for protecting tunneled Home Test Init
          and Home Test messages, a non-null encryption algorithm and
          non-null authentication algorithm MUST be applied.

          - If replay protection is required, dynamic keying MUST be
          used.  IPsec can easily provide replay protection only if
          dynamic keying is used.  This may not always be possible,
          and manual keying would be preferred in some cases.  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 ensure correct
          ordering.  However, if a home agent reboots and loses its
          state regarding the sequence numbers, replay attacks become
          possible. The use of a key management mechanism together
          with IPsec can be used to prevent such replay attacks.

          - IPsec AH authenticator calculation MUST be performed as if
          a 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 Routing header. Type 2 Routing header
          should be treated by IPsec in the same manner as Type 0



Arkko et al                                         [Page 7]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


          Routing header.

          - Similarly, the authenticator calculation MUST be performed
          as if a packet with a Home Address destination option would
          have the home address in the IPv6 source address field and
          the care-of address in the destination option.

          - When a packet is matched against IPsec security policy or
          selectors of a security association, an address appearing in
          a Home Address destination option MUST be considered as the
          source address of the packet.

          - Similarly, a home address within a Type 2 Routing header
          MUST be considered as the destination address of the packet,
          when a packet is matched against IPsec security policy or
          selectors of a security association.

          - When IPsec is used to protect return routability signaling
          or payload packets, the security association between the
          home agent and the mobile node MUST change its destination
          address (tunneled gateway address) when the care-of address
          for the mobile node changes. At the home agent, this
          modification takes place when a the care-of address in a
          binding changes. At the mobile node, this modification takes
          place immediately after movement.

          - When IPsec is used to protect return routability signaling
          or payload packets, the security policy database entries
          SHOULD be defined specifically for the tunnel interface
          between the mobile node and the home agent. 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.

     The following rules apply to mobile nodes:

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

          - If IPsec is used to protect return routability signaling
          or payload packets tunneled via the home agent, IPsec tunnel
          mode encapsulation MUST be used.

          - Depending on whether IPsec AH or ESP is used the protec-
          tion offered for the Binding Updates is slightly different.
          AH protects also the IPv6 header and any extension headers.
          It is important for the home agent to verify that the care-
          of address has not been tampered. If ESP is used, the IPv6
          header where this information resides could potentially have
          been modified by attackers on the path. 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



Arkko et al                                         [Page 8]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


          mobility option when ESP is used, or when the implementation
          does not know whether AH or ESP is used.

          - Where dynamic keying is used, the key management protocol
          MUST use the care-of address as the source address in the
          protocol exchanges.

          - Conversely, the IPsec SAs MUST be requested from the key
          management protocol with the home address as the mobile
          node's address.

     The following rules apply to home agents:

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

          - If IPsec is used to protect return routability signaling
          or payload packets tunneled to and from the mobile node,
          IPsec tunnel mode encapsulation MUST be used.

          - We need 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 SA for any given home
          address and home agent when manual keying is used. When
          dynamic keying is used, the security policy database entries
          MUST unequivocally identify the IKE phase 1 credentials
          which can be used to create security associations for a
          particular home address.

























Arkko et al                                         [Page 9]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


7.  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. Our examples assume
     the use of ESP, but a similar configuration could also be used to
     protect the messages with AH.

     Section 7.1 introduces the format we use in the description of
     the SPD and the SAD.  Section 7.2 describes how to configure
     manually keyed security associations, and Section 7.3 describes
     how to use dynamic keying.

7.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> |
       "IF" <condition> "THEN CREATE" <pattern> |

     Where <condition> is an boolean expression about the fields of
     the IPv6 packet, <sa> is the name of an SA, and <pattern> is a
     specification for an SA to be negotiated via IKE. 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> "," <ahesp> "," <mode> ")" ":"
                    <selectors>




Arkko et al                                        [Page 10]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


     Where <dir> is "IN" or "OUT", <spi> is the SPI of the SA, <desti-
     nation> is the destination of the SA, <ahesp> is either "AH" or
     "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <selectors>
     is a boolean expression about the fields of the IPv6 packet.

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

7.2.  Manual Configuration

7.2.1.  Binding Updates and Acknowledgements

     Here are the contents of the SPD and SAD for protecting Binding
     Updates and Acknowledgements in the mobile node mobile node and
     home agent home agent:

       mobile node SPD OUT:
         - IF source = home_address_1 & destination = home_agent_1 &
              proto = MH
           THEN USE SA1

       mobile node SPD IN:
         - IF source = home_agent_1 & destination = home_address_1 &
              proto = MH
           THEN USE 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 SA2

       home agent SPD IN:
         - IF source = home_address_1 & destination = home_agent_1 &
              proto = MH
           THEN USE 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





Arkko et al                                        [Page 11]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


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

       mobile node SPD OUT:
         - IF interface = tunnel to home_agent_1 & source = home_address_1 &
              destination = any & proto = MH
           THEN USE SA3

       mobile node SPD IN:
         - IF interface = tunnel from home_agent_1 & source = any &
              destination = home_address_1 & proto = MH
           THEN USE 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, home_address_1, ESP, TUNNEL):
           source = any & destination = home_address_1 & proto = MH

       home agent SPD OUT:
         - IF interface = tunnel to home_address_1 & source = any &
              destination = home_address_1 & proto = MH
           THEN USE SA4

       home agent SPD IN:
         - IF interface = tunnel from home_address_1 & source = home_address_1 &
              destination = any & proto = MH
           THEN USE SA3

       home agent SAD:
         - SA4(OUT, spi_d, home_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

7.2.3.  Prefix Discovery

     In the following we describe some additional SPD and SAD entries
     to protect prefix discovery.

       mobile node SPD OUT:
         - IF source = home_address_1 & destination = home_agent_1 &
              proto = ICMPv6
           THEN USE SA5.

       mobile node SPD IN:
         - IF source = home_agent_1 & destination = home_address_1 &
              proto = ICMPv6
           THEN USE SA6



Arkko et al                                        [Page 12]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


       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 &
              proto = ICMPv6
           THEN USE SA6

       home agent SPD IN:
         - IF source = home_address_1 & destination = home_agent_1 &
              proto = ICMPv6
           THEN USE SA5

       home agent SAD:
         - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
           source = home_agent_1 & destination = home_address_1 &
           proto = ICMPv6
         - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
           source = home_address_1 & destination = home_agent_1 &
           proto = ICMPv6

     Note that the SPDs described above protect all ICMPv6 traffic
     between the mobile node and the home agent.

     When new prefixes are advertised by the home agent, the MN MAY
     configure additional new home addresses. There may be a need to
     create new security associations, if the mobile node intends to
     use any of these home addresses to send a Binding Update to the
     home agent.

7.2.4.  Payload Packets

     It is also possible to perform some additional, optional,
     protection of tunneled payload packets. This protection takes
     place in a similar manner to the return routability protection
     above, but requires a different value for the protocol field. The
     necessary SPD and SAD entries are shown below. It is assumed that
     the entries for protecting Binding Updates and Acknowledgements,
     and the entries to protect Home Test Init and Home Test messages
     take precedence over these entries.

       mobile node SPD OUT:
         - IF interface = tunnel to home_agent_1 & source =
     home_address_1 &
              destination = any & proto = X
           THEN USE SA7

       mobile node SPD IN:
         - IF interface = tunnel from home_agent_1 & source = any &



Arkko et al                                        [Page 13]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


              destination = home_address_1 & proto = X
           THEN USE SA8

       mobile node SAD:
         - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
           source = home_address_1 & destination = any & proto = X
         - SA8(IN, spi_h, home_address_1, ESP, TUNNEL):
           source = any & destination = home_address_1 & proto = X

       home agent SPD OUT:
         - IF interface = tunnel to home_address_1 & source = any &
              destination = home_address_1 & proto = X
           THEN USE SA8

       home agent SPD IN:
         - IF interface = tunnel from home_address_1 & source =
     home_address_1 &
              destination = any & proto = X
           THEN USE SA7

       home agent SAD:
         - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL):
           source = any & destination = home_address_1 & proto = X
         - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
           source = home_address_1 & destination = any & proto = X

7.3.  Dynamic Keying

     In this section we show an example configuration that uses IKE to
     negotiate security associations.

7.3.1.  Binding Updates and Acknowledgements

     Here are the contents of the SPD for protecting Binding Updates
     and Acknowledgements:

       mobile node SPD OUT:
         - IF source = home_address_1 & destination = home_agent_1 & proto = MH
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

       mobile node SPD IN:
         - IF source = home_agent_1 & destination = home_address_1 & proto = MH
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

       home agent SPD OUT:
         - IF source = home_agent_1 & destination = home_address_1 & proto = MH
           THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1

       home agent SPD IN:
         - IF source = home_address_1 & destination = home_agent_1 & proto = MH
           THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1

     We have omitted details of the proposed transforms in the above,
     and all details related to the particular authentication method



Arkko et al                                        [Page 14]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


     such as certificates beyond listing a specific identity that must
     be used.

     We require IKE to be run using the care-of addresses but still
     negotiate IPsec SAs that use home addresses. The extra conditions
     set by the home agent SPD for the peer phase 1 identity to 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 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".

     These checks also imply that the configuration of the home agent
     is user-specific: every user or home address requires a specific
     configuration entry. It would be possible to alleviate the
     configuration tasks by using certificates that have home addresses
     in the Subject AltName field.  However, it isn't clear if all IKE
     implementations allow one address to be used for carrying the IKE
     negotiations when another address is mentioned in the used cer-
     tificates. In any case, even this approach would have required
     user-specific tasks in the certificate authority.

7.3.2.  Return Routability Signaling

     Protection for the return routability signaling can be configured
     in a similar manner as above.

       mobile node SPD OUT:
         - IF interface = tunnel to home_agent_1 &
              source = home_address_1 & destination = any & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                      local phase 1 identity = user_1

       mobile node SPD IN:
         - IF interface = tunnel from home_agent_1 &
              source = any & destination = home_address_1 & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                      local phase 1 identity = user_1

       home agent SPD OUT:
         - IF interface = tunnel to home_address_1 &
              source = any & destination = home_address_1 & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
                                      peer phase 1 identity = user_1

       home agent SPD IN:
         - IF interface = tunnel from home_address_1 &
              source = home_address_1 & destination = any & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
                                      peer phase 1 identity = user_1

     One difference to the above is that we specified the tunnel
     gateway address, as we need to use a different address for that
     than those appearing in the packets.




Arkko et al                                        [Page 15]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


7.3.3.  Prefix Discovery

     In the following we describe some additional SPD entries to
     protect prefix discovery with IKE. (Note that when actual new
     prefixes are discovered, there may be a need to enter new
     manually configured SPD entries to specify the authorization
     policy for the resulting new home addresses.)

       mobile node SPD OUT:
         - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

       mobile node SPD IN:
         - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1

       home agent SPD OUT:
         - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1

       home agent SPD IN:
         - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1

7.3.4.  Payload Packets

     Protection for the payload packets happens similarly to the
     protection of return routability signaling. As in the manually
     keyed case, these SPD entries have lower priority than the above
     ones.

       mobile node SPD OUT:
         - IF interface = tunnel to home_agent_1 &
              source = home_address_1 & destination = any & proto = X
           THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                      local phase 1 identity = user_1

       mobile node SPD IN:
         - IF interface = tunnel from home_agent_1 &
              source = any & destination = home_address_1 & proto = X
           THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
                                      local phase 1 identity = user_1

       home agent SPD OUT:
         - IF interface = tunnel to home_address_1 &
              source = any & destination = home_address_1 & proto = X
           THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
                                      peer phase 1 identity = user_1

       home agent SPD IN:
         - IF interface = tunnel from home_address_1 &
              source = home_address_1 & destination = any & proto = X
           THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
                                      peer phase 1 identity = user_1



Arkko et al                                        [Page 16]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


7.4.  Mobile Node Returning Home

     When the MN returns home and deregisters with the Home Agent, the
     tunnel between the home agent and the MN's CoA is torn down. The
     SPD entries, which were used for protecting tunneled traffic
     between the MN and the HA become inactive. The corresponding SAs
     could be stored or deleted depending on how they were created. If
     the SAs were created dynamically using IKE, they are
     automatically deleted when they expire. If the SAs were created
     through manual configuration, they can be retained and used later
     if the MN moves aways from home.

     The SAs created for BU/BA protection SHOULD not be deleted as
     they do not depend on care-of addresses and can be used again.











































Arkko et al                                        [Page 17]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


8.  Processing Steps within a Node

     In this section we give examples of what processing steps node
     can take to achieve the required packet formats and satisfy the
     requirements. These example are for illustration purposes only,
     and implementations are free to choose other strategies as long
     as the results stay the same on the wire.

8.1.  Binding Update to the Home Agent

     Step 1. At the mobile node, Mobile IPv6 module first produces the
     following packet

        IPv6 header (source = home address, destination = home agent)
        Mobility header
           Binding Update

     Step 2. This packet is matched against the IPsec policy data base
     on the mobile node and we make a note that IPsec must be applied.

     Step 3. Then, we add the necessary Mobile IPv6 options but do not
     change the addresses yet, as described in Section 11.2.2 in [1].
     This results in:

        IPv6 header (source = home address, destination = home agent)
        Destination Options header
           Home Address option (care-of address)
        Mobility header
           Binding Update

     Step 4. Finally, IPsec headers are added and the necessary
     authenticator values are calculated:

        IPv6 header (source = home address, destination = home agent)
        Destination Options header
           Home Address option (care-of address)
        ESP header (SPI = spi_a)
        Mobility header
           Binding Update

     Step 5. Before sending the packet, the addresses in the IPv6
     header and the Destination Options header are changed:

        IPv6 header (source = care-of address, destination = home agent)
        Destination Options header
           Home Address option (home address)
        ESP header (SPI = spi_a)
        Mobility header
           Binding Update

8.2.  Binding Update from the Mobile Node

     Step 1. The following packet is received at the home agent:




Arkko et al                                        [Page 18]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


        IPv6 header (source = care-of address, destination = home agent)
        Destination Options header
           Home Address option (home address)
        ESP header (SPI = spi_a)
        Mobility header
           Binding Update

     Step 2. The home address option is processed first, which results
     in

        IPv6 header (source = home address, destination = home agent)
        Destination Options header
           Home Address option (care-of address)
        ESP header (SPI = spi_a)
        Mobility header
           Binding Update

     Step 3. ESP header is processed next, resulting in

         IPv6 header (source = home address, destination = home agent)
         Destination Options header
            Home Address option (care-of address)
         Mobility header
            Binding Update

     Step 4. This packet matches the SA selectors (source = home
     address, destination = home agent, proto = MH).

     Step 5. Mobile IPv6 processes the Binding Update.

     The Binding Update is delivered to the Mobile IPv6 module.

8.3.  Binding Acknowledgement to the Mobile Node

     Step 1. Mobile IPv6 produces the following packet:

        IPv6 header (source = home agent, destination = home address)
        Mobility header
           Binding Acknowledgement

     Step 2. This packet matches the IPsec policy entries, and we
     remember that IPsec has to be applied.

     Step 3. Then, we add the necessary Route Headers but do not
     change the addresses yet, as described in Section 9.6 in [1].
     This results in:
        IPv6 header (source = home agent, destination = home address)
        Routing header (type 2)
           care-of address
        Mobility header
           Binding Acknowledgement

     Step 4. We apply IPsec:




Arkko et al                                        [Page 19]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


        IPv6 header (source = home agent, destination = home address)
        Routing header (type 2)
           care-of address
        ESP header (SPI = spi_b)
        Mobility header
           Binding Acknowledgement

     Step 5. Finally, before sending the packet out we change the
     addresses in the IPv6 header and the Route header:

        IPv6 header (source = home agent, destination = care-of address)
        Routing header (type 2)
           home address
        ESP header (SPI = spi_b)
        Mobility header
           Binding Acknowledgement

8.4.  Binding Acknowledgement from the Home Agent

     Step 1. The following packet is received at the mobile node

        IPv6 header (source = home agent, destination = care-of address)
        Routing header (type 2)
           home address
        ESP header (SPI = spi_b)
        Mobility header
           Binding Acknowledgement

     Step 2. After the routing header is processed the packet becomes

        IPv6 header (source = home agent, destination = home address)
        Routing header (type 2)
           care-of address
        ESP header (SPI = spi_b)
        Mobility header
           Binding Acknowledgement

     Step 3. ESP header is processed next, resulting in:

        IPv6 header (source = home agent, destination = home address)
        Routing header (type 2)
           care-of address
        Mobility header
           Binding Acknowledgement
     Step 4. This packet matches the SA selectors (source = home
     agent, destination = home address, proto = MH).

     Step 5. The Binding Acknowledgement is delivered to the Mobile
     IPv6 module.

8.5.  Home Test Init to the Home Agent

     Step 1. The mobile node constructs a Home Test Init message:




Arkko et al                                        [Page 20]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


        IPv6 header (source = home address, destination = correspondent node)
        Mobility header
           Home Test Init

     Step 2. Mobile IPv6 determines that this packet should go to the
     tunnel to the home agent.

     Step 3. The packet is matched against IPsec policy entries for
     the interface, and we find that IPsec needs to be applied.

     Step 4. IPsec tunnel mode headers are added. Note that we use a
     care-of address as a source address for the tunnel packet.

        IPv6 header (source = care-of address, destination = home agent)
        ESP header (SPI = spi_c)
        IPv6 header (source = home address, destination = correspondent node)
        Mobility header
           Home Test Init

     Step 5. The packet no longer satisfies the criteria that made it
     enter the tunnel, and it is sent directly to the home agent.

8.6.  Home Test Init from the Mobile Node

     Step 1. The home agent receives the following packet:

        IPv6 header (source = care-of address, destination = home agent)
        ESP header (SPI = spi_c)
        IPv6 header (source = home address, destination = correspondent node)
        Mobility Header
           Home Test Init

     Step 2. IPsec processing is performed, resulting in:

        IPv6 header (source = home address, destination = correspondent node)
        Mobility Header
           Home Test Init

     Step 3. The resulting packet matches the selectors and the packet
     can be processed further.

     Step 4. The packet is then forwarded towards the correspondent
     node.

8.7.  Home Test to the Mobile Node

     Step 1. The home agent receives a Home Test packet from the
     correspondent node:

        IPv6 header (source = correspondent node, destination = home address)
        Mobility Header
           Home Test Init





Arkko et al                                        [Page 21]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


     Step 2. The home agent determines that this packet is destined to
     a mobile node that is away from home, and decides to tunnel it.

     Step 3. The packet matches the IPsec policy entries for the
     tunnel interface, and we note that IPsec needs to be applied.

     Step 4. IPsec is applied, resulting in a new packet. Note that
     the home agent must keep track of the location of the mobile
     node, and update the tunnel gateway address in the security
     association(s) accordingly.

        IPv6 header (source = home agent, destination = care-of address)
        ESP header (SPI = spi_d)
        IPv6 header (source = correspondent node, destination = home address)
        Mobility Header
           Home Test Init

     Step 5. The packet no longer satisfies the criteria that made it
     enter the tunnel, and it is sent directly to the care-of address.

8.8.  Home Test from the Home Agent

     Step 1. The mobile node receives the following packet:

        IPv6 header (source = home agent, destination = care-of address)
        ESP header (SPI = spi_d)
        IPv6 header (source = correspondent node, destination = home address)
        Mobility Header
           Home Test Init

     Step 2. IPsec is processed, resulting in:

        IPv6 header (source = correspondent node, destination = home address)
        Mobility Header
           Home Test Init

     Step 3. This matches the SA selectors (source = any, destination
     = home address).

     Step 4. The packet is given to Mobile IPv6 processing.

8.9.  Prefix Solicitation Message to the Home Agent

     This procedure is similar to the one presented in Section 8.1.

8.10.  Prefix Solicitation Message from the Mobile Node

     This procedure is similar to the one presented in Section 8.2.

8.11.  Prefix Advertisement Message to the Mobile Node

     This procedure is similar to the one presented in Section 8.3.





Arkko et al                                        [Page 22]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


8.12.  Prefix Advertisement Message from the Home Agent

     This procedure is similar to the one presented in Section 8.4.

8.13.  Payload Packet to the Home Agent

     This procedure is similar to the one presented in Section 8.5.

8.14.  Payload Packet from the Mobile Node

     This procedure is similar to the one presented in Section 8.6.

8.15.  Payload Packet to the Mobile Node

     This procedure is similar to the one presented in Section 8.7.

8.16.  Payload Packet from the Home Agent

     This procedure is similar to the one presented in Section 8.8.






































Arkko et al                                        [Page 23]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


9.  Implementation Considerations

     We have chosen to require an encapsulation format for return
     routability and payload packet protection which can only be
     realized if the IPsec implementation can be controlled via an
     API. One of the main reasons for choosing such a format is that
     it removes the overhead of twenty four bytes when a home address
     option or routing header is added to the tunneled packet. The API
     should minimally support changing the gateway address of a
     security association towards the mobile node as the mobile node
     moves. Implementations are free to choose other methods to update
     a security association.  This includes deleting the current SA
     and adding a new SA.

     We have also chosen to require that a dynamic key management
     protocol must be able to make an authorization decision for IPsec
     SA creation with different addresses than with what the key
     management protocol is run. We expect this to be done typically by
     configuring the allowed combinations of phase 1 user identities
     and home addresses.

     The base Mobile IPv6 specification sets high requirements for a
     so-called Bump-In-The-Stack (BITS) implementation model of IPsec.
     As Mobile IPv6 specific modifications of the packets are required
     after IPsec processing, the BITS implementation has to perform
     also some tasks related to mobility. This may increase the
     complexity of the implementation, even if it already performs
     some tasks of the IP layer (such as fragmentation).

     We have chosen to require policy entries that are specific to a
     tunnel interface. This means that implementations have to regard
     the Home Agent - Mobile Node tunnel as a separate interface on
     which IPsec SPDs can be based.

     A further complication of the IPsec processing on a tunnel
     interface is that this requires access to the BITS implementation
     before the packet actually goes out.




















Arkko et al                                        [Page 24]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


10.  Security Considerations

     The Mobile IPv6 base specification [1] requires strong security
     between the mobile node and the home agent. This memo discusses
     how that security can be arranged in practise, using IPsec.




















































Arkko et al                                        [Page 25]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


11.  References

     [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support for
     IPv6", Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In
     Progress.) September 2002.

     [2]  S. Kent, R. Atkinson, "Security Architecture for the
     Internet Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.

     [3]  D. Harkins and D. Carrel, "The Internet Key Exchange", RFC
     2409, Cisco Systems, November 1998.

     [4] S. Deering and R. Hinden, "Internet Protocol, Version 6
     (IPv6) Specification", RFC 2460, December 1998.











































Arkko et al                                        [Page 26]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


12.  Acknowledgements

     The authors would like to thank Erik Nordmark, Gabriel
     Montenegro, Kevin Miles, Cheryl Madson and Jari T. Malinen for
     interesting discussions in this problem space.




















































Arkko et al                                        [Page 27]

INTERNET-DRAFT        Home Agent IPsec       15 October 2002


13.  Author's Address


     Jari Arkko
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland

     EMail: Jari.Arkko@ericsson.com

     Vijay Devarapalli
     Nokia Research Center
     313 Fairchild Drive
     Mountain View, CA 94043

     EMail: vijayd@iprg.nokia.com

     Francis Dupont
     ENST Bretagne
     Campus de Rennes 2, rue de la Chataigneraie
     BP 78
     35512 Cesson-Sevigne Cedex
     France

     EMail: Francis.Dupont@enst-bretagne.fr
































Arkko et al                                        [Page 28]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/