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]