[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                           Erik Nordmark, Sun Microsystems
Nov 12, 2001


           Securing MIPv6 BUs using return routability (BU3WAY)

                  <draft-nordmark-mobileip-bu3way-00.txt>


   Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 obsoleted 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 can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

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

   This Internet Draft expires May 12, 2002.



   Abstract

   This document is intended to serve as input to the discussion in the
   Mobile IP Working Group regarding securing MIPv6 Binding Updates.
   This document tries to capture a possible extreme point in the design
   space for a solution to that problem, for the purposes of exploring
   the design space.  The author does not claim that this protocol is
   better than any other proposed solutions - merely that it is
   different and the differences can help in understanding design
   tradeoffs in this space.

   This proposal relies on using only return routability to verify the
   authority to perform a binding update.  It uses return routability
   for every Binding Update message i.e., every binding update implies a



draft-nordmark-mobileip-bu3way-00.txt                           [Page 1]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   3-way handshake between the correspondent node and the mobile node.

   The document also tries to look at how the security properties of the
   proposed protocol would change when trying to optimize the protocol
   so that, past the first BU between a MN and a CN, subsequent BUs can
   be done without a 3-way handshake.


   Contents

      1.  INTRODUCTION.............................................    3
         1.1.  Assumptions.........................................    3

      2.  TERMINOLOGY..............................................    5
         2.1.  General.............................................    5
         2.2.  Requirements........................................    6

      3.  PROTOCOL OVERVIEW........................................    6
         3.1.  Goals and Requirements..............................    6
         3.2.  Message flow........................................    7

      4.  MESSAGE FORMATS..........................................    9
         4.1.  Binding Update Request Message Format...............    9
         4.2.  Binding Update Challenge Message Format.............   10
         4.3.  Binding Update Message Format.......................   12
         4.4.  Binding Acknowledgement Message Format..............   14

      5.  CONCEPTUAL MODEL OF A NODE...............................   16
         5.1.  Conceptual Data Structures..........................   16
         5.2.  Forming Cookies.....................................   18
         5.3.  Garbage Collection and Timeout Requirements.........   20

      6.  BEHAVIORAL SPECIFICATION.................................   20
         6.1.  Sending Binding Update Request Messages.............   20
         6.2.  Retransmission of Binding Update Request Messages...   21
         6.3.  Validation of Binding Update Request Messages.......   22
         6.4.  Processing Valid Binding Update Request Messages....   22
         6.5.  Sending Binding Update Challenge Messages...........   23
         6.6.  Validation of Binding Update Challenge Messages.....   23
         6.7.  Processing Valid Binding Update Challenge Messages..   24
         6.8.  Sending Binding Update Messages.....................   24
         6.9.  Retransmission of Binding Update Messages...........   25
         6.10.  Validation of Binding Update Messages..............   26
         6.11.  Processing Valid Binding Update Messages...........   26
         6.12.  Sending Binding Acknowledgement Messages...........   27
         6.13.  Validation of Binding Acknowledgement Messages.....   28
         6.14.  Processing Valid Binding Acknowledgement Messages..   29




draft-nordmark-mobileip-bu3way-00.txt                           [Page 2]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


      7.  SECURITY PROPERTIES......................................   29
         7.1.  Residual Threats....................................   30
         7.2.  HA to MN Security Association.......................   32
         7.3.  MN to MN Binding Updates............................   33

      8.  ORTHOGONAL SECURITY ISSUES...............................   34

      9.  WHAT IFS - ALTERNATE APPROACHES..........................   35
         9.1.  Establish a Key for Authenticating BUs..............   36
         9.2.  Diffie-Hellman Exchange.............................   37

      10.  PROTOCOL CONSTANTS......................................   38

      11.  CONCLUSIONS.............................................   38

      12.  SECURITY CONSIDERATIONS.................................   40

      13.  ACKNOWLEDGEMENTS........................................   40

      REFERENCES...................................................   40

      AUTHORS' ADDRESSES...........................................   41






1.  INTRODUCTION

   This document outlines a method for authenticating and authorizing
   Mobile IPv6 [MIPv6] Binding Updates between a correspondent node and
   a mobile node where there exists no pre-established direct or
   indirect security relationship between those two entities.  If a
   pre-established relationship, like both the CN and MN being part of
   the same Key Infrastructure (public or private) stronger security can
   be applied for authenticating the Binding Update.  There are also
   proposals that associate a public/private key pair with the actual
   IPv6 address which have different properties.  However, such stronger
   methods are outside of scope of the document.  The purpose is to
   explore parts of the solution space for weaker mechanisms.



1.1.  Assumptions

   The basis for the authentication and authorization is the assumption
   that unicast IP routing is reasonably secure and that as long as



draft-nordmark-mobileip-bu3way-00.txt                           [Page 3]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   binding updates does not create significant additional security
   issues than already present in today's routing system, the solution
   at least does not do any (additional) harm.

   In particular, this assumption about the IP routing working manifests
   itself in the assumption that if a given Correspondent Node CN sends
   a packet to the Home Address (HoA) of a Mobile Node MN, that the
   routing system will deliver those packets to the Home Link of the
   mobile node where the Home Agent (HA) will receive it.

   At some level the authentication and authorization is intertwined in
   this case.  Authentication is often viewed as providing both sender
   identity authentication as well as message integrity.  If the
   identity aspect of this in fact is capable of stating that the entity
   sending a binding update is the mobile node i.e. the entity which has
   been assigned the home address, then the authorization issue becomes
   trivial - it is obvious that the MN is authorized to redirect its own
   traffic.  But this is largely a terminology issue.

   The proposal also assumes that the communication between a MN and its
   HA is secured using some form of pre-established security
   association.  For instance, such a security association might be
   create at "subscription" time i.e., when the MN is assigned its HA.
   It is assumed that this security association is used to secure the
   Binding Update and Binding Acknowledgement messages between the MN
   and its HA, and also that the association can be used to secure other
   traffic between those two nodes.

   This assumption includes traffic in both directions; from the HA to
   the MN as well as the reverse direction.  Thus either the pre-
   established security association is bidirectional or there exists two
   separate unidirectional pre-established security associations between
   the HA and MN.

   The techniques discussed can operate with the traffic between the HA
   and MN providing at least integrity, but the security is improved
   significantly when this channel provides confidentiality.

   There is no assumption that the security mechanisms on that channel
   provide replay protection since the binding update exchanges provide
   their own protection against replays.










draft-nordmark-mobileip-bu3way-00.txt                           [Page 4]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


2.  TERMINOLOGY


2.1.  General

      IP          - Internet Protocol Version 6.

      ICMP        - Internet Message Control Protocol for the Internet
                    Protocol Version 6.

      node        - a device that implements IP.

      router      - a node that forwards IP packets not explicitly
                    addressed to itself.

      host        - any node that is not a router.

      mobile node (MN)
                    a node which has a pre-established security
                    association with one or more home agents on its home
                    link and is capable of detecting when it moves
                    between different points of attachment in the
                    network, acquire a temporary care of address in each
                    visited location, and signal its current care of
                    address to the home agent using the security
                    association.

      correspondent node (CN)
                    a node with which a mobile node communicates.  The
                    correspondent node may itself be a mobile node.

      home address (HoA)
                    the address of the mobile node which does not change
                    as the mobile node moves

      home link   - the link towards which regular IP routing forwards
                    packets destined to the home address

      home agent  - a router on the home link which tracks the mobile
                    nodes current location and relays packets to (and in
                    some cases) from the mobile node.

      care of address (CoA)
                    an IP address assigned to the mobile node is its
                    current location

      packet      - an IP header plus payload.




draft-nordmark-mobileip-bu3way-00.txt                           [Page 5]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


2.2.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [KEYWORDS].

   This document also makes use of internal conceptual variables to
   describe protocol behavior and external variables that an
   implementation must allow system administrators to change.  The
   specific variable names, how their values change, and how their
   settings influence protocol behavior are provided to demonstrate
   protocol behavior.  An implementation is not required to have them in
   the exact form described here, so long as its external behavior is
   consistent with that described in this document.


3.  PROTOCOL OVERVIEW


3.1.  Goals and Requirements

   Note that this protocol, as well as other protocols that do not rely
   on some pre-existing security relationship (including security
   properties tied to the IPv6 addresses), are inherently subject to
   Man-in-the-Middle attacks for attackers that are in the path of the
   messages that are exchanged.

   The goals and requirements for this protocol are:

    o Minimize the complexity of the protocol even if it is at the
      expense of more messages being exchanged.

    o Minimize the use of cryptographic algorithms.

    o Ensure that a correspondent node does not retain state due to
      receiving the first message in a binding update exchange, in order
      to reduce the exposure to denial of service attacks.

    o Prevent replays of binding updates after the MN has moved away to
      a different link.

    o Make replays of binding updates before the MN has moved away to a
      different link as idempotent with the original binding update.

    o Make it cryptographically hard for attackers that are not on any
      of the paths between CN-HA or CN-MN to inject spoofed binding
      updates.




draft-nordmark-mobileip-bu3way-00.txt                           [Page 6]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


    o Use the pre-established security association between the MN and HA
      to thwart Man-in-the-middle attacks for attackers on the path
      between the MN and HA.

    o When the correspondent is also a mobile node, use the secured path
      between it and its home agent to reduce the threats from attackers
      that are on the same link as the correspondent.

    o Make it hard for attackers there are not on any of the paths to
      inject spoofed Binding Acknowledgement messages.


   The protocol uses the messages in [MIPv6] with some extensions and,
   in addition, two new messages:

       Binding Update Request (BUR): First message in 3-way handshake.
                  Sent from the MN to the CN.

       Binding Update Challenge (BUC): Second message in 3-way
                  handshake.  Sent by the CN when receiving a BUR.  This
                  message includes information that the CN can use to
                  verify that the third message in the 3-way handshake
                  without requiring that the CN create state when
                  sending the BUC.

       Binding Update (BU): Third message in the 3-way handshake.  Echos
                  the information from the BUC.  When the MN requests an
                  acknowledgement of the BU it includes a random number
                  that will be echoed in the Binding Acknowledgement
                  message.

       Binding Acknowledgement (BA):  Used as specified in [MIPv6] but
                  with the added ability to return the random number
                  included in a Binding Update message as a means to
                  weakly authenticate the BA.

       Binding Request (BR):  Used as specified in [MIPv6].



3.2.  Message flow

   When a MN determines that it wants a given CN to use route
   optimization when sending packets to the MN, the MN initiates the
   binding update 3-way handshake by sending a Binding Update Request
   message to the CN.  This message just includes the Care of Address
   and Home Address of the MN.




draft-nordmark-mobileip-bu3way-00.txt                           [Page 7]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   The CN responds to this by sending a Binding Update Challenge message
   to the Home Address of the MN, which serves to verify that IP routing
   plus the home agent indeed forward packets to the node that sent the
   BUR.  The CN can get some assurance of this, without needing to
   retain state for each BUR it receives, by including a cookie in the
   BUC and verifying that the BU includes the same cookie.  The purpose
   of this check is to prevent nodes that are not on the path between
   the CN, HA, MN, and CN to inject spoofed binding updates.  The cookie
   will be different for different MNs and even the same MN using
   different Care of Addresses over time.

   This document specifies how such a cookie can be created by the CN by
   using a local timestamp mechanism (i.e., the time does not need to be
   synchronized with other nodes; only the CN will inspect the timestamp
   in the cookie) and a secret (random) number maintained by the CN
   which the CN does not share with any other node.  This allows the CN
   to compute a keyed hash using its secret and the home address, care
   of address, and timestamp.  The recommended cookie consists of the
   local timestamp followed by the result of the keyed hash.

   The timestamp in the cookie allows the CN to immediately reject
   replayed binding updates that are very old, as in older than e.g. 30
   seconds (a maximum of the round-trip time of any Internet path).
   This aids in rejecting old binding updates that are replayed after
   the CN has lost its binding cache information, e.g. due to crashing
   and rebooting or due to garbage collecting unused binding cache
   entries.  The protocol allows the CN to use different such lifetimes
   for the cookies so that e.g. a CN that suspects a DoS attack to fill
   up its Binding Cache can use shorter cookie lifetimes than 30
   seconds.

   The timestamp also allows the CN to use different secrets over time.
   When the CN switches from using one secret to another it just needs
   to remember what the timestamp value was at the time the switch was
   made.  With this information the CN can use the correct secret when
   verifying the cookie in a received BU, even when the BU was sent when
   the old secret was being used.

   Each sent Binding Update Challenge message will use a new timestamp
   value thus, as long as the CN maintains a binding cache entry for the
   MN, the timestamp will prevent replays of old BUs.

   The proposal also addresses the possibility of spoofed Binding
   Acknowledgement messages.  This case is simpler than the Binding
   Update case since the MN creates some state when sending the BUR thus
   this state can be augmented with a random cookie value without the
   type of Denial-of-service concerns that are present in a CN handling
   a BUR.  This cookie is then sent in the Binding Update message and



draft-nordmark-mobileip-bu3way-00.txt                           [Page 8]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   the MN verifies that the Binding Acknowledgement message contains the
   same cookie value.  This prevents off-path attackers from spoofing a
   Binding Acknowledgement message.

        MN  <=====================================
          \                                     ||
           \                                    ||
            \  (1) BUR (HoA,CoA)                ||
             \      (4) BU (N1, timestamp)      ||   (3) BUC
              v                                 ||
             CN ------------------------------> HA
                   (2) BUC (N1=hash(secret, HoA, CoA, CN, timestamp,
                                    cookie lifetime), timestamp)



   The proposal specifies that the BUR, BUC, BU and BA messages should
   be sent bypassing any binding cache entry on the sender in order to
   prevent old, and potentially stale, binding cache information from
   interfering.

   Also, in order to avoid issues with ingress filtering and use the
   MN-HA pre-established security association to reduce threats "close
   to" mobile nodes, the BUC, BU, and BA messages, when the sender is a
   mobile node, are reverse-tunneled through the sender's home agent.
   This ensures that when two mobile nodes are communicating, i.e., the
   correspondent is also a mobile node, the pre-established security
   association between the mobile CN and its home agent is used to
   prevent attackers close to the CN from injecting spoofed binding
   updates or binding acknowledgements.


4.  MESSAGE FORMATS


4.1.  Binding Update Request Message Format

   A Mobile node sends a Binding Update Request to a Correspondent Node
   in order to start the 3-way binding update process.












draft-nordmark-mobileip-bu3way-00.txt                           [Page 9]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                           Home Address                        +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

      Source Address
                     The Care of Address assigned to the MN.

      Destination Address
                     The CN's IP address.

   ICMP Fields:

      Type           TBD

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Home Address   The MN's Home Address.



4.2.  Binding Update Challenge Message Format

   A Binding Update Challenge message is sent by a node in response to a
   Binding Update Request.  The BUC is sent to the Home Address in the
   BUR in order to verify that the MN is indeed reachable by using that
   home address.





draft-nordmark-mobileip-bu3way-00.txt                          [Page 10]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Cookie Life   |            Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
        |                                                               |
        +                                                               +
        |                                                               |
        +                         Care of Address                       +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Cookie ...
        +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     The destination address in the triggering BUR.  If
                     the sender of the BUC is a mobile node itself then
                     this source address is likely to be its home
                     address.  In this case the BUC MUST be reverse
                     tunneled through the sender's home agent to avoid
                     issues with ingress filtering.

      Destination Address
                     The Home Address in the triggering BUR.

   ICMP Fields:

      Type           TBD

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Cookie Life    8-bit field with an unsigned integer.  The cookie
                     lifetime in units of seconds.

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Care of Address
                     The Source IP address of the triggering BUR.



draft-nordmark-mobileip-bu3way-00.txt                          [Page 11]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


      Cookie         The information included by the CN in the BUC which
                     it expects to see returned in the Binding Update.
                     The length of the Cookie field is indicated by the
                     length of the ICMP packet.



4.3.  Binding Update Message Format

   Once an MN has received a BUC in response to its BUR it will send a
   Binding Update to the CN.

   NOTE: The description of the BU in this document is intentionally
   incomplete.  It only includes the information deemed necessary to
   understand and discuss the security properties of the ideas presented
   in this document.  See [MIPv6] for the other information needed in a
   Binding Update.  The use of the Acknowledgement Cookie removes the
   need for the Sequence number field specified in [MIPv6].

   NOTE: For no reason, other than ease of cutting and pasting between
   sections in this document, the binding update is described as an ICMP
   packet.  The ideas proposed in this document can be applied
   independently of how the BU information is carried; destination
   option, UDP packet, or whatever.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|H|R|D|        Reserved       |  Cookie Life    |Prefix Length|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Reserved                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
        |                            Lifetime                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                     Acknowledgement Cookie                    +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                      Care of Address                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



draft-nordmark-mobileip-bu3way-00.txt                          [Page 12]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


        |   Cookie ...
        +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     The MN's Home Address copied from the Destination
                     Address field in the triggering BUC message.  This
                     copying ensures that it is the same as the Home
                     Address field in the BUR.  The BU MUST be reverse
                     tunneled through the sender's home agent to avoid
                     issues with ingress filtering.

      Destination Address
                     The CN's address.  MUST be the same as the
                     destination address in the BUR.

   ICMP Fields:

      Type           TBD

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      A-bit          Binding Acknowledgement as specified in [MIPv6].
                     Other bit flags, the Prefix Length, and Lifetime as
                     specified in [MIPv6].  Note that there is no
                     sequence number field necessary in this proposal.

      Reserved       This field is unused.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

      Cookie Life    8-bit field with an unsigned integer.  The cookie
                     lifetime in units of seconds.  Copied from the BUC
                     message.

      Acknowledgment Cookie
                     Only used when the A-bit is set.  A 64-bit random
                     number set by the MN used to match the Binding
                     Acknowledgement with the Binding Update.

      Care of Address
                     The same as the Care of Address field in the
                     received BUC, that is, the same as the Source
                     Address field in the BUR.




draft-nordmark-mobileip-bu3way-00.txt                          [Page 13]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


      Cookie         Copied from the Cookie field in the BUC.  The
                     length of the Cookie field is indicated by the
                     length of the ICMP packet.



4.4.  Binding Acknowledgement Message Format

   A node sends a Binding Acknowledgement in response to a Binding
   Request when the A-bit is set in the request.

   NOTE: The description of the BA in this document is intentionally
   incomplete.  It only includes the information deemed necessary to
   understand and discuss the security properties of the ideas presented
   in this document.  See [MIPv6] for the other information needed in a
   Binding Acknowledgement.  The use of the Acknowledgement Cookie
   removes the need for the Sequence number field specified in [MIPv6].

   NOTE: For no reason, other than ease of cutting and pasting between
   sections in this document, the binding ack is described as an ICMP
   packet.  The ideas proposed in this document can be applied
   independently of how the BA information is carried; destination
   option, UDP packet, or whatever.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |     Code      |          Checksum             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    Status     |                 Reserved                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Lifetime                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            Refresh                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                     Acknowledgement Cookie                    +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                      Care of Address                          +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




draft-nordmark-mobileip-bu3way-00.txt                          [Page 14]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   IP Fields:

      Source Address
                     The Destination Address in the triggering Binding
                     Update message.  If the sender of the BA is a
                     mobile node itself then this source address is
                     likely to be its home address.  In this case the BA
                     MUST be reverse tunneled through the sender's home
                     agent to avoid issues with ingress filtering.

      Destination Address
                     The Source Address in the triggering BU message.
                     This is the Home Address of the MN sending the BU.

   ICMP Fields:

      Type           TBD

      Code           0

      Checksum       The ICMP checksum.  See [ICMPv6].

      Status         See [MIPv6].

      Reserved       Unused field.  It MUST be initialized to zero by
                     the sender and MUST be ignored by the receiver.

      Lifetime       See [MIPv6].

      Refresh        See [MIPv6].

      Acknowledgement Cookie
                     64-bit field.  Copied from the Acknowledgement
                     Cookie field in the triggering Binding Update
                     Message.

      Care of Address
                     The Care of Address of the mobile node.  Copied
                     from the Care of Address field in the triggering BU
                     message.

                     TBD: Does this field serve any purpose?  It is
                     currently verified when the BA is received, but it
                     should be possible to omit it since the
                     Acknowledgement Cookie ensures that the BA is in
                     response to the last transmitted BU etc.





draft-nordmark-mobileip-bu3way-00.txt                          [Page 15]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


5.  CONCEPTUAL MODEL OF A NODE

   This section describes a conceptual model of one possible data
   structure organization that nodes need to maintain in order to
   implement [MIPv6] with the extensions and modifications specified in
   this document.  The described organization is provided to facilitate
   the explanation of how the protocol should behave.  This document
   does not mandate that implementations adhere to this model as long as
   their external behavior is consistent with that described in this
   document.


5.1.  Conceptual Data Structures

   This section specifies the conceptual data structures with focus on
   the parts that are different than in [MIPv6].

   Each IPv6 node will need to maintain the following pieces of
   information:

      Binding Cache
         - A cache capturing information for mobile nodes from which the
           node has received and accepted a Binding Update message.

           The cache is indexed by the Home Address of the MN.  Each
           entry contains:

            o Home Address.  See [MIPv6].

            o Care of Address.  See [MIPv6].

            o The state of the binding.  This can be either "valid" or
              "invalid".  Binding Cache entries only effect packet
              transmission when they are in the "valid" state.  In order
              to prevent certain replay attacks, e.g., after a binding
              has been removed by a BU with a zero lifetime, binding
              cache entries might need to be retained to suppress
              duplicates for up to CookieLifetime seconds.  Such entries
              are in "invalid" state.

            o Lifetime of the binding.  Once this lifetime expires the
              binding cache entry must be either deleted or marked
              invalid.  Unlike [MIPv6] the lifetime is a function of
              both the lifetime field in the BU packets and the delay
              between generating the BUC cookie and receiving the BU.

            o Last update time.  This field contains the local timestamp
              value from the cookie indicating when the binding cache



draft-nordmark-mobileip-bu3way-00.txt                          [Page 16]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


              entry was created or last updated by a BU message.

            o Cookie Lifetime.  Set from the BU that last created or
              updated the binding.

            o The Acknowledgement Cookie value and an indication whether
              this field is valid i.e. set from a Binding Update
              message.  This might be useful if the protocol is extended
              to use the Acknowledgement Cookie to filter out spoofed
              Binding Request messages.  Note that this specification
              currently does not apply such filtering; in fact it is
              silent on the use of BR messages.


           In addition, on a Home Agent the binding cache entries
           contain additional information which is specified in [MIPv6].

      AdvCookieLifetime.
         - The CookieLifetime the CN uses to send in BUC messages.  MUST
           not exceed MAX_COOKIE_LIFETIME.

      List of secrets
         - A list with all the secrets that the CN has used to generate
           BUC cookies in the last AdvCookieLifetime seconds.  This list
           contains either one or two entries, unless the CN creates a
           new secret more often than every AdvCookieLifetime seconds.

           Each entry in the list has the secret as well as the
           timestamp value the last time the secret was used to create a
           cookie.


   Each Mobile Node, in addition to the above per-node conceptual data
   structures, need to maintain

      Binding Update List
         - A list with all nodes to which the MN has sent a BUR or BU
           and the binding has not yet expired.

           The binding update list is indexed by address of the CN to
           which the BUR or BU was sent and the Home Address i.e., there
           can only be one entry per each <CN, HoA> pair.

           Each entry contains:

            o The IP address to which the BUR or BU was sent.  See
              [MIPv6].




draft-nordmark-mobileip-bu3way-00.txt                          [Page 17]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


            o The Home Address for which the binding was made.  See
              [MIPv6].

            o The Care of Address in the last binding update sent.  See
              [MIPv6].

            o The state of the binding.  The possible states are
              BUC_WAIT (sent BUR; waiting for a BUC), BA_WAIT (send BU;
              waiting for BA), NO_BA (sent BU not requesting a BA), and
              BA_OK (not waiting for anything).

            o Remaining Cookie Lifetime.  Set to the CookieLifetime when
              the BUC is received and decremented as time passes.  This
              is needed to avoid retransmitting BUs using a cookie that
              is older than the CookieLifetime in the BUC since the CN
              will ignore such cookies.

            o When in the BA_WAIT or NO_BA state: the cookie received in
              the BUC to be used when retransmitting the BU.

            o The Acknowledgement Cookie value used.

            o The initial value of the lifetime field sent in the BU.
              See [MIPv6].

            o The remaining lifetime of the binding.  See [MIPv6].

            o The time a BUR or BU was last sent (transmitted or
              retransmitted) needed in order to rate limit the sending
              and implement retransmissions.

            o The state of the binary exponential back-off mechanism for
              BUR and BU messages.  This is a factor which is multipled
              with the retransmit timer value and doubled for each
              unsuccessful retransmission.

            o A flag that, when set, indicates that future BUR and BU
              messages should not be sent to the destination.  See
              [MIPv6].




5.2.  Forming Cookies

   The recommended way to form cookies is to use a secret (the current
   secret in the list of secrets), a keyed hash, and a timestamp.




draft-nordmark-mobileip-bu3way-00.txt                          [Page 18]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   The timestamp should have a finer granularity than the minimal
   spacing between subsequent binding updates in order to prevent two
   binding updates from the same MN using the same timestamp.  Should
   the same timestamp be used then the "new" BU will be considered to be
   a replay of an "old" BU and be ignored i.e., the MN would fail to
   update the binding cache.

   Therefor it is recommended that the timestamp have a granularity of
   one millisecond or better.

   The number of bits in the timestamp should be such that an attacker
   can not just wait for the timestamp to wrap around and then replay an
   old BU with what now looks like a new timestamp.  This threat can be
   avoided by requiring that a new secret is used before the time stamp
   wraps around.  For example, if a 32-bit timestamp with granularity
   one millisecond is used than a new secret must be generated at least
   every 4 million seconds i.e. about 1000 hours.

   Note that when a new secret is generated the node should continue to
   use the monotonically increasing timestamps to be able to tell
   whether the old or new secret was used for handshakes that were in
   progress during the change of secret.

   When the node looses all state e.g., when it reboots, the node can
   choose to either use the same secret as before the reboot provided
   that it ensures that the timestamps are monotonically increasing
   across the reboot and ensures that no BU message are accepted until
   at least AdvCookieLifetime seconds after the loss of state.  (The
   latter is easy to ensure if it takes at least AdvCookieLifetime
   seconds to reboot.)  If the node can not make this guarantees then it
   should select a new secret each time it reboots.

   The secret MUST be a good random number as specified in [RANDOM].

   The recommended algorithm to use for the keyed hash is for further
   study.  MD5 or SHA-1 are likely choices.

   The keyed hash should operate on the concatenation of the timestamp,
   the HoA, the CoA, and CN's address, and the AdvCookieLifetime that
   will be sent in the Binding Update Challenge Message.

   Then the cookie can be formed by concatenating the timestamp and the
   hash value.  With a 32-bit timestamp it becomes 4 octets of timestamp
   followed by TBD bytes of hash.

   TBD: Specify the length of the cookie based on the algorithm chosen.





draft-nordmark-mobileip-bu3way-00.txt                          [Page 19]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


5.3.  Garbage Collection and Timeout Requirements

   Unlike in [MIPv6] a CN can not arbitrarily choose to garbage collect
   binding cache entries, since that would open up potential replay
   attacks.

   Independently of how a binding cache entry is deleted i.e. whether
   its lifetime expires, the CN desires to garbage collect it, or the CN
   receives a BU with a zero lifetime, the CN must retain the binding
   cache entry in the "invalid" state for at least AdvCookieLifetime
   seconds after the entry is deleted.

   This ensures that even if an attacker sent a Binding Update Request
   and received a cookie (valid for AdvCookieLifetime seconds) just
   before the binding cache entry was deleted, the cookie contained in
   the Binding Update Challenge can not be used to recreate an old
   binding for the MN.

   Even without the ability to do arbitrary garbage collection of
   binding cache entries the CN can still control the size of this
   cache.  This can be done by rejecting either Binding Update Request
   messages (by silently dropping them) or by rejecting Binding Update
   messages when there is no more space in the cache.  In addition, the
   ability for the CN to use different CookieLifetime values can help.
   But in order to conform the state loss behavior above the CN needs to
   have a conservative (i.e., maximum) estimate of the CookieLifetime
   value used before loosing the state.  Thus a CN that varies the
   AdvCookieLifetime over time must maintain the maximum cookie lifetime
   value that it has used.  This can be done by using the
   MAX_COOKIE_LIFETIME constant.


   As specified in [MIPv6] a mobile node can not choose to garbage
   collect binding update list entries.  They must be allowed to time
   out based on the lifetime of the binding as specified in [MIPv6].


6.  BEHAVIORAL SPECIFICATION

   This section describes the rules for sending and receiving the
   messages used by this protocol.


6.1.  Sending Binding Update Request Messages

   When a MN wishes to provide a binding update for a CN it first checks
   if there is a binding update list entry for the <CN,HoA> pair.  If
   such an entry exists and is in state BUC_WAIT or BA_WAIT then there



draft-nordmark-mobileip-bu3way-00.txt                          [Page 20]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   is already an on-going attempt to create such a binding thus the
   retransmissions will take care of creating one if possible.

   If the state is BA_OK then the previous BU was acknowledged with a BA
   and a new binding update exchange is only necessary should the CoA
   have changed since the last one.

   If the state if NO_BA it might be the case that the unacknowledged BU
   was lost.  In this case, assuming that "last sent" indicates that the
   last BU was sent more than the binary backed off timeout seconds ago,
   then an additional BU can be sent per the retransmission rules in
   section 6.9.  Note that the BU retransmission rules might determine
   that the cookie from the BUC is too old and revert to sending a new
   BUR.

   If no binding update list entry then one is created for <CN,HoA>.
   The state of the existing or created binding cache entry is set so
   that

    - The CoA is the current CoA of the MN

    - the state is BUC_WAIT

    - the time last sent set to the current time

    - the binary exponential back-off factor set to 1.

    - The flag to not send BUR/BU set to false


   Then a BUR message is formatted according to section 4.1 and
   transmitted.

   Note that since the source address of the BUR is always the Care of
   Address, the BUR will never be reverse tunneled to the HA of the
   sender.


6.2.  Retransmission of Binding Update Request Messages

   When the retransmission timer fires and the binding update list entry
   is in state BUC_WAIT the MN

    - Double the binary exponential factor.  This is used to compute the
      next timeout value.

    - Records the current time in the "time last sent"




draft-nordmark-mobileip-bu3way-00.txt                          [Page 21]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


    - Retransmits the BUR message.




6.3.  Validation of Binding Update Request Messages

   A node MUST silently discard any received Binding Update Request
   messages that do not satisfy all of the following validity checks:


      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 24 or more octets.

      - The IP source address is not a multicast address or the
        unspecified address.

      - The IP destination address is not a multicast address or the
        unspecified address.

      - The Home Address field is not a multicast address or the
        unspecified address.


   The contents of the Reserved field and any data after the first 24
   octets MUST be ignored.  Future, backward-compatible changes to the
   protocol may specify the contents of the Reserved field or add fields
   after the Home Address field; backward-incompatible changes may use
   different Code values.


   A binding update request that passes the validity checks is called a
   "valid BUR".


6.4.  Processing Valid Binding Update Request Messages


   The processing consists of forming a cookie as specified in section
   5.2 and sending a Binding Update Challenge message.

   No state is created on the node doing this processing.






draft-nordmark-mobileip-bu3way-00.txt                          [Page 22]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


6.5.  Sending Binding Update Challenge Messages

   A BUC message is formatted as specified in section 4.2.  The
   CookieLifetime field is set to the value of AdvCookieLifetime.

   If the sending node has a binding cache entry for the destination of
   the BUC then the sending MUST bypass that and send the packet
   directly to the destination address i.e. not add a routing header per
   the information in the binding cache.  This ensures that the HA-MN
   pre-established security association can be used to provide
   confidentiality for the cookie between the HA and MN.

   If the sending node is a mobile node itself then it MUST reverse
   tunnel the BUC message through its home agent.  This removes any
   concerns about ingress filtering and allows the cookie field to be
   confidential on the path from the sender to its home agent.

   The Binding Update Challenge messages are never retransmitted.
   Instead, if the BUC is lost, then MN will retransmit the BUR causing
   a new BUC to be sent.


6.6.  Validation of Binding Update Challenge Messages

   A node MUST silently discard any received Binding Update Challenge
   messages that do not satisfy all of the following validity checks:


      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 24 or more octets.

      - The IP source address is not a multicast address or the
        unspecified address.

      - The IP destination address is not a multicast address or the
        unspecified address.

      - The Care of Address field is not a multicast address or the
        unspecified address.


   The contents of the Reserved field MUST be ignored.  Future,
   backward-compatible changes to the protocol may specify the contents
   of the Reserved field; backward-incompatible changes may use
   different Code values.



draft-nordmark-mobileip-bu3way-00.txt                          [Page 23]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   A binding update challenge that passes the validity checks is called
   a "valid BUC".


6.7.  Processing Valid Binding Update Challenge Messages

   The MN will first look up the <CN, HoA> in the binding update list.
   If no entry is found, if the entry is not in BUC_WAIT state, or if
   the CoA field does not match the Care of Address field in the BUC,
   then the BUC must be silently dropped.

   Then the MN updates the binding update list information with

    - Record the time the BUC was received

    - Record the Cookie.

    - Record the CookieLifetime in the Remaining Cookie Lifetime.  This
      value will limit for how long the BU will be retransmitted using
      this cookie.

    - Cancel any timer for retransmitting the BUR for that entry.

    - Set the state of NO_BA.

    - Set the time last sent to the current time (since a BU will be
      sent)

    - Reset the exponential back-off factor to 1.

    - Set the lifetime field in the binding cache entry to the lifetime
      value that will be sent in the BU.


   In addition, if the MN will set the A-bit in the BU in order to
   request a Binding Acknowledgement it:

    - Computes a 64-bit random number and store that in the
      Acknowledgement Cookie field in the binding cache entry.

    - Sets the state to BA_WAIT.



6.8.  Sending Binding Update Messages

   If the sending node has a binding cache entry for the destination of
   the BU then the sending MUST bypass that and send the packet directly



draft-nordmark-mobileip-bu3way-00.txt                          [Page 24]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   to the destination address i.e. not add a routing header per the
   information in the binding cache.  This ensures that the HA-MN pre-
   established security association can be used to provide
   confidentiality for the cookie between the HA and MN.

   The source address of the BU is the Home Address.  Thus the packet
   MUST be reverse tunneled through the home agent.  This removes any
   concerns about ingress filtering and allows the cookie field and
   acknowledgement cookie field to be confidential on the path from the
   sender to its home agent.

   Then a BUR message is formatted according to section 4.3 and
   transmitted.


6.9.  Retransmission of Binding Update Messages


   When the state is BA_WAIT BUs will be retransmitted based on a
   timeout.  When the state is NO_BA then BUs will be retransmitted,
   subject to the rate limiting imposed by the binary exponentially
   backed off timeout value, when the MN receives a packet from the CN
   which has been tunneled by the HA to the MN since this indicates that
   the CN did not receive and accept the BU message.

   When this happens and the Remaining Cookie Lifetime in binding update
   list entry is less than zero the then the cookie is too old to use in
   a retransmission.  In this case the state should be changed to
   BUC_WAIT without changing the binary exponential back-off factor and
   immediately retransmit the BUR as specified in section 6.2.

   Otherwise the retransmission should be handled as follows:

    - Double the binary exponential factor.  This is used to compute the
      next timeout value.

    - Records the current time in the "time last sent"

    - Retransmits the BU message.   If the A-bit is set the
      Acknowledgement Cookie field is set from the binding cache entry
      i.e., retransmitted BU messages have the same Acknowledgement
      Cookie value.









draft-nordmark-mobileip-bu3way-00.txt                          [Page 25]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


6.10.  Validation of Binding Update Messages

   A node MUST silently discard any received Binding Update messages
   that do not satisfy all of the following validity checks:


      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 40 or more octets.

      - The IP source address is not a multicast address or the
        unspecified address.

      - The IP destination address is not a multicast address or the
        unspecified address.

      - The Care of Address field is not a multicast address or the
        unspecified address.


   The contents of the Reserved field MUST be ignored.  Future,
   backward-compatible changes to the protocol may specify the contents
   of the Reserved field; backward-incompatible changes may use
   different Code values.


   A binding update that passes the validity checks is called a "valid
   BU".


6.11.  Processing Valid Binding Update Messages

   The CN must first extract the timestamp and the hash from the cookie
   field in order to verify them.  The suggestion in section 5.2 is that
   the timestamp is the first 4 octets of the cookie followed by the
   hash.

   If the timestamp is more than the CookieLifetime field in the BU or
   the CookieLifetime field is more than MAX_COOKIE_LIFETIME then the
   message MUST be silently discarded.  If the timestamp is new i.e.
   greater than the current time then the message is a replay after the
   timestamp wrapped around and the message MUST be silently discarded.

   The node use the timestamp to determine which secret was used to
   generate the keyed hash based on the secret list.  Then it can
   compute the keyed hash using the same algorithm that it used when



draft-nordmark-mobileip-bu3way-00.txt                          [Page 26]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   sending the BUC; using that secret and the information in the packet
   (Care of address, Correspondent address, Home address, timestamp, and
   CookieLifetime) as specified in section 5.2.  If the generated hash
   does not match the hash in the received cookie then the packet MUST
   be silently discarded.

   Next the node MUST verify against the binding cache to make sure that
   the BU is not the replay of an old binding update.  If there is no
   binding cache entry for the home address then the BU can not be a
   duplicate per the rules in section 5.3.  If there already exists a
   binding cache entry for the home address then compare the "last
   update time" timestamp in that entry with the timestamp contained in
   the cookie.  If the timestamp is older than the one in the binding
   cache entry then the BU MUST be silently discarded.  Note: BUs where
   the timestamp matches are processed in order to generate a Binding
   Acknowledgement in response to a retransmitted BU.

   At this point the node knows that the BU is indeed a valid and
   authentic one.  Thus it creates or updates the entry in binding cache
   as specified in [MIPv6].  Note that the lifetime used is the above
   conservative estimate.  In addition it records the timestamp part of
   the cookie field in the "last update" field in the binding cache
   entry.  (Note that the timestamp in the cookie is recorded - not the
   current time when the BU is received by the CN.)

   If a BU with a lifetime of zero is received an no binding cache entry
   exists then no binding cache entry needs to be created.  However,
   should a binding cache entry exist in this case than that entry can
   not be immediately deleted in all cases.  The binding cache entry
   must remain in "invalid" state for at least CookieLifetime seconds
   after the last non-zero lifetime BU was received as specified in
   section 5.3 in order to prevent replays after MN moves home and de-
   registers.

   If the A-bit is set in the BU message the node records the
   Acknowledgement Cookie in the binding cache entry and sends a Binding
   Acknowledgement message.


6.12.  Sending Binding Acknowledgement Messages

   If the sending node has a binding cache entry for the destination of
   the BA then the sending MUST bypass that and send the packet directly
   to the destination address i.e. not add a routing header per the
   information in the binding cache.  This ensures that the HA-MN pre-
   established security association can be used to provide
   confidentiality for the acknowledgement cookie between the HA and MN.




draft-nordmark-mobileip-bu3way-00.txt                          [Page 27]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   If the sending node is a mobile node itself then it MUST reverse
   tunnel the BA message through its home agent.  This removes any
   concerns about ingress filtering and allows the cookie field to be
   confidential on the path from the sender to its home agent.

   Form the Binding Ack as follows:

     - The Lifetime field is set to the minimum of the conservative
      lifetime above and whatever the CN wishes to support.

    - The Status and Refresh is set as in [MIPv6].

    - The acknowledgement cookie and care of address is set from the
      binding cache fields.


   The binding acknowledgement is never retransmitted by the CN.  Should
   the BA be lost then the MN will retransmit the BU and in some cases
   the MN will need to retransmit the BUR due to a too old cookie.


6.13.  Validation of Binding Acknowledgement Messages

   A node MUST silently discard any received Binding Acknowledgement
   messages that do not satisfy all of the following validity checks:


      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 40 or more octets.

      - The IP source address is not a multicast address or the
        unspecified address.

      - The IP destination address is not a multicast address or the
        unspecified address.

      - The Care of Address field is not a multicast address or the
        unspecified address.


   The contents of the Reserved field and any data after the first 40
   octets MUST be ignored.  Future, backward-compatible changes to the
   protocol may specify the contents of the Reserved field or add fields
   after the Care of Address field; backward-incompatible changes may
   use different Code values.



draft-nordmark-mobileip-bu3way-00.txt                          [Page 28]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   A binding acknowledgement that passes the validity checks is called a
   "valid BA".


6.14.  Processing Valid Binding Acknowledgement Messages

   The MN will first look for a matching <CN, HoA> in the binding update
   list.  If no entry exists, the CoA doesn't match, or the state in the
   entry is not BA_WAIT then the BA MUST be silently discarded.

   If the acknowledgement cookie field in the packet does not match the
   acknowledgement cookie in the binding update list then the packet
   MUST be silently discarded.

   Mark the binding update list entry with state BA_OK and stop any
   timers associated with retransmitting BUs.


7.  SECURITY PROPERTIES

   The following set of threats are believed to be handled by the
   proposal:

    - Off-paths attackers are prevented by the use of the Cookie in the
      BUC-BU exchange.

    - Off-path attackers can't inject spoofed binding acknowledgements
      due to the acknowledgement cookie in the BU-BA exchange.

    - Replay attacks of BUs after a new BU has been received by a CN are
      ignored due to the timestamp in the cookie being older.

    - Replay attacks of BUs while the MN is in the location indicated by
      the BU has no effect; the cookie can not be used with a different
      CoA, Home Address, CN address, or timestamp.

    - Replay attacks after a MN has moved home and unregistered with a
      CN (using a BU with lifetime zero) have no effect since the
      binding cache state is maintained (with no effect on routing) for
      AdvCookieLifetime.

    - While the MN remains at the same CoA there is no effect of
      replaying/repeating the same BU since it doesn't redirect packets
      away from the correct CoA.  Replay attacks after a MN has become
      unreachable are of course possible for CookieLifetime seconds, but
      once the MN becomes reachable on a different link, it will
      initiate a new BUR/BUC/BU exchange based on the binding update
      list.  The rules in section 6.11 ensure that this will happen.



draft-nordmark-mobileip-bu3way-00.txt                          [Page 29]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


    - Replay attacks due to the CN garbage collecting the binding cache
      entries or loosing state are avoided using the rules in section
      5.3.

    - Flooding of spoofed BUR messages to a CN causes the CN compute a
      keyed hash and to send a BUC message.  It does not create any
      state based on this.  The BUC message is sent to the Home Address
      field in the BUR, but the IP source address of the BUR is included
      in the BUC message.  Thus this can not be used as a more severe
      type of reflector attack than e.g. an ICMP echo packet. [TBD: The
      reflector threat is a bit different than an ICMP echo due to the
      extra address in the packets.  Perhaps the BUR should be sent with
      the HoA as the source i.e. reverse tunneled through the HA to
      reduce the reflector risk.]

    - Flooding of spoofed BUC and BA packets cause a minimal amount of
      work to determine that the corresponding BUR and BU where never
      sent.

    - Flooding of spoofed BU packets causes some work on the CN to
      compute the keyed hash and compare it with the cookie in the
      message in order to reject the message.



7.1.  Residual Threats

   A node capable of passively observing packets between the CN and HA
   as well as being able to send packets, can redirect packets for any
   MN using that HA.  This requires neither being able to modify the
   packets being delivered towards the HA, nor being able to prevent
   those packets from being delivered.

   Note that the above threat is introduced by Binding Updates whether
   or not the node named MN is indeed a mobile node; there is no way a
   CN can tell that a node isn't mobile.  The reception of a binding
   update is taken as proof that the sender is indeed mobile.

   This is done by the attacker sending a BUR and seeing the resulting
   BUC, taking the cookie from that packet to form a BU.  The MN will
   also observe the BUC but it will silently ignore it since it has not
   sent a BUR (and having the MN do anything differently would make BUCs
   a potential DoS attack opportunity).

   If ingress filtering [INGRESS] is used then the CoA that the attacker
   can use is limited to what the attacker can put in the IP source
   address field, which is not very limiting.




draft-nordmark-mobileip-bu3way-00.txt                          [Page 30]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   Note that this threat is potentially more severe than what it takes
   to redirect traffic without using of Binding Updates; an attacker on
   the path between two nodes can of course observe all the traffic but
   it requires some active capability on the link for it to be able to
   prevent this packets to be delivered.  An example of such active
   capabilities would be use of the Neighbor Discovery protocol on a
   shared Ethernet to make packets destined to the next hop router
   instead arrive at the attacker.

   A particular flavor of this attack is an attacker or the same LAN as
   the CN or HA.

   Note that the threat applies to any node; the CN has no means of
   determining whether a node is mobile or not but instead infers this
   from the reception of a BU with a matching cookie.

   A node capable of passively observing packets between the HA and MN
   can launch the same type of attack under the same constraints.  This
   includes nodes on the same LAN as the MN.  However, if the pre-
   established security association between the HA and MN provides in
   confidentiality, then such attacks are prevented.

   It is also possible for an attacker to inject spoofed data traffic
   (e.g., an ICMP echo) from a valid CN address to the MN with the
   intent to make the MN perform a binding update exchange which will
   create state in the CN's binding cache and in the MN's binding update
   list.  This threat is external and independent of the actual
   mechanism to perform the binding update.  The only known technique to
   address it is to have some threshold in the MN when it comes to
   performing a binding update which a CN which isn't already in the
   binding update list so that it requires multiple packets to and from
   the CN before the binding update is triggered.  Note that CNs in the
   binding update list need to be notified of the new CoA when the MN
   moves thus they can not be subject to such a threshold.

   TBD: Does the ICMP parameter problem cause a threat?  As specified
   [MIPv6] the reception of such indicating that the CN doesn't
   understand binding update options/messages is supposed to make the MN
   stop sending binding updates to the CN.  They could be used to make a
   MN mark the binding update list entry as "don't bother sending BUR/BU
   to this node".  It isn't clear what affect such marking will (or
   should) have on the behavior of the MN and whether this behavior can
   be exploited.  Thus such ICMP messages appear to be usable by an
   attacker to prevent a CN from receiving binding updates.







draft-nordmark-mobileip-bu3way-00.txt                          [Page 31]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


7.2.  HA to MN Security Association

   A possible way to prevent attackers on the path between the HA and MN
   is to protect all packets that the HA tunnels to the MN using a pre-
   established security association that provides confidentiality.

   However, such a approach might be deemed costly for mobile devices
   with limited crypto performance.  Thus there might be a desire to
   only apply the confidentiality to packets related to binding updates;
   in particular the BUC packets containing the cookie needed to
   generate a BU.

   This could be approached by making the HA apply different security
   associations depending on the content of the packets being
   encapsulated.  The specification of selectors in [IPv6-SA], appear to
   say that the selectors (such as protocol type; port numbers) apply
   when packets are forwarded as well as originated.  However, it isn't
   clear to what extent existing IPsec implementations have this
   capability to use different IPsec tunnels depending on the selectors
   in the forwarded packets.  Also, it isn't clear what the performance
   impact would be in such a case since the Home Agent would need to
   inspect the selectors when forwarding packets to mobile nodes.

   Conceptually an alternative would be to make the BUC packets be
   addressed to the Home Agent (instead of the MN's Home Address) but
   this is non-trivial since

    o The CN has no way of finding out the address of the HA

    o In general the MN can't tell the CN the HA address, since that
      would allow a form of spoofing by an attacker claiming that the HA
      is some node other than the real HA.


   It might be possible, by hard-coding the knowledge of 64-bit
   prefixes, to either:

    o Have the CN determine the all-home agents anycast address for the
      MN based on the MN's home address.

    o Have the MN send a HA's address to the CN, and have the CN verify
      that the address falls in the same 64-bit prefix as the MN's home
      address.


   But hard-coding the 64-bit prefix boundary in nodes that are not
   attached to the particular link where the prefix is assigned would
   remove some flexibility in evolving the IPv6 addressing architecture



draft-nordmark-mobileip-bu3way-00.txt                          [Page 32]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   over the lifetime of the IPv6 protocol.


7.3.  MN to MN Binding Updates

   As specified any attacker on the same LAN as the CN can redirect
   traffic destined from the CN to any node on the Internet as outlined
   in the previous section.

   Of course, such a threat might not be much severe than the ability to
   use Neighbor Discovery to spoof the IP address of the routers on the
   LAN, thereby being able to redirect or capture all packets sent by a
   CN.  Given the increasing prevalence of wireless LANs and other
   public access LANs, it is important to understand the security
   properties for such cases.

   However, in the case that the CN is also a mobile node, i.e., it has
   a pre-established security association with its home agent, then this
   security association potentially provides better security than
   without mobile IPv6.  This is done by the specification requiring
   that BUC, BU, and BA messages are reverse tunneled to the HA, which
   is also required to avoid any ingress filtering problems for the BUC
   and BA messages.

   This specification also requires that the BUC, BU and BA messages are
   sent bypassing any binding cache entry.  This means that a
   correspondent that is mobile can in fact reject any BUC, BU and BA
   messages that are not received over the secure channel from its HA.

        ----------
        |        |
        |   HA1  |
        |        |                                     -------------  LAN
        ----------                                     |           |
          |    |                                  ----------   ----------
          |    |                                  |        |   |        |
          |    | Secure tunnel                    |   CN   |   |    X   |
          |    |                                  |        |   |        |
          |    |                                  ----------   ----------
          |    |
        ----------
        |        |
        |   MN1  |
        |        |
        ----------

        Figure 1: Attacker next to CN




draft-nordmark-mobileip-bu3way-00.txt                          [Page 33]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   In Figure 1 the X can send a BUR to CN specifying that the home
   address MN1 and the care of address X (or any other care of address).
   Note that MN1 could be any node in the Internet; in particular it
   does not need to be a mobile node.

   X would be able to observe the BUC sent by the CN towards the
   specified home address, and could use this to send a BU to the CN.

        ----------                                ----------
        |        |                                |        |
        |   HA1  |                                |   HA2  |
        |        |                                |        |
        ----------                                ----------
          |    |                                    |    |
          |    |                                    |    |
          |    | Secure tunnel                      |    | Secure tunnel
          |    |                                    |    |
          |    |                                    |  -------------  LAN
          |    |                                    |  | |         |
        ----------                                ----------   ----------
        |        |                                |        |   |        |
        |   MN1  |                                |   MN2  |   |    X   |
        |        |                                |        |   |        |
        ----------                                ----------   ----------

        Figure 2: Attacker next to CN which is a mobile node

   Given the rules in section 6, the same attack would not be effective
   in figure 2.  While X can send the BUR to MN2, MN2 will reverse
   tunnel the BUC to HA2 and HA2 will forward the packet towards HA1.
   Thus assuming that the MN2-HA2 security association provides
   confidentiality then X is not able to generate a BU with a matching
   cookie.  And MN1 will not respond to the BUC caused by the spoofed
   BUR since it did not send the BUR.


8.  ORTHOGONAL SECURITY ISSUES

   The following issues that have been identified on the Mobile IP WG
   mailing list are not addressed in this document:

    - Use of unauthenticated Home Address options for general reflector
      attacks.

    - Possible DoS attacks by flooding Binding Requests; potentially
      with spoofed IP source addresses.





draft-nordmark-mobileip-bu3way-00.txt                          [Page 34]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   It is the author's belief that solutions to that problem are
   orthogonal to the proposed use of 3-way BUs.

   For instance, a possible solution to the unauthenticated Home Address
   option would be to

    - have the CNs reject packets with a Home Address option unless they
      have a matching binding cache entry, and

    - require that MNs by default tunnel all packets (where the IP
      address is its home address) through its home agent

    - When the MN knows that the CN will accept the Home Address option
      i.e., when it has received a binding ack from the CN, the it can
      optionally use the Home Address option thus avoid tunneling
      packets through the home agent.

    - A CN can not discard (garbage collect or loose) a binding cache
      entry until the lifetime of the binding expires, unless it can
      notify the MN that it can no longer use a home address option.


   Thus such a solution has no bearing on the proposal in this document.

   Also, handling of Binding Requests is also likely to be orthogonal.
   A MN could simply silently ignore any binding requests unless it has
   a binding update list entry for the CN and Home Address.

   Note in such an approach the acknowledgement cookie provided by this
   proposal might be helpful; one could require that the binding request
   contain the acknowledgement cookie from the last BU to prevent off-
   path attackers from injecting binding requests with a spoofed CN IP
   source address.

   The details of addressing these threats are outside of the scope of
   this document.


9.  WHAT IFS - ALTERNATE APPROACHES

   This section tries to provide some initial thoughts on how the
   security properties of the solution would change with a few
   modifications to the protocol described above.  The purpose of this
   is to try to feed a discussion in order to gain a wider understanding
   of how the security properties are different in different parts of
   the design space.

   This section does not claim to be complete.  In fact it only looks at



draft-nordmark-mobileip-bu3way-00.txt                          [Page 35]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   two possible modifications:

    o During the first 3-way BU as specified in the protocol,
      additionally pass a clear-text key from the CN through the HA to
      the MN.  The MN can then use that key to authenticate future BUs
      and not require a 3-way handshake.

    o As part of the first 3-way BU exchange perform a Diffie-Hellman
      exchange to establish a shared secret between the MN and CN.  Use
      the shared secret to secure future BUs.


   The purpose of looking at the first modification is to understand the
   implications of trying to optimize the exchange for subsequent BUs.
   The purpose of looking at the second modification is to try to
   understand how to potentially limit the capabilities of attackers
   that are mostly passive.


9.1.  Establish a Key for Authenticating BUs

   For the purposes of making it simple to describe this modification it
   makes sense to introduce an additional message: Authenticated Binding
   Update (ABU) Such a message could of course be encoded as a variant
   of the BU message.

   Also, without loss of generality, assume that it is the Binding
   Acknowledgement that carries the authentication key from CN to MN.
   [It is also possible to carry this on the BUC but in order to avoid
   the CN creating state when receiving a BUR this requires making the
   authentication key be derived in similar ways to the Cookie sent in
   the BUC.  This is probably possible but introduces complexities that
   are not believed to be germane to understanding the security
   properties in general.]

   We also assume that the CN send the BA to the Home Address (i.e.,
   bypassing any binding cache entries).  While this isn't strictly
   required it does allow using the assumed MN to HA security
   association to obtain higher security.

   The idea in this modification is that the exchange consists of a BUR,
   BUC, BU, and an additional BA.  In the BU there is a bit indicating
   that the MN requests a authentication key.  This causes the CN to
   generate such a key, store it in the binding cache entry, and send it
   in the clear to the MN with the binding ack.

   Presumably the binding ack would be extended to carry not only the
   key but also the lifetime of the key and the algorithm used to



draft-nordmark-mobileip-bu3way-00.txt                          [Page 36]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   authenticate such as HMAC-SHA1.

   The MN would then, after verifying the binding ack using the
   acknowledgement cookie as before, store the authentication key in the
   binding update list.

   When the MN needs to update the binding in the CN, it would form a
   Authenticated Binding Update message and authenticate that using the
   key and algorithm.  This then forms some authentication data which is
   included in the ABU.

   The CN then needs to verify the ABU packet.  It would use the Home
   Address to lookup the binding cache entry for the MN.  This would
   contain the authentication key which is then used to verify the
   authentication data included in the ABU.  Presumably the ABU would
   contain a sequence number (starting at zero for the first ABU sent
   after receiving the authentication key) that might protect against
   certain replay attacks.

   The properties of such a scheme seem to be that, since anybody on the
   path between the CN and the HA can see the BA packet, attackers on
   path can redirect packets.  To no surprise this isn't any better than
   the proposed 3-way protocol.

   But also, an attacker that was on the path between the HA and MN when
   the authentication key was established but due to later movements of
   the MN no longer is on that path, can use the authentication key to
   redirect the MN's traffic during the lifetime of the authentication
   key.  The use of a sequence number in the ABU packet doesn't protect
   against this since the attacker can presumably pick large sequence
   numbers whereas the MN itself would use sequence numbers 0,1,2,3 etc
   as it moves.  Thus such a sequence number would just protect against
   subsequent BU packets from the legitimate MN being reordered in the
   network.

   The above concern can presumably be addressed by requiring that the
   BA containing the authentication key be protected by an HA to MN
   security association that provides confidentiality.  In such a case
   the cursory analysis on this approach seems to have the same security
   properties as the original 3-way proposal i.e. in that case they
   share the same residual threats with respect to nodes that are on the
   path between the CN and HA.


9.2.  Diffie-Hellman Exchange

   Assume that once the BUR/BUC/BU exchange has happened there is an
   ephemeral Diffie-Hellman exchange between the CN and MN.  This



draft-nordmark-mobileip-bu3way-00.txt                          [Page 37]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


   exchange could presumably be done by the CN sending packets to the
   MN's home address and the MN reverse tunneling the packets through
   its home agent.  Such an approach, combined with confidentiality for
   these packets over the HA-MN path, seems to add additional security
   beyond the original 3-way proposal.

   In particular, an attacker would need to be more active than an
   attacker in the 3-way scheme.  For instance, an attacker on the same
   LAN as the CN would not only need to observe the packets passing by
   but would instead need to actively insert itself as a Man-in-the-
   Middle in the Diffie-Hellman exchange by intercepting packets in both
   directions, being able to inject modified packets, and perhaps being
   able to prevent that the original packets it intercepted are not
   delivered. [TBD: Is this difference significant?]

   If a DH exchange is done it can presumably start with the BU i.e.,
   the BU and BA packets would perform the exchange.  It would be
   undesirable to start the exchange before this point in time since the
   CN should avoid to create any state before the 3-way handshake has
   completed.


10.  PROTOCOL CONSTANTS

   Common constants:

            MAX_COOKIE_LIFETIME       30 seconds

   All protocol constants are subject to change in future revisions of
   the protocol.


11.  CONCLUSIONS

   The section tries to extract some lessons from designing and
   analyzing the bu3way proposal.

   For the purposes of this section we define these names for the
   variants of the proposal:

    o bu3way-int is the proposal with just integrity protection for the
      HA-MN paths

    o bu3way-conf is the proposal with confidentiality on the HA-MN
      paths

    o bu3way+key-int is the outline of the ideas in section 9.1 with
      just integrity for the HA-MN paths



draft-nordmark-mobileip-bu3way-00.txt                          [Page 38]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


    o bu3way+key-conf is that outline with confidentiality on the HA-MN
      paths


   The conclusions so far are:

    - bu3way-int: Anybody on the MN-HA path can spoof binding updates as
      long as they are on the path.  They have to spoof for each BU sent
      by the MN.  So when the MN moves they will loose this ability if
      they are no longer on the MN-HA path.

    - bu3way-conf: No such spoofing possible.

    - bu3way+key-int: Anybody on the HA-MN path when the key is
      established can spoof BUs for the lifetime of the key even after
      they are no longer on the HA-MN path due to the MN having moved.

    - bu3way+key-conf: No such spoofing possible.


   For potential attackers on the CN-HA path there is not much
   difference whether or an authentication key is distributed or not.
   With bu3way such an attacker can send a BUR with e.g. itself as the
   CoA and snoop the BUC packet between the CN and HA and use it to send
   a BU that will be accepted.  But if ingress filtering [INGRESS] is
   used it can not pick an arbitrary CoA, since the CoA is the source
   address in the BUR.

   With bu3way+key such an attacker can just silently snoop the key from
   the BUC and at some later time during the lifetime of that key, send
   a BU using any CoA.

   In addition, using DH exchange instead of bu3way+key is different in
   that it requires attackers on the CN-HA path to actively insert
   themselves as a man-in-the-middle in the DH exchange, which may or
   may not be more difficult than just snooping at the packets as they
   pass by.


   There are also some performance tradeoffs between distributing an
   authentication key or not:

    o How many binding updates are performed between a pair of MN and CN
      vs. the cost of creating the authentication key.  If there is only
      one binding update than bu3way+key is slower since it needs to
      generate a key.





draft-nordmark-mobileip-bu3way-00.txt                          [Page 39]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


12.  SECURITY CONSIDERATIONS

   Security issues are discussed in section 7.

   TBD Need to evaluate with respect to [SEC-REQ]



13.  ACKNOWLEDGEMENTS

   The security requirements, threats, and proposed solutions that have
   been discussed on the MobileIP WG mailing list have help form this
   the approach taken in this document.

   Phil Roberts, Jari Arkko, and Claude Castellucci provided comments
   that helped clarify the document.  Phil suggested making the
   CookieLifetime a choice for the CN instead of it being a protocol
   constant.


REFERENCES


  [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol
          (ICMPv6) for the Internet Protocol Version 6 (IPv6)
          Specification", draft-ietf-ipngwg-icmp-v3-01.txt.

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

  [MIPv6] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft-
          ietf-mobileip-ipv6-14.txt.

  [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
          Protocol".  RFC 2401, November 1998.

  [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 2402,
          November 1998.

  [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",
          RFC 2406, November 1998.

  [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
          Requirement Levels", RFC 2119, March 1997.

  [INGRESS] P. Ferguson, D. Senie, "Network Ingress Filtering:
          Defeating Denial of Service Attacks which employ IP Source
          Address Spoofing.", RFC 2827, May 2000.



draft-nordmark-mobileip-bu3way-00.txt                          [Page 40]


INTERNET-DRAFT  Securing BUs using routability (BU3WAY)     Nov 12, 2001


  [SEC-REQ] A. Mankin et al, "Threat Models introduced by Mobile IPv6
          and Requirements for Security in Mobile IPv6", draft-ietf-
          mobileip-mipv6-scrty-reqts-02.txt.

  [RANDOM] D. Eastlake, S. Crocker, J. Schiller, "Randomness
          Recommendations for Security", RFC 1750, December 1994.



AUTHORS' ADDRESSES

     Erik Nordmark
     Sun Microsystems Laboratories, Europe
     29 Chemin du Vieux Chene
     38240 Meylan, France

     phone: +33 (0)4 76 18 88 03
     fax:   +33 (0)4 76 18 88 88
     email: Erik.Nordmark@sun.com
































draft-nordmark-mobileip-bu3way-00.txt                          [Page 41]


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