[Docs] [txt|pdf] [Tracker] [WG] [Email] [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-00.txt>                      Nokia
                                                             Francis Dupont
                                                              ENST Bretagne
     20 September 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     20 September 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
       8.          Processing Steps within a Node.......................17
         8.1.      Binding Update to the Home Agent.....................17
         8.2.      Binding Update from the Mobile Node..................17
         8.3.      Binding Acknowledgement to the Mobile Node...........18
         8.4.      Binding Acknowledgement from the Home Agent..........19
         8.5.      Home Test Init to the Home Agent.....................19
         8.6.      Home Test Init from the Mobile Node..................20
         8.7.      Home Test to the Mobile Node.........................20
         8.8.      Home Test from the Home Agent........................21
         8.9.      Prefix Solicitation Message to the Home Agent........21
         8.10.     Prefix Solicitation Message from the Mobile Node.....21
         8.11.     Prefix Advertisement Message to the Mobile Node......21
         8.12.     Prefix Advertisement Message from the Home Agent.....22
         8.13.     Payload Packet to the Home Agent.....................22
         8.14.     Payload Packet from the Mobile Node..................22
         8.15.     Payload Packet to the Mobile Node....................22
         8.16.     Payload Packet from the Home Agent...................22
       9.          Security Considerations..............................23
       10.         Open Issues..........................................24
       11.         References...........................................25
       12.         Acknowledgements.....................................26
       13.         Author's Address.....................................27


















Arkko et al                                         [Page 2]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


4.  Introduction

     Mobile IPv6 [1] uses IPsec [2] to protect signaling between the
     home agent and the mobile node. This signaling consists of vari-
     ous 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.  Authentication
     Header (AH) or Encapsulating Security Payload (ESP) can be used.

     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 configu-
     ration 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     20 September 2002


5.  Packet Formats

     In this section we describe the order of headers within the pro-
     tected 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     20 September 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 follow-
     ing 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 (tun-
     nel 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 informa-
     tion 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     20 September 2002


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

        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     20 September 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 mes-
          sages 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 sup-
          ported 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.




Arkko et al                                         [Page 7]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


          - 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, 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 IPsec is used to protect return routability signaling
          or payload packets, the security association from the home
          agent to the mobile node MUST change its destination 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 modi-
          fication takes place immediately after movement.

          - When IPsec is used to protect return routability signaling
          or payload packets, the security policy database entries
          MUST 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 the mobile node tunnels Home Test Init messages or pay-
          load packets via the home agent with IPsec protection, the
          mobile node MUST use the Home Address destination and IPsec
          tunnel mode encapsulation.

          Depending on whether IPsec AH or ESP is used the protection
          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
          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



Arkko et al                                         [Page 8]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


          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 Bind-
          ing 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 the home agent tunnels Home Test messages or payload
          packets to the mobile node with IPsec protection, the home
          agent MUST use the Type 2 Routing header and IPsec tunnel
          mode encapsulation.

          - 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 par-
          ticular home address.





























Arkko et al                                         [Page 9]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


7.  Example Configurations

     In the following we describe the Security Policy Database (SPD)
     and Security Association Database (SAD) entries necessary to pro-
     tect 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 man-
     ually 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 descrip-
     tion 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     20 September 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.

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 & destination = home agent & proto = MH
           THEN USE SA1

       mobile node SPD IN:
         - IF source = home agent & destination = home address & proto = MH
           THEN USE SA2

       mobile node SAD:
         - SA1(OUT, 5001, home agent, ESP, TRANSPORT):
           source = home address & destination = home agent & proto = MH
         - SA2(IN, 5002, home address, ESP, TRANSPORT):
           source = home agent & destination = home address & proto = MH

       home agent SPD OUT:
         - IF source = home agent & destination = home address & proto = MH
           THEN USE SA2

       home agent SPD IN:
         - IF source = home address & destination = home agent & proto = MH
           THEN USE SA1

       home agent SAD:
         - SA2(OUT, 5002, home address, ESP, TRANSPORT):
           source = home agent & destination = home address & proto = MH
         - SA1(IN, 5001, home agent, ESP, TRANSPORT):
           source = home address & destination = home agent & proto = MH

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 & source = home address &
              destination = any & proto = MH
           THEN USE SA3




Arkko et al                                        [Page 11]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


       mobile node SPD IN:
         - IF interface = tunnel from home agent & source = any &
              destination = home address & proto = MH
           THEN USE SA4

       mobile node SAD:
         - SA3(OUT, 5003, home agent, ESP, TUNNEL):
           source = home address & destination = any & proto = MH
         - SA4(IN, 5004, home address, ESP, TUNNEL):
           source = any & destination = home address & proto = MH

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

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

       home agent SAD:
         - SA4(OUT, 5004, home address, ESP, TUNNEL):
           source = any & destination = home address & proto = MH
         - SA3(IN, 5003, home agent, ESP, TUNNEL):
           source = home address & destination = any & proto = MH

7.2.3.  Prefix Discovery

     In the following we describe some additional SPD and SAD entries
     to protect prefix discovery. (Note that when actual new prefixes
     are discovered, there may be a need to enter new manually config-
     ured SAs to protect Binding Updates.)

       mobile node SPD OUT:
         - IF source = home address & destination = home agent & proto = ICMPv6
           THEN USE SA5

       mobile node SPD IN:
         - IF source = home agent & destination = home address & proto = ICMPv6
           THEN USE SA6

       mobile node SAD:
         - SA5(OUT, 5005, home agent, ESP, TRANSPORT):
           source = home address & destination = home agent & proto = ICMPv6
         - SA6(IN, 5006, home address, ESP, TRANSPORT):
           source = home agent & destination = home address & proto = ICMPv6

       home agent SPD OUT:
         - IF source = home agent & destination = home address & proto = ICMPv6
           THEN USE SA6

       home agent SPD IN:
         - IF source = home address & destination = home agent & proto = ICMPv6



Arkko et al                                        [Page 12]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


           THEN USE SA5

       home agent SAD:
         - SA6(OUT, 5006, home address, ESP, TRANSPORT):
           source = home agent & destination = home address & proto = ICMPv6
         - SA5(IN, 5005, home agent, ESP, TRANSPORT):
           source = home address & destination = home agent & proto = ICMPv6

7.2.4.  Payload Packets

     It is also possible to perform some additional, optional, protec-
     tion 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 & source = home address
     &
              destination = any & proto = any
           THEN USE SA7

       mobile node SPD IN:
         - IF interface = tunnel from home agent & source = any &
              destination = home address & proto = any
           THEN USE SA8

       mobile node SAD:
         - SA7(OUT, 5007, home agent, ESP, TUNNEL):
           source = home address & destination = any & proto = any
         - SA8(IN, 5008, home address, ESP, TUNNEL):
           source = any & destination = home address & proto = any

       home agent SPD OUT:
         - IF interface = tunnel to mobile node & source = any &
              destination = home address & proto = any
           THEN USE SA8

       home agent SPD IN:
         - IF interface = tunnel from mobile node & source = home
     address &
              destination = any & proto = any
           THEN USE SA7

       home agent SAD:
         - SA8(OUT, 5008, home address, ESP, TUNNEL):
           source = any & destination = home address & proto = any
         - SA7(IN, 5007, home agent, ESP, TUNNEL):
           source = home address & destination = any & proto = any





Arkko et al                                        [Page 13]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


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 & destination = home agent & proto = MH
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1

       mobile node SPD IN:
         - IF source = home agent & destination = home address & proto = MH
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1

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

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

     (We have omitted details of the proposed transforms in the
     above.)

     We require IKE to be run using the care-of addresses but still
     negotiate IPsec SAs that use home addresses.  Note the extra con-
     ditions set by the home agent SPD for the peer phase 1 identity.
     These are needed, and must be verified by the home agent.  The
     purpose of the condition is to ensure that the IKE phase 2 nego-
     tiation for a given user's home address can't be requested by
     another user.

     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 con-
     figuration 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 &



Arkko et al                                        [Page 14]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


              source = home address & destination = any & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

       mobile node SPD IN:
         - IF interface = tunnel from home agent &
              source = any & destination = home address & proto = MH
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

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

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

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

     Note that this specification has still the same problems as the
     manual protection for return routability signaling had.

7.3.3.  Prefix Discovery

     In the following we describe some additional SPD entries to pro-
     tect prefix discovery with IKE. (Note that when actual new pre-
     fixes 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 & destination = home agent & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1

       mobile node SPD IN:
         - IF source = home agent & destination = home address & proto = ICMPv6
           THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1

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

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





Arkko et al                                        [Page 15]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


7.3.4.  Payload Packets

     Protection for the payload packets happens similarly to the pro-
     tection 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 &
              source = home address & destination = any & proto = any
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

       mobile node SPD IN:
         - IF interface = tunnel from home agent &
              source = any & destination = home address & proto = any
           THEN CREATE ESP TUNNEL SA: gateway = home agent &
                                      local phase 1 identity = user1

       home agent SPD OUT:
         - IF interface = tunnel to mobile node &
              source = any & destination = home address & proto = any
           THEN CREATE ESP TUNNEL SA: gateway = home address &
                                      peer phase 1 identity = user1

       home agent SPD IN:
         - IF interface = tunnel from mobile node &
              source = home address & destination = any & proto = any
           THEN CREATE ESP TUNNEL SA: gateway = home address &
                                      peer phase 1 identity = user1




























Arkko et al                                        [Page 16]

INTERNET-DRAFT        Home Agent IPsec     20 September 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 = 5001)
        Mobility header
           Binding Update

     Step 5. Before forwarding 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 = 5001)
        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 17]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


        IPv6 header (source = care-of address, destination = home agent)
        Destination Options header
           Home Address option (home address)
        ESP header (SPI = 5001)
        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 = 5001)
        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 18]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


        IPv6 header (source = home agent, destination = home address)
        Routing header (type 2)
           care-of address
        ESP header (SPI = 5002)
        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 = 5002)
        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 = 5002)
        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 = 5002)
        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 19]

INTERNET-DRAFT        Home Agent IPsec     20 September 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 = 5003)
        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 routed 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 = 5003)
        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 cor-
     respondent node:

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





Arkko et al                                        [Page 20]

INTERNET-DRAFT        Home Agent IPsec     20 September 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 tun-
     nel 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 asso-
     ciation(s) accordingly.

        IPv6 header (source = home agent, destination = care-of address)
        ESP header (SPI = 5004)
        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 routed 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 = 5004)
        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 21]

INTERNET-DRAFT        Home Agent IPsec     20 September 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 22]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


9.  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 23]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


10.  Open Issues

     The following issues should be highlighted as potentially contro-
     versial:

          - 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 con-
          trolled via an API. We expect to change the gateway address
          of a security association towards the mobile node as the
          mobile node moves.

          - The base Mobile IPv6 specification sets high requirements
          for a so-called Bumb-In-The-Wire (BITS) implementation model
          of IPsec. As Mobile IPv6 specific modifications of the pack-
          ets are required after IPsec processing, the BITS implemen-
          tation 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. While this seems to be required in
          the definition of an "interface" in [4], in practise imple-
          mentations don't often do this.

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

          - We have chosen to use the MAY keyword in the requirement
          for dynamic key management support.

          - We have 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 where 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.

          - Mobile IPv6 base specification needs to be synchronized
          with what is stated in this document. There are also certain
          ambiguities in the specification, e.g., what the order of
          processing is for reverse tunneling, what the home agent's
          procedures are, and so on.

          - Compatibility with IPsec remote access VPNs has not been
          discussed.









Arkko et al                                        [Page 24]

INTERNET-DRAFT        Home Agent IPsec     20 September 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.














































Arkko et al                                        [Page 25]

INTERNET-DRAFT        Home Agent IPsec     20 September 2002


12.  Acknowledgements

     The authors would like to thank Erik Nordmark, Gabriel Montene-
     gro, Kevin Miles, and Cheryl Madson for interesting discussions
     in this problem space.




















































Arkko et al                                        [Page 26]

INTERNET-DRAFT        Home Agent IPsec     20 September 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 27]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/