idnits 2.17.1 draft-nordmark-mobileip-bu3way-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 80 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: AdvCookieLifetime. - The CookieLifetime the CN uses to send in BUC messages. MUST not exceed MAX_COOKIE_LIFETIME. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 12, 2001) is 8200 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6' is defined on line 1789, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 1798, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1801, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-01 -- Possible downref: Normative reference to a draft: ref. 'ICMPv6' ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 ** Obsolete normative reference: RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Normative reference to a draft: ref. 'SEC-REQ' ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 3 Nov 12, 2001 5 Securing MIPv6 BUs using return routability (BU3WAY) 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet Draft expires May 12, 2002. 32 Abstract 34 This document is intended to serve as input to the discussion in the 35 Mobile IP Working Group regarding securing MIPv6 Binding Updates. 36 This document tries to capture a possible extreme point in the design 37 space for a solution to that problem, for the purposes of exploring 38 the design space. The author does not claim that this protocol is 39 better than any other proposed solutions - merely that it is 40 different and the differences can help in understanding design 41 tradeoffs in this space. 43 This proposal relies on using only return routability to verify the 44 authority to perform a binding update. It uses return routability 45 for every Binding Update message i.e., every binding update implies a 46 3-way handshake between the correspondent node and the mobile node. 48 The document also tries to look at how the security properties of the 49 proposed protocol would change when trying to optimize the protocol 50 so that, past the first BU between a MN and a CN, subsequent BUs can 51 be done without a 3-way handshake. 53 Contents 55 1. INTRODUCTION............................................. 3 56 1.1. Assumptions......................................... 3 58 2. TERMINOLOGY.............................................. 5 59 2.1. General............................................. 5 60 2.2. Requirements........................................ 6 62 3. PROTOCOL OVERVIEW........................................ 6 63 3.1. Goals and Requirements.............................. 6 64 3.2. Message flow........................................ 7 66 4. MESSAGE FORMATS.......................................... 9 67 4.1. Binding Update Request Message Format............... 9 68 4.2. Binding Update Challenge Message Format............. 10 69 4.3. Binding Update Message Format....................... 12 70 4.4. Binding Acknowledgement Message Format.............. 14 72 5. CONCEPTUAL MODEL OF A NODE............................... 16 73 5.1. Conceptual Data Structures.......................... 16 74 5.2. Forming Cookies..................................... 18 75 5.3. Garbage Collection and Timeout Requirements......... 20 77 6. BEHAVIORAL SPECIFICATION................................. 20 78 6.1. Sending Binding Update Request Messages............. 20 79 6.2. Retransmission of Binding Update Request Messages... 21 80 6.3. Validation of Binding Update Request Messages....... 22 81 6.4. Processing Valid Binding Update Request Messages.... 22 82 6.5. Sending Binding Update Challenge Messages........... 23 83 6.6. Validation of Binding Update Challenge Messages..... 23 84 6.7. Processing Valid Binding Update Challenge Messages.. 24 85 6.8. Sending Binding Update Messages..................... 24 86 6.9. Retransmission of Binding Update Messages........... 25 87 6.10. Validation of Binding Update Messages.............. 26 88 6.11. Processing Valid Binding Update Messages........... 26 89 6.12. Sending Binding Acknowledgement Messages........... 27 90 6.13. Validation of Binding Acknowledgement Messages..... 28 91 6.14. Processing Valid Binding Acknowledgement Messages.. 29 93 7. SECURITY PROPERTIES...................................... 29 94 7.1. Residual Threats.................................... 30 95 7.2. HA to MN Security Association....................... 32 96 7.3. MN to MN Binding Updates............................ 33 98 8. ORTHOGONAL SECURITY ISSUES............................... 34 100 9. WHAT IFS - ALTERNATE APPROACHES.......................... 35 101 9.1. Establish a Key for Authenticating BUs.............. 36 102 9.2. Diffie-Hellman Exchange............................. 37 104 10. PROTOCOL CONSTANTS...................................... 38 106 11. CONCLUSIONS............................................. 38 108 12. SECURITY CONSIDERATIONS................................. 40 110 13. ACKNOWLEDGEMENTS........................................ 40 112 REFERENCES................................................... 40 114 AUTHORS' ADDRESSES........................................... 41 116 1. INTRODUCTION 118 This document outlines a method for authenticating and authorizing 119 Mobile IPv6 [MIPv6] Binding Updates between a correspondent node and 120 a mobile node where there exists no pre-established direct or 121 indirect security relationship between those two entities. If a 122 pre-established relationship, like both the CN and MN being part of 123 the same Key Infrastructure (public or private) stronger security can 124 be applied for authenticating the Binding Update. There are also 125 proposals that associate a public/private key pair with the actual 126 IPv6 address which have different properties. However, such stronger 127 methods are outside of scope of the document. The purpose is to 128 explore parts of the solution space for weaker mechanisms. 130 1.1. Assumptions 132 The basis for the authentication and authorization is the assumption 133 that unicast IP routing is reasonably secure and that as long as 134 binding updates does not create significant additional security 135 issues than already present in today's routing system, the solution 136 at least does not do any (additional) harm. 138 In particular, this assumption about the IP routing working manifests 139 itself in the assumption that if a given Correspondent Node CN sends 140 a packet to the Home Address (HoA) of a Mobile Node MN, that the 141 routing system will deliver those packets to the Home Link of the 142 mobile node where the Home Agent (HA) will receive it. 144 At some level the authentication and authorization is intertwined in 145 this case. Authentication is often viewed as providing both sender 146 identity authentication as well as message integrity. If the 147 identity aspect of this in fact is capable of stating that the entity 148 sending a binding update is the mobile node i.e. the entity which has 149 been assigned the home address, then the authorization issue becomes 150 trivial - it is obvious that the MN is authorized to redirect its own 151 traffic. But this is largely a terminology issue. 153 The proposal also assumes that the communication between a MN and its 154 HA is secured using some form of pre-established security 155 association. For instance, such a security association might be 156 create at "subscription" time i.e., when the MN is assigned its HA. 157 It is assumed that this security association is used to secure the 158 Binding Update and Binding Acknowledgement messages between the MN 159 and its HA, and also that the association can be used to secure other 160 traffic between those two nodes. 162 This assumption includes traffic in both directions; from the HA to 163 the MN as well as the reverse direction. Thus either the pre- 164 established security association is bidirectional or there exists two 165 separate unidirectional pre-established security associations between 166 the HA and MN. 168 The techniques discussed can operate with the traffic between the HA 169 and MN providing at least integrity, but the security is improved 170 significantly when this channel provides confidentiality. 172 There is no assumption that the security mechanisms on that channel 173 provide replay protection since the binding update exchanges provide 174 their own protection against replays. 176 2. TERMINOLOGY 178 2.1. General 180 IP - Internet Protocol Version 6. 182 ICMP - Internet Message Control Protocol for the Internet 183 Protocol Version 6. 185 node - a device that implements IP. 187 router - a node that forwards IP packets not explicitly 188 addressed to itself. 190 host - any node that is not a router. 192 mobile node (MN) 193 a node which has a pre-established security 194 association with one or more home agents on its home 195 link and is capable of detecting when it moves 196 between different points of attachment in the 197 network, acquire a temporary care of address in each 198 visited location, and signal its current care of 199 address to the home agent using the security 200 association. 202 correspondent node (CN) 203 a node with which a mobile node communicates. The 204 correspondent node may itself be a mobile node. 206 home address (HoA) 207 the address of the mobile node which does not change 208 as the mobile node moves 210 home link - the link towards which regular IP routing forwards 211 packets destined to the home address 213 home agent - a router on the home link which tracks the mobile 214 nodes current location and relays packets to (and in 215 some cases) from the mobile node. 217 care of address (CoA) 218 an IP address assigned to the mobile node is its 219 current location 221 packet - an IP header plus payload. 223 2.2. Requirements 225 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 226 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 227 document, are to be interpreted as described in [KEYWORDS]. 229 This document also makes use of internal conceptual variables to 230 describe protocol behavior and external variables that an 231 implementation must allow system administrators to change. The 232 specific variable names, how their values change, and how their 233 settings influence protocol behavior are provided to demonstrate 234 protocol behavior. An implementation is not required to have them in 235 the exact form described here, so long as its external behavior is 236 consistent with that described in this document. 238 3. PROTOCOL OVERVIEW 240 3.1. Goals and Requirements 242 Note that this protocol, as well as other protocols that do not rely 243 on some pre-existing security relationship (including security 244 properties tied to the IPv6 addresses), are inherently subject to 245 Man-in-the-Middle attacks for attackers that are in the path of the 246 messages that are exchanged. 248 The goals and requirements for this protocol are: 250 o Minimize the complexity of the protocol even if it is at the 251 expense of more messages being exchanged. 253 o Minimize the use of cryptographic algorithms. 255 o Ensure that a correspondent node does not retain state due to 256 receiving the first message in a binding update exchange, in order 257 to reduce the exposure to denial of service attacks. 259 o Prevent replays of binding updates after the MN has moved away to 260 a different link. 262 o Make replays of binding updates before the MN has moved away to a 263 different link as idempotent with the original binding update. 265 o Make it cryptographically hard for attackers that are not on any 266 of the paths between CN-HA or CN-MN to inject spoofed binding 267 updates. 269 o Use the pre-established security association between the MN and HA 270 to thwart Man-in-the-middle attacks for attackers on the path 271 between the MN and HA. 273 o When the correspondent is also a mobile node, use the secured path 274 between it and its home agent to reduce the threats from attackers 275 that are on the same link as the correspondent. 277 o Make it hard for attackers there are not on any of the paths to 278 inject spoofed Binding Acknowledgement messages. 280 The protocol uses the messages in [MIPv6] with some extensions and, 281 in addition, two new messages: 283 Binding Update Request (BUR): First message in 3-way handshake. 284 Sent from the MN to the CN. 286 Binding Update Challenge (BUC): Second message in 3-way 287 handshake. Sent by the CN when receiving a BUR. This 288 message includes information that the CN can use to 289 verify that the third message in the 3-way handshake 290 without requiring that the CN create state when 291 sending the BUC. 293 Binding Update (BU): Third message in the 3-way handshake. Echos 294 the information from the BUC. When the MN requests an 295 acknowledgement of the BU it includes a random number 296 that will be echoed in the Binding Acknowledgement 297 message. 299 Binding Acknowledgement (BA): Used as specified in [MIPv6] but 300 with the added ability to return the random number 301 included in a Binding Update message as a means to 302 weakly authenticate the BA. 304 Binding Request (BR): Used as specified in [MIPv6]. 306 3.2. Message flow 308 When a MN determines that it wants a given CN to use route 309 optimization when sending packets to the MN, the MN initiates the 310 binding update 3-way handshake by sending a Binding Update Request 311 message to the CN. This message just includes the Care of Address 312 and Home Address of the MN. 314 The CN responds to this by sending a Binding Update Challenge message 315 to the Home Address of the MN, which serves to verify that IP routing 316 plus the home agent indeed forward packets to the node that sent the 317 BUR. The CN can get some assurance of this, without needing to 318 retain state for each BUR it receives, by including a cookie in the 319 BUC and verifying that the BU includes the same cookie. The purpose 320 of this check is to prevent nodes that are not on the path between 321 the CN, HA, MN, and CN to inject spoofed binding updates. The cookie 322 will be different for different MNs and even the same MN using 323 different Care of Addresses over time. 325 This document specifies how such a cookie can be created by the CN by 326 using a local timestamp mechanism (i.e., the time does not need to be 327 synchronized with other nodes; only the CN will inspect the timestamp 328 in the cookie) and a secret (random) number maintained by the CN 329 which the CN does not share with any other node. This allows the CN 330 to compute a keyed hash using its secret and the home address, care 331 of address, and timestamp. The recommended cookie consists of the 332 local timestamp followed by the result of the keyed hash. 334 The timestamp in the cookie allows the CN to immediately reject 335 replayed binding updates that are very old, as in older than e.g. 30 336 seconds (a maximum of the round-trip time of any Internet path). 337 This aids in rejecting old binding updates that are replayed after 338 the CN has lost its binding cache information, e.g. due to crashing 339 and rebooting or due to garbage collecting unused binding cache 340 entries. The protocol allows the CN to use different such lifetimes 341 for the cookies so that e.g. a CN that suspects a DoS attack to fill 342 up its Binding Cache can use shorter cookie lifetimes than 30 343 seconds. 345 The timestamp also allows the CN to use different secrets over time. 346 When the CN switches from using one secret to another it just needs 347 to remember what the timestamp value was at the time the switch was 348 made. With this information the CN can use the correct secret when 349 verifying the cookie in a received BU, even when the BU was sent when 350 the old secret was being used. 352 Each sent Binding Update Challenge message will use a new timestamp 353 value thus, as long as the CN maintains a binding cache entry for the 354 MN, the timestamp will prevent replays of old BUs. 356 The proposal also addresses the possibility of spoofed Binding 357 Acknowledgement messages. This case is simpler than the Binding 358 Update case since the MN creates some state when sending the BUR thus 359 this state can be augmented with a random cookie value without the 360 type of Denial-of-service concerns that are present in a CN handling 361 a BUR. This cookie is then sent in the Binding Update message and 362 the MN verifies that the Binding Acknowledgement message contains the 363 same cookie value. This prevents off-path attackers from spoofing a 364 Binding Acknowledgement message. 366 MN <===================================== 367 \ || 368 \ || 369 \ (1) BUR (HoA,CoA) || 370 \ (4) BU (N1, timestamp) || (3) BUC 371 v || 372 CN ------------------------------> HA 373 (2) BUC (N1=hash(secret, HoA, CoA, CN, timestamp, 374 cookie lifetime), timestamp) 376 The proposal specifies that the BUR, BUC, BU and BA messages should 377 be sent bypassing any binding cache entry on the sender in order to 378 prevent old, and potentially stale, binding cache information from 379 interfering. 381 Also, in order to avoid issues with ingress filtering and use the 382 MN-HA pre-established security association to reduce threats "close 383 to" mobile nodes, the BUC, BU, and BA messages, when the sender is a 384 mobile node, are reverse-tunneled through the sender's home agent. 385 This ensures that when two mobile nodes are communicating, i.e., the 386 correspondent is also a mobile node, the pre-established security 387 association between the mobile CN and its home agent is used to 388 prevent attackers close to the CN from injecting spoofed binding 389 updates or binding acknowledgements. 391 4. MESSAGE FORMATS 393 4.1. Binding Update Request Message Format 395 A Mobile node sends a Binding Update Request to a Correspondent Node 396 in order to start the 3-way binding update process. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Code | Checksum | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 + + 407 | | 408 + Home Address + 409 | | 410 + + 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 IP Fields: 416 Source Address 417 The Care of Address assigned to the MN. 419 Destination Address 420 The CN's IP address. 422 ICMP Fields: 424 Type TBD 426 Code 0 428 Checksum The ICMP checksum. See [ICMPv6]. 430 Reserved This field is unused. It MUST be initialized to 431 zero by the sender and MUST be ignored by the 432 receiver. 434 Home Address The MN's Home Address. 436 4.2. Binding Update Challenge Message Format 438 A Binding Update Challenge message is sent by a node in response to a 439 Binding Update Request. The BUC is sent to the Home Address in the 440 BUR in order to verify that the MN is indeed reachable by using that 441 home address. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Code | Checksum | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Cookie Life | Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 450 | | 451 + + 452 | | 453 + Care of Address + 454 | | 455 + + 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Cookie ... 459 +-+-+-+-+-+-+-+-+-+-+-+- 461 IP Fields: 463 Source Address 464 The destination address in the triggering BUR. If 465 the sender of the BUC is a mobile node itself then 466 this source address is likely to be its home 467 address. In this case the BUC MUST be reverse 468 tunneled through the sender's home agent to avoid 469 issues with ingress filtering. 471 Destination Address 472 The Home Address in the triggering BUR. 474 ICMP Fields: 476 Type TBD 478 Code 0 480 Checksum The ICMP checksum. See [ICMPv6]. 482 Cookie Life 8-bit field with an unsigned integer. The cookie 483 lifetime in units of seconds. 485 Reserved This field is unused. It MUST be initialized to 486 zero by the sender and MUST be ignored by the 487 receiver. 489 Care of Address 490 The Source IP address of the triggering BUR. 492 Cookie The information included by the CN in the BUC which 493 it expects to see returned in the Binding Update. 494 The length of the Cookie field is indicated by the 495 length of the ICMP packet. 497 4.3. Binding Update Message Format 499 Once an MN has received a BUC in response to its BUR it will send a 500 Binding Update to the CN. 502 NOTE: The description of the BU in this document is intentionally 503 incomplete. It only includes the information deemed necessary to 504 understand and discuss the security properties of the ideas presented 505 in this document. See [MIPv6] for the other information needed in a 506 Binding Update. The use of the Acknowledgement Cookie removes the 507 need for the Sequence number field specified in [MIPv6]. 509 NOTE: For no reason, other than ease of cutting and pasting between 510 sections in this document, the binding update is described as an ICMP 511 packet. The ideas proposed in this document can be applied 512 independently of how the BU information is carried; destination 513 option, UDP packet, or whatever. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type | Code | Checksum | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |A|H|R|D| Reserved | Cookie Life |Prefix Length| 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Reserved | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 524 | Lifetime | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | | 527 + Acknowledgement Cookie + 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 + + 532 | | 533 + Care of Address + 534 | | 535 + + 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Cookie ... 539 +-+-+-+-+-+-+-+-+-+-+-+- 541 IP Fields: 543 Source Address 544 The MN's Home Address copied from the Destination 545 Address field in the triggering BUC message. This 546 copying ensures that it is the same as the Home 547 Address field in the BUR. The BU MUST be reverse 548 tunneled through the sender's home agent to avoid 549 issues with ingress filtering. 551 Destination Address 552 The CN's address. MUST be the same as the 553 destination address in the BUR. 555 ICMP Fields: 557 Type TBD 559 Code 0 561 Checksum The ICMP checksum. See [ICMPv6]. 563 A-bit Binding Acknowledgement as specified in [MIPv6]. 564 Other bit flags, the Prefix Length, and Lifetime as 565 specified in [MIPv6]. Note that there is no 566 sequence number field necessary in this proposal. 568 Reserved This field is unused. It MUST be initialized to 569 zero by the sender and MUST be ignored by the 570 receiver. 572 Cookie Life 8-bit field with an unsigned integer. The cookie 573 lifetime in units of seconds. Copied from the BUC 574 message. 576 Acknowledgment Cookie 577 Only used when the A-bit is set. A 64-bit random 578 number set by the MN used to match the Binding 579 Acknowledgement with the Binding Update. 581 Care of Address 582 The same as the Care of Address field in the 583 received BUC, that is, the same as the Source 584 Address field in the BUR. 586 Cookie Copied from the Cookie field in the BUC. The 587 length of the Cookie field is indicated by the 588 length of the ICMP packet. 590 4.4. Binding Acknowledgement Message Format 592 A node sends a Binding Acknowledgement in response to a Binding 593 Request when the A-bit is set in the request. 595 NOTE: The description of the BA in this document is intentionally 596 incomplete. It only includes the information deemed necessary to 597 understand and discuss the security properties of the ideas presented 598 in this document. See [MIPv6] for the other information needed in a 599 Binding Acknowledgement. The use of the Acknowledgement Cookie 600 removes the need for the Sequence number field specified in [MIPv6]. 602 NOTE: For no reason, other than ease of cutting and pasting between 603 sections in this document, the binding ack is described as an ICMP 604 packet. The ideas proposed in this document can be applied 605 independently of how the BA information is carried; destination 606 option, UDP packet, or whatever. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type | Code | Checksum | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Status | Reserved | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Lifetime | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Refresh | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | | 620 + Acknowledgement Cookie + 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 + + 625 | | 626 + Care of Address + 627 | | 628 + + 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 IP Fields: 634 Source Address 635 The Destination Address in the triggering Binding 636 Update message. If the sender of the BA is a 637 mobile node itself then this source address is 638 likely to be its home address. In this case the BA 639 MUST be reverse tunneled through the sender's home 640 agent to avoid issues with ingress filtering. 642 Destination Address 643 The Source Address in the triggering BU message. 644 This is the Home Address of the MN sending the BU. 646 ICMP Fields: 648 Type TBD 650 Code 0 652 Checksum The ICMP checksum. See [ICMPv6]. 654 Status See [MIPv6]. 656 Reserved Unused field. It MUST be initialized to zero by 657 the sender and MUST be ignored by the receiver. 659 Lifetime See [MIPv6]. 661 Refresh See [MIPv6]. 663 Acknowledgement Cookie 664 64-bit field. Copied from the Acknowledgement 665 Cookie field in the triggering Binding Update 666 Message. 668 Care of Address 669 The Care of Address of the mobile node. Copied 670 from the Care of Address field in the triggering BU 671 message. 673 TBD: Does this field serve any purpose? It is 674 currently verified when the BA is received, but it 675 should be possible to omit it since the 676 Acknowledgement Cookie ensures that the BA is in 677 response to the last transmitted BU etc. 679 5. CONCEPTUAL MODEL OF A NODE 681 This section describes a conceptual model of one possible data 682 structure organization that nodes need to maintain in order to 683 implement [MIPv6] with the extensions and modifications specified in 684 this document. The described organization is provided to facilitate 685 the explanation of how the protocol should behave. This document 686 does not mandate that implementations adhere to this model as long as 687 their external behavior is consistent with that described in this 688 document. 690 5.1. Conceptual Data Structures 692 This section specifies the conceptual data structures with focus on 693 the parts that are different than in [MIPv6]. 695 Each IPv6 node will need to maintain the following pieces of 696 information: 698 Binding Cache 699 - A cache capturing information for mobile nodes from which the 700 node has received and accepted a Binding Update message. 702 The cache is indexed by the Home Address of the MN. Each 703 entry contains: 705 o Home Address. See [MIPv6]. 707 o Care of Address. See [MIPv6]. 709 o The state of the binding. This can be either "valid" or 710 "invalid". Binding Cache entries only effect packet 711 transmission when they are in the "valid" state. In order 712 to prevent certain replay attacks, e.g., after a binding 713 has been removed by a BU with a zero lifetime, binding 714 cache entries might need to be retained to suppress 715 duplicates for up to CookieLifetime seconds. Such entries 716 are in "invalid" state. 718 o Lifetime of the binding. Once this lifetime expires the 719 binding cache entry must be either deleted or marked 720 invalid. Unlike [MIPv6] the lifetime is a function of 721 both the lifetime field in the BU packets and the delay 722 between generating the BUC cookie and receiving the BU. 724 o Last update time. This field contains the local timestamp 725 value from the cookie indicating when the binding cache 726 entry was created or last updated by a BU message. 728 o Cookie Lifetime. Set from the BU that last created or 729 updated the binding. 731 o The Acknowledgement Cookie value and an indication whether 732 this field is valid i.e. set from a Binding Update 733 message. This might be useful if the protocol is extended 734 to use the Acknowledgement Cookie to filter out spoofed 735 Binding Request messages. Note that this specification 736 currently does not apply such filtering; in fact it is 737 silent on the use of BR messages. 739 In addition, on a Home Agent the binding cache entries 740 contain additional information which is specified in [MIPv6]. 742 AdvCookieLifetime. 743 - The CookieLifetime the CN uses to send in BUC messages. MUST 744 not exceed MAX_COOKIE_LIFETIME. 746 List of secrets 747 - A list with all the secrets that the CN has used to generate 748 BUC cookies in the last AdvCookieLifetime seconds. This list 749 contains either one or two entries, unless the CN creates a 750 new secret more often than every AdvCookieLifetime seconds. 752 Each entry in the list has the secret as well as the 753 timestamp value the last time the secret was used to create a 754 cookie. 756 Each Mobile Node, in addition to the above per-node conceptual data 757 structures, need to maintain 759 Binding Update List 760 - A list with all nodes to which the MN has sent a BUR or BU 761 and the binding has not yet expired. 763 The binding update list is indexed by address of the CN to 764 which the BUR or BU was sent and the Home Address i.e., there 765 can only be one entry per each pair. 767 Each entry contains: 769 o The IP address to which the BUR or BU was sent. See 770 [MIPv6]. 772 o The Home Address for which the binding was made. See 773 [MIPv6]. 775 o The Care of Address in the last binding update sent. See 776 [MIPv6]. 778 o The state of the binding. The possible states are 779 BUC_WAIT (sent BUR; waiting for a BUC), BA_WAIT (send BU; 780 waiting for BA), NO_BA (sent BU not requesting a BA), and 781 BA_OK (not waiting for anything). 783 o Remaining Cookie Lifetime. Set to the CookieLifetime when 784 the BUC is received and decremented as time passes. This 785 is needed to avoid retransmitting BUs using a cookie that 786 is older than the CookieLifetime in the BUC since the CN 787 will ignore such cookies. 789 o When in the BA_WAIT or NO_BA state: the cookie received in 790 the BUC to be used when retransmitting the BU. 792 o The Acknowledgement Cookie value used. 794 o The initial value of the lifetime field sent in the BU. 795 See [MIPv6]. 797 o The remaining lifetime of the binding. See [MIPv6]. 799 o The time a BUR or BU was last sent (transmitted or 800 retransmitted) needed in order to rate limit the sending 801 and implement retransmissions. 803 o The state of the binary exponential back-off mechanism for 804 BUR and BU messages. This is a factor which is multipled 805 with the retransmit timer value and doubled for each 806 unsuccessful retransmission. 808 o A flag that, when set, indicates that future BUR and BU 809 messages should not be sent to the destination. See 810 [MIPv6]. 812 5.2. Forming Cookies 814 The recommended way to form cookies is to use a secret (the current 815 secret in the list of secrets), a keyed hash, and a timestamp. 817 The timestamp should have a finer granularity than the minimal 818 spacing between subsequent binding updates in order to prevent two 819 binding updates from the same MN using the same timestamp. Should 820 the same timestamp be used then the "new" BU will be considered to be 821 a replay of an "old" BU and be ignored i.e., the MN would fail to 822 update the binding cache. 824 Therefor it is recommended that the timestamp have a granularity of 825 one millisecond or better. 827 The number of bits in the timestamp should be such that an attacker 828 can not just wait for the timestamp to wrap around and then replay an 829 old BU with what now looks like a new timestamp. This threat can be 830 avoided by requiring that a new secret is used before the time stamp 831 wraps around. For example, if a 32-bit timestamp with granularity 832 one millisecond is used than a new secret must be generated at least 833 every 4 million seconds i.e. about 1000 hours. 835 Note that when a new secret is generated the node should continue to 836 use the monotonically increasing timestamps to be able to tell 837 whether the old or new secret was used for handshakes that were in 838 progress during the change of secret. 840 When the node looses all state e.g., when it reboots, the node can 841 choose to either use the same secret as before the reboot provided 842 that it ensures that the timestamps are monotonically increasing 843 across the reboot and ensures that no BU message are accepted until 844 at least AdvCookieLifetime seconds after the loss of state. (The 845 latter is easy to ensure if it takes at least AdvCookieLifetime 846 seconds to reboot.) If the node can not make this guarantees then it 847 should select a new secret each time it reboots. 849 The secret MUST be a good random number as specified in [RANDOM]. 851 The recommended algorithm to use for the keyed hash is for further 852 study. MD5 or SHA-1 are likely choices. 854 The keyed hash should operate on the concatenation of the timestamp, 855 the HoA, the CoA, and CN's address, and the AdvCookieLifetime that 856 will be sent in the Binding Update Challenge Message. 858 Then the cookie can be formed by concatenating the timestamp and the 859 hash value. With a 32-bit timestamp it becomes 4 octets of timestamp 860 followed by TBD bytes of hash. 862 TBD: Specify the length of the cookie based on the algorithm chosen. 864 5.3. Garbage Collection and Timeout Requirements 866 Unlike in [MIPv6] a CN can not arbitrarily choose to garbage collect 867 binding cache entries, since that would open up potential replay 868 attacks. 870 Independently of how a binding cache entry is deleted i.e. whether 871 its lifetime expires, the CN desires to garbage collect it, or the CN 872 receives a BU with a zero lifetime, the CN must retain the binding 873 cache entry in the "invalid" state for at least AdvCookieLifetime 874 seconds after the entry is deleted. 876 This ensures that even if an attacker sent a Binding Update Request 877 and received a cookie (valid for AdvCookieLifetime seconds) just 878 before the binding cache entry was deleted, the cookie contained in 879 the Binding Update Challenge can not be used to recreate an old 880 binding for the MN. 882 Even without the ability to do arbitrary garbage collection of 883 binding cache entries the CN can still control the size of this 884 cache. This can be done by rejecting either Binding Update Request 885 messages (by silently dropping them) or by rejecting Binding Update 886 messages when there is no more space in the cache. In addition, the 887 ability for the CN to use different CookieLifetime values can help. 888 But in order to conform the state loss behavior above the CN needs to 889 have a conservative (i.e., maximum) estimate of the CookieLifetime 890 value used before loosing the state. Thus a CN that varies the 891 AdvCookieLifetime over time must maintain the maximum cookie lifetime 892 value that it has used. This can be done by using the 893 MAX_COOKIE_LIFETIME constant. 895 As specified in [MIPv6] a mobile node can not choose to garbage 896 collect binding update list entries. They must be allowed to time 897 out based on the lifetime of the binding as specified in [MIPv6]. 899 6. BEHAVIORAL SPECIFICATION 901 This section describes the rules for sending and receiving the 902 messages used by this protocol. 904 6.1. Sending Binding Update Request Messages 906 When a MN wishes to provide a binding update for a CN it first checks 907 if there is a binding update list entry for the pair. If 908 such an entry exists and is in state BUC_WAIT or BA_WAIT then there 909 is already an on-going attempt to create such a binding thus the 910 retransmissions will take care of creating one if possible. 912 If the state is BA_OK then the previous BU was acknowledged with a BA 913 and a new binding update exchange is only necessary should the CoA 914 have changed since the last one. 916 If the state if NO_BA it might be the case that the unacknowledged BU 917 was lost. In this case, assuming that "last sent" indicates that the 918 last BU was sent more than the binary backed off timeout seconds ago, 919 then an additional BU can be sent per the retransmission rules in 920 section 6.9. Note that the BU retransmission rules might determine 921 that the cookie from the BUC is too old and revert to sending a new 922 BUR. 924 If no binding update list entry then one is created for . 925 The state of the existing or created binding cache entry is set so 926 that 928 - The CoA is the current CoA of the MN 930 - the state is BUC_WAIT 932 - the time last sent set to the current time 934 - the binary exponential back-off factor set to 1. 936 - The flag to not send BUR/BU set to false 938 Then a BUR message is formatted according to section 4.1 and 939 transmitted. 941 Note that since the source address of the BUR is always the Care of 942 Address, the BUR will never be reverse tunneled to the HA of the 943 sender. 945 6.2. Retransmission of Binding Update Request Messages 947 When the retransmission timer fires and the binding update list entry 948 is in state BUC_WAIT the MN 950 - Double the binary exponential factor. This is used to compute the 951 next timeout value. 953 - Records the current time in the "time last sent" 954 - Retransmits the BUR message. 956 6.3. Validation of Binding Update Request Messages 958 A node MUST silently discard any received Binding Update Request 959 messages that do not satisfy all of the following validity checks: 961 - ICMP Checksum is valid. 963 - ICMP Code is 0. 965 - ICMP length (derived from the IP length) is 24 or more octets. 967 - The IP source address is not a multicast address or the 968 unspecified address. 970 - The IP destination address is not a multicast address or the 971 unspecified address. 973 - The Home Address field is not a multicast address or the 974 unspecified address. 976 The contents of the Reserved field and any data after the first 24 977 octets MUST be ignored. Future, backward-compatible changes to the 978 protocol may specify the contents of the Reserved field or add fields 979 after the Home Address field; backward-incompatible changes may use 980 different Code values. 982 A binding update request that passes the validity checks is called a 983 "valid BUR". 985 6.4. Processing Valid Binding Update Request Messages 987 The processing consists of forming a cookie as specified in section 988 5.2 and sending a Binding Update Challenge message. 990 No state is created on the node doing this processing. 992 6.5. Sending Binding Update Challenge Messages 994 A BUC message is formatted as specified in section 4.2. The 995 CookieLifetime field is set to the value of AdvCookieLifetime. 997 If the sending node has a binding cache entry for the destination of 998 the BUC then the sending MUST bypass that and send the packet 999 directly to the destination address i.e. not add a routing header per 1000 the information in the binding cache. This ensures that the HA-MN 1001 pre-established security association can be used to provide 1002 confidentiality for the cookie between the HA and MN. 1004 If the sending node is a mobile node itself then it MUST reverse 1005 tunnel the BUC message through its home agent. This removes any 1006 concerns about ingress filtering and allows the cookie field to be 1007 confidential on the path from the sender to its home agent. 1009 The Binding Update Challenge messages are never retransmitted. 1010 Instead, if the BUC is lost, then MN will retransmit the BUR causing 1011 a new BUC to be sent. 1013 6.6. Validation of Binding Update Challenge Messages 1015 A node MUST silently discard any received Binding Update Challenge 1016 messages that do not satisfy all of the following validity checks: 1018 - ICMP Checksum is valid. 1020 - ICMP Code is 0. 1022 - ICMP length (derived from the IP length) is 24 or more octets. 1024 - The IP source address is not a multicast address or the 1025 unspecified address. 1027 - The IP destination address is not a multicast address or the 1028 unspecified address. 1030 - The Care of Address field is not a multicast address or the 1031 unspecified address. 1033 The contents of the Reserved field MUST be ignored. Future, 1034 backward-compatible changes to the protocol may specify the contents 1035 of the Reserved field; backward-incompatible changes may use 1036 different Code values. 1038 A binding update challenge that passes the validity checks is called 1039 a "valid BUC". 1041 6.7. Processing Valid Binding Update Challenge Messages 1043 The MN will first look up the in the binding update list. 1044 If no entry is found, if the entry is not in BUC_WAIT state, or if 1045 the CoA field does not match the Care of Address field in the BUC, 1046 then the BUC must be silently dropped. 1048 Then the MN updates the binding update list information with 1050 - Record the time the BUC was received 1052 - Record the Cookie. 1054 - Record the CookieLifetime in the Remaining Cookie Lifetime. This 1055 value will limit for how long the BU will be retransmitted using 1056 this cookie. 1058 - Cancel any timer for retransmitting the BUR for that entry. 1060 - Set the state of NO_BA. 1062 - Set the time last sent to the current time (since a BU will be 1063 sent) 1065 - Reset the exponential back-off factor to 1. 1067 - Set the lifetime field in the binding cache entry to the lifetime 1068 value that will be sent in the BU. 1070 In addition, if the MN will set the A-bit in the BU in order to 1071 request a Binding Acknowledgement it: 1073 - Computes a 64-bit random number and store that in the 1074 Acknowledgement Cookie field in the binding cache entry. 1076 - Sets the state to BA_WAIT. 1078 6.8. Sending Binding Update Messages 1080 If the sending node has a binding cache entry for the destination of 1081 the BU then the sending MUST bypass that and send the packet directly 1082 to the destination address i.e. not add a routing header per the 1083 information in the binding cache. This ensures that the HA-MN pre- 1084 established security association can be used to provide 1085 confidentiality for the cookie between the HA and MN. 1087 The source address of the BU is the Home Address. Thus the packet 1088 MUST be reverse tunneled through the home agent. This removes any 1089 concerns about ingress filtering and allows the cookie field and 1090 acknowledgement cookie field to be confidential on the path from the 1091 sender to its home agent. 1093 Then a BUR message is formatted according to section 4.3 and 1094 transmitted. 1096 6.9. Retransmission of Binding Update Messages 1098 When the state is BA_WAIT BUs will be retransmitted based on a 1099 timeout. When the state is NO_BA then BUs will be retransmitted, 1100 subject to the rate limiting imposed by the binary exponentially 1101 backed off timeout value, when the MN receives a packet from the CN 1102 which has been tunneled by the HA to the MN since this indicates that 1103 the CN did not receive and accept the BU message. 1105 When this happens and the Remaining Cookie Lifetime in binding update 1106 list entry is less than zero the then the cookie is too old to use in 1107 a retransmission. In this case the state should be changed to 1108 BUC_WAIT without changing the binary exponential back-off factor and 1109 immediately retransmit the BUR as specified in section 6.2. 1111 Otherwise the retransmission should be handled as follows: 1113 - Double the binary exponential factor. This is used to compute the 1114 next timeout value. 1116 - Records the current time in the "time last sent" 1118 - Retransmits the BU message. If the A-bit is set the 1119 Acknowledgement Cookie field is set from the binding cache entry 1120 i.e., retransmitted BU messages have the same Acknowledgement 1121 Cookie value. 1123 6.10. Validation of Binding Update Messages 1125 A node MUST silently discard any received Binding Update messages 1126 that do not satisfy all of the following validity checks: 1128 - ICMP Checksum is valid. 1130 - ICMP Code is 0. 1132 - ICMP length (derived from the IP length) is 40 or more octets. 1134 - The IP source address is not a multicast address or the 1135 unspecified address. 1137 - The IP destination address is not a multicast address or the 1138 unspecified address. 1140 - The Care of Address field is not a multicast address or the 1141 unspecified address. 1143 The contents of the Reserved field MUST be ignored. Future, 1144 backward-compatible changes to the protocol may specify the contents 1145 of the Reserved field; backward-incompatible changes may use 1146 different Code values. 1148 A binding update that passes the validity checks is called a "valid 1149 BU". 1151 6.11. Processing Valid Binding Update Messages 1153 The CN must first extract the timestamp and the hash from the cookie 1154 field in order to verify them. The suggestion in section 5.2 is that 1155 the timestamp is the first 4 octets of the cookie followed by the 1156 hash. 1158 If the timestamp is more than the CookieLifetime field in the BU or 1159 the CookieLifetime field is more than MAX_COOKIE_LIFETIME then the 1160 message MUST be silently discarded. If the timestamp is new i.e. 1161 greater than the current time then the message is a replay after the 1162 timestamp wrapped around and the message MUST be silently discarded. 1164 The node use the timestamp to determine which secret was used to 1165 generate the keyed hash based on the secret list. Then it can 1166 compute the keyed hash using the same algorithm that it used when 1167 sending the BUC; using that secret and the information in the packet 1168 (Care of address, Correspondent address, Home address, timestamp, and 1169 CookieLifetime) as specified in section 5.2. If the generated hash 1170 does not match the hash in the received cookie then the packet MUST 1171 be silently discarded. 1173 Next the node MUST verify against the binding cache to make sure that 1174 the BU is not the replay of an old binding update. If there is no 1175 binding cache entry for the home address then the BU can not be a 1176 duplicate per the rules in section 5.3. If there already exists a 1177 binding cache entry for the home address then compare the "last 1178 update time" timestamp in that entry with the timestamp contained in 1179 the cookie. If the timestamp is older than the one in the binding 1180 cache entry then the BU MUST be silently discarded. Note: BUs where 1181 the timestamp matches are processed in order to generate a Binding 1182 Acknowledgement in response to a retransmitted BU. 1184 At this point the node knows that the BU is indeed a valid and 1185 authentic one. Thus it creates or updates the entry in binding cache 1186 as specified in [MIPv6]. Note that the lifetime used is the above 1187 conservative estimate. In addition it records the timestamp part of 1188 the cookie field in the "last update" field in the binding cache 1189 entry. (Note that the timestamp in the cookie is recorded - not the 1190 current time when the BU is received by the CN.) 1192 If a BU with a lifetime of zero is received an no binding cache entry 1193 exists then no binding cache entry needs to be created. However, 1194 should a binding cache entry exist in this case than that entry can 1195 not be immediately deleted in all cases. The binding cache entry 1196 must remain in "invalid" state for at least CookieLifetime seconds 1197 after the last non-zero lifetime BU was received as specified in 1198 section 5.3 in order to prevent replays after MN moves home and de- 1199 registers. 1201 If the A-bit is set in the BU message the node records the 1202 Acknowledgement Cookie in the binding cache entry and sends a Binding 1203 Acknowledgement message. 1205 6.12. Sending Binding Acknowledgement Messages 1207 If the sending node has a binding cache entry for the destination of 1208 the BA then the sending MUST bypass that and send the packet directly 1209 to the destination address i.e. not add a routing header per the 1210 information in the binding cache. This ensures that the HA-MN pre- 1211 established security association can be used to provide 1212 confidentiality for the acknowledgement cookie between the HA and MN. 1214 If the sending node is a mobile node itself then it MUST reverse 1215 tunnel the BA message through its home agent. This removes any 1216 concerns about ingress filtering and allows the cookie field to be 1217 confidential on the path from the sender to its home agent. 1219 Form the Binding Ack as follows: 1221 - The Lifetime field is set to the minimum of the conservative 1222 lifetime above and whatever the CN wishes to support. 1224 - The Status and Refresh is set as in [MIPv6]. 1226 - The acknowledgement cookie and care of address is set from the 1227 binding cache fields. 1229 The binding acknowledgement is never retransmitted by the CN. Should 1230 the BA be lost then the MN will retransmit the BU and in some cases 1231 the MN will need to retransmit the BUR due to a too old cookie. 1233 6.13. Validation of Binding Acknowledgement Messages 1235 A node MUST silently discard any received Binding Acknowledgement 1236 messages that do not satisfy all of the following validity checks: 1238 - ICMP Checksum is valid. 1240 - ICMP Code is 0. 1242 - ICMP length (derived from the IP length) is 40 or more octets. 1244 - The IP source address is not a multicast address or the 1245 unspecified address. 1247 - The IP destination address is not a multicast address or the 1248 unspecified address. 1250 - The Care of Address field is not a multicast address or the 1251 unspecified address. 1253 The contents of the Reserved field and any data after the first 40 1254 octets MUST be ignored. Future, backward-compatible changes to the 1255 protocol may specify the contents of the Reserved field or add fields 1256 after the Care of Address field; backward-incompatible changes may 1257 use different Code values. 1259 A binding acknowledgement that passes the validity checks is called a 1260 "valid BA". 1262 6.14. Processing Valid Binding Acknowledgement Messages 1264 The MN will first look for a matching in the binding update 1265 list. If no entry exists, the CoA doesn't match, or the state in the 1266 entry is not BA_WAIT then the BA MUST be silently discarded. 1268 If the acknowledgement cookie field in the packet does not match the 1269 acknowledgement cookie in the binding update list then the packet 1270 MUST be silently discarded. 1272 Mark the binding update list entry with state BA_OK and stop any 1273 timers associated with retransmitting BUs. 1275 7. SECURITY PROPERTIES 1277 The following set of threats are believed to be handled by the 1278 proposal: 1280 - Off-paths attackers are prevented by the use of the Cookie in the 1281 BUC-BU exchange. 1283 - Off-path attackers can't inject spoofed binding acknowledgements 1284 due to the acknowledgement cookie in the BU-BA exchange. 1286 - Replay attacks of BUs after a new BU has been received by a CN are 1287 ignored due to the timestamp in the cookie being older. 1289 - Replay attacks of BUs while the MN is in the location indicated by 1290 the BU has no effect; the cookie can not be used with a different 1291 CoA, Home Address, CN address, or timestamp. 1293 - Replay attacks after a MN has moved home and unregistered with a 1294 CN (using a BU with lifetime zero) have no effect since the 1295 binding cache state is maintained (with no effect on routing) for 1296 AdvCookieLifetime. 1298 - While the MN remains at the same CoA there is no effect of 1299 replaying/repeating the same BU since it doesn't redirect packets 1300 away from the correct CoA. Replay attacks after a MN has become 1301 unreachable are of course possible for CookieLifetime seconds, but 1302 once the MN becomes reachable on a different link, it will 1303 initiate a new BUR/BUC/BU exchange based on the binding update 1304 list. The rules in section 6.11 ensure that this will happen. 1306 - Replay attacks due to the CN garbage collecting the binding cache 1307 entries or loosing state are avoided using the rules in section 1308 5.3. 1310 - Flooding of spoofed BUR messages to a CN causes the CN compute a 1311 keyed hash and to send a BUC message. It does not create any 1312 state based on this. The BUC message is sent to the Home Address 1313 field in the BUR, but the IP source address of the BUR is included 1314 in the BUC message. Thus this can not be used as a more severe 1315 type of reflector attack than e.g. an ICMP echo packet. [TBD: The 1316 reflector threat is a bit different than an ICMP echo due to the 1317 extra address in the packets. Perhaps the BUR should be sent with 1318 the HoA as the source i.e. reverse tunneled through the HA to 1319 reduce the reflector risk.] 1321 - Flooding of spoofed BUC and BA packets cause a minimal amount of 1322 work to determine that the corresponding BUR and BU where never 1323 sent. 1325 - Flooding of spoofed BU packets causes some work on the CN to 1326 compute the keyed hash and compare it with the cookie in the 1327 message in order to reject the message. 1329 7.1. Residual Threats 1331 A node capable of passively observing packets between the CN and HA 1332 as well as being able to send packets, can redirect packets for any 1333 MN using that HA. This requires neither being able to modify the 1334 packets being delivered towards the HA, nor being able to prevent 1335 those packets from being delivered. 1337 Note that the above threat is introduced by Binding Updates whether 1338 or not the node named MN is indeed a mobile node; there is no way a 1339 CN can tell that a node isn't mobile. The reception of a binding 1340 update is taken as proof that the sender is indeed mobile. 1342 This is done by the attacker sending a BUR and seeing the resulting 1343 BUC, taking the cookie from that packet to form a BU. The MN will 1344 also observe the BUC but it will silently ignore it since it has not 1345 sent a BUR (and having the MN do anything differently would make BUCs 1346 a potential DoS attack opportunity). 1348 If ingress filtering [INGRESS] is used then the CoA that the attacker 1349 can use is limited to what the attacker can put in the IP source 1350 address field, which is not very limiting. 1352 Note that this threat is potentially more severe than what it takes 1353 to redirect traffic without using of Binding Updates; an attacker on 1354 the path between two nodes can of course observe all the traffic but 1355 it requires some active capability on the link for it to be able to 1356 prevent this packets to be delivered. An example of such active 1357 capabilities would be use of the Neighbor Discovery protocol on a 1358 shared Ethernet to make packets destined to the next hop router 1359 instead arrive at the attacker. 1361 A particular flavor of this attack is an attacker or the same LAN as 1362 the CN or HA. 1364 Note that the threat applies to any node; the CN has no means of 1365 determining whether a node is mobile or not but instead infers this 1366 from the reception of a BU with a matching cookie. 1368 A node capable of passively observing packets between the HA and MN 1369 can launch the same type of attack under the same constraints. This 1370 includes nodes on the same LAN as the MN. However, if the pre- 1371 established security association between the HA and MN provides in 1372 confidentiality, then such attacks are prevented. 1374 It is also possible for an attacker to inject spoofed data traffic 1375 (e.g., an ICMP echo) from a valid CN address to the MN with the 1376 intent to make the MN perform a binding update exchange which will 1377 create state in the CN's binding cache and in the MN's binding update 1378 list. This threat is external and independent of the actual 1379 mechanism to perform the binding update. The only known technique to 1380 address it is to have some threshold in the MN when it comes to 1381 performing a binding update which a CN which isn't already in the 1382 binding update list so that it requires multiple packets to and from 1383 the CN before the binding update is triggered. Note that CNs in the 1384 binding update list need to be notified of the new CoA when the MN 1385 moves thus they can not be subject to such a threshold. 1387 TBD: Does the ICMP parameter problem cause a threat? As specified 1388 [MIPv6] the reception of such indicating that the CN doesn't 1389 understand binding update options/messages is supposed to make the MN 1390 stop sending binding updates to the CN. They could be used to make a 1391 MN mark the binding update list entry as "don't bother sending BUR/BU 1392 to this node". It isn't clear what affect such marking will (or 1393 should) have on the behavior of the MN and whether this behavior can 1394 be exploited. Thus such ICMP messages appear to be usable by an 1395 attacker to prevent a CN from receiving binding updates. 1397 7.2. HA to MN Security Association 1399 A possible way to prevent attackers on the path between the HA and MN 1400 is to protect all packets that the HA tunnels to the MN using a pre- 1401 established security association that provides confidentiality. 1403 However, such a approach might be deemed costly for mobile devices 1404 with limited crypto performance. Thus there might be a desire to 1405 only apply the confidentiality to packets related to binding updates; 1406 in particular the BUC packets containing the cookie needed to 1407 generate a BU. 1409 This could be approached by making the HA apply different security 1410 associations depending on the content of the packets being 1411 encapsulated. The specification of selectors in [IPv6-SA], appear to 1412 say that the selectors (such as protocol type; port numbers) apply 1413 when packets are forwarded as well as originated. However, it isn't 1414 clear to what extent existing IPsec implementations have this 1415 capability to use different IPsec tunnels depending on the selectors 1416 in the forwarded packets. Also, it isn't clear what the performance 1417 impact would be in such a case since the Home Agent would need to 1418 inspect the selectors when forwarding packets to mobile nodes. 1420 Conceptually an alternative would be to make the BUC packets be 1421 addressed to the Home Agent (instead of the MN's Home Address) but 1422 this is non-trivial since 1424 o The CN has no way of finding out the address of the HA 1426 o In general the MN can't tell the CN the HA address, since that 1427 would allow a form of spoofing by an attacker claiming that the HA 1428 is some node other than the real HA. 1430 It might be possible, by hard-coding the knowledge of 64-bit 1431 prefixes, to either: 1433 o Have the CN determine the all-home agents anycast address for the 1434 MN based on the MN's home address. 1436 o Have the MN send a HA's address to the CN, and have the CN verify 1437 that the address falls in the same 64-bit prefix as the MN's home 1438 address. 1440 But hard-coding the 64-bit prefix boundary in nodes that are not 1441 attached to the particular link where the prefix is assigned would 1442 remove some flexibility in evolving the IPv6 addressing architecture 1443 over the lifetime of the IPv6 protocol. 1445 7.3. MN to MN Binding Updates 1447 As specified any attacker on the same LAN as the CN can redirect 1448 traffic destined from the CN to any node on the Internet as outlined 1449 in the previous section. 1451 Of course, such a threat might not be much severe than the ability to 1452 use Neighbor Discovery to spoof the IP address of the routers on the 1453 LAN, thereby being able to redirect or capture all packets sent by a 1454 CN. Given the increasing prevalence of wireless LANs and other 1455 public access LANs, it is important to understand the security 1456 properties for such cases. 1458 However, in the case that the CN is also a mobile node, i.e., it has 1459 a pre-established security association with its home agent, then this 1460 security association potentially provides better security than 1461 without mobile IPv6. This is done by the specification requiring 1462 that BUC, BU, and BA messages are reverse tunneled to the HA, which 1463 is also required to avoid any ingress filtering problems for the BUC 1464 and BA messages. 1466 This specification also requires that the BUC, BU and BA messages are 1467 sent bypassing any binding cache entry. This means that a 1468 correspondent that is mobile can in fact reject any BUC, BU and BA 1469 messages that are not received over the secure channel from its HA. 1471 ---------- 1472 | | 1473 | HA1 | 1474 | | ------------- LAN 1475 ---------- | | 1476 | | ---------- ---------- 1477 | | | | | | 1478 | | Secure tunnel | CN | | X | 1479 | | | | | | 1480 | | ---------- ---------- 1481 | | 1482 ---------- 1483 | | 1484 | MN1 | 1485 | | 1486 ---------- 1488 Figure 1: Attacker next to CN 1490 In Figure 1 the X can send a BUR to CN specifying that the home 1491 address MN1 and the care of address X (or any other care of address). 1492 Note that MN1 could be any node in the Internet; in particular it 1493 does not need to be a mobile node. 1495 X would be able to observe the BUC sent by the CN towards the 1496 specified home address, and could use this to send a BU to the CN. 1498 ---------- ---------- 1499 | | | | 1500 | HA1 | | HA2 | 1501 | | | | 1502 ---------- ---------- 1503 | | | | 1504 | | | | 1505 | | Secure tunnel | | Secure tunnel 1506 | | | | 1507 | | | ------------- LAN 1508 | | | | | | 1509 ---------- ---------- ---------- 1510 | | | | | | 1511 | MN1 | | MN2 | | X | 1512 | | | | | | 1513 ---------- ---------- ---------- 1515 Figure 2: Attacker next to CN which is a mobile node 1517 Given the rules in section 6, the same attack would not be effective 1518 in figure 2. While X can send the BUR to MN2, MN2 will reverse 1519 tunnel the BUC to HA2 and HA2 will forward the packet towards HA1. 1520 Thus assuming that the MN2-HA2 security association provides 1521 confidentiality then X is not able to generate a BU with a matching 1522 cookie. And MN1 will not respond to the BUC caused by the spoofed 1523 BUR since it did not send the BUR. 1525 8. ORTHOGONAL SECURITY ISSUES 1527 The following issues that have been identified on the Mobile IP WG 1528 mailing list are not addressed in this document: 1530 - Use of unauthenticated Home Address options for general reflector 1531 attacks. 1533 - Possible DoS attacks by flooding Binding Requests; potentially 1534 with spoofed IP source addresses. 1536 It is the author's belief that solutions to that problem are 1537 orthogonal to the proposed use of 3-way BUs. 1539 For instance, a possible solution to the unauthenticated Home Address 1540 option would be to 1542 - have the CNs reject packets with a Home Address option unless they 1543 have a matching binding cache entry, and 1545 - require that MNs by default tunnel all packets (where the IP 1546 address is its home address) through its home agent 1548 - When the MN knows that the CN will accept the Home Address option 1549 i.e., when it has received a binding ack from the CN, the it can 1550 optionally use the Home Address option thus avoid tunneling 1551 packets through the home agent. 1553 - A CN can not discard (garbage collect or loose) a binding cache 1554 entry until the lifetime of the binding expires, unless it can 1555 notify the MN that it can no longer use a home address option. 1557 Thus such a solution has no bearing on the proposal in this document. 1559 Also, handling of Binding Requests is also likely to be orthogonal. 1560 A MN could simply silently ignore any binding requests unless it has 1561 a binding update list entry for the CN and Home Address. 1563 Note in such an approach the acknowledgement cookie provided by this 1564 proposal might be helpful; one could require that the binding request 1565 contain the acknowledgement cookie from the last BU to prevent off- 1566 path attackers from injecting binding requests with a spoofed CN IP 1567 source address. 1569 The details of addressing these threats are outside of the scope of 1570 this document. 1572 9. WHAT IFS - ALTERNATE APPROACHES 1574 This section tries to provide some initial thoughts on how the 1575 security properties of the solution would change with a few 1576 modifications to the protocol described above. The purpose of this 1577 is to try to feed a discussion in order to gain a wider understanding 1578 of how the security properties are different in different parts of 1579 the design space. 1581 This section does not claim to be complete. In fact it only looks at 1582 two possible modifications: 1584 o During the first 3-way BU as specified in the protocol, 1585 additionally pass a clear-text key from the CN through the HA to 1586 the MN. The MN can then use that key to authenticate future BUs 1587 and not require a 3-way handshake. 1589 o As part of the first 3-way BU exchange perform a Diffie-Hellman 1590 exchange to establish a shared secret between the MN and CN. Use 1591 the shared secret to secure future BUs. 1593 The purpose of looking at the first modification is to understand the 1594 implications of trying to optimize the exchange for subsequent BUs. 1595 The purpose of looking at the second modification is to try to 1596 understand how to potentially limit the capabilities of attackers 1597 that are mostly passive. 1599 9.1. Establish a Key for Authenticating BUs 1601 For the purposes of making it simple to describe this modification it 1602 makes sense to introduce an additional message: Authenticated Binding 1603 Update (ABU) Such a message could of course be encoded as a variant 1604 of the BU message. 1606 Also, without loss of generality, assume that it is the Binding 1607 Acknowledgement that carries the authentication key from CN to MN. 1608 [It is also possible to carry this on the BUC but in order to avoid 1609 the CN creating state when receiving a BUR this requires making the 1610 authentication key be derived in similar ways to the Cookie sent in 1611 the BUC. This is probably possible but introduces complexities that 1612 are not believed to be germane to understanding the security 1613 properties in general.] 1615 We also assume that the CN send the BA to the Home Address (i.e., 1616 bypassing any binding cache entries). While this isn't strictly 1617 required it does allow using the assumed MN to HA security 1618 association to obtain higher security. 1620 The idea in this modification is that the exchange consists of a BUR, 1621 BUC, BU, and an additional BA. In the BU there is a bit indicating 1622 that the MN requests a authentication key. This causes the CN to 1623 generate such a key, store it in the binding cache entry, and send it 1624 in the clear to the MN with the binding ack. 1626 Presumably the binding ack would be extended to carry not only the 1627 key but also the lifetime of the key and the algorithm used to 1628 authenticate such as HMAC-SHA1. 1630 The MN would then, after verifying the binding ack using the 1631 acknowledgement cookie as before, store the authentication key in the 1632 binding update list. 1634 When the MN needs to update the binding in the CN, it would form a 1635 Authenticated Binding Update message and authenticate that using the 1636 key and algorithm. This then forms some authentication data which is 1637 included in the ABU. 1639 The CN then needs to verify the ABU packet. It would use the Home 1640 Address to lookup the binding cache entry for the MN. This would 1641 contain the authentication key which is then used to verify the 1642 authentication data included in the ABU. Presumably the ABU would 1643 contain a sequence number (starting at zero for the first ABU sent 1644 after receiving the authentication key) that might protect against 1645 certain replay attacks. 1647 The properties of such a scheme seem to be that, since anybody on the 1648 path between the CN and the HA can see the BA packet, attackers on 1649 path can redirect packets. To no surprise this isn't any better than 1650 the proposed 3-way protocol. 1652 But also, an attacker that was on the path between the HA and MN when 1653 the authentication key was established but due to later movements of 1654 the MN no longer is on that path, can use the authentication key to 1655 redirect the MN's traffic during the lifetime of the authentication 1656 key. The use of a sequence number in the ABU packet doesn't protect 1657 against this since the attacker can presumably pick large sequence 1658 numbers whereas the MN itself would use sequence numbers 0,1,2,3 etc 1659 as it moves. Thus such a sequence number would just protect against 1660 subsequent BU packets from the legitimate MN being reordered in the 1661 network. 1663 The above concern can presumably be addressed by requiring that the 1664 BA containing the authentication key be protected by an HA to MN 1665 security association that provides confidentiality. In such a case 1666 the cursory analysis on this approach seems to have the same security 1667 properties as the original 3-way proposal i.e. in that case they 1668 share the same residual threats with respect to nodes that are on the 1669 path between the CN and HA. 1671 9.2. Diffie-Hellman Exchange 1673 Assume that once the BUR/BUC/BU exchange has happened there is an 1674 ephemeral Diffie-Hellman exchange between the CN and MN. This 1675 exchange could presumably be done by the CN sending packets to the 1676 MN's home address and the MN reverse tunneling the packets through 1677 its home agent. Such an approach, combined with confidentiality for 1678 these packets over the HA-MN path, seems to add additional security 1679 beyond the original 3-way proposal. 1681 In particular, an attacker would need to be more active than an 1682 attacker in the 3-way scheme. For instance, an attacker on the same 1683 LAN as the CN would not only need to observe the packets passing by 1684 but would instead need to actively insert itself as a Man-in-the- 1685 Middle in the Diffie-Hellman exchange by intercepting packets in both 1686 directions, being able to inject modified packets, and perhaps being 1687 able to prevent that the original packets it intercepted are not 1688 delivered. [TBD: Is this difference significant?] 1690 If a DH exchange is done it can presumably start with the BU i.e., 1691 the BU and BA packets would perform the exchange. It would be 1692 undesirable to start the exchange before this point in time since the 1693 CN should avoid to create any state before the 3-way handshake has 1694 completed. 1696 10. PROTOCOL CONSTANTS 1698 Common constants: 1700 MAX_COOKIE_LIFETIME 30 seconds 1702 All protocol constants are subject to change in future revisions of 1703 the protocol. 1705 11. CONCLUSIONS 1707 The section tries to extract some lessons from designing and 1708 analyzing the bu3way proposal. 1710 For the purposes of this section we define these names for the 1711 variants of the proposal: 1713 o bu3way-int is the proposal with just integrity protection for the 1714 HA-MN paths 1716 o bu3way-conf is the proposal with confidentiality on the HA-MN 1717 paths 1719 o bu3way+key-int is the outline of the ideas in section 9.1 with 1720 just integrity for the HA-MN paths 1722 o bu3way+key-conf is that outline with confidentiality on the HA-MN 1723 paths 1725 The conclusions so far are: 1727 - bu3way-int: Anybody on the MN-HA path can spoof binding updates as 1728 long as they are on the path. They have to spoof for each BU sent 1729 by the MN. So when the MN moves they will loose this ability if 1730 they are no longer on the MN-HA path. 1732 - bu3way-conf: No such spoofing possible. 1734 - bu3way+key-int: Anybody on the HA-MN path when the key is 1735 established can spoof BUs for the lifetime of the key even after 1736 they are no longer on the HA-MN path due to the MN having moved. 1738 - bu3way+key-conf: No such spoofing possible. 1740 For potential attackers on the CN-HA path there is not much 1741 difference whether or an authentication key is distributed or not. 1742 With bu3way such an attacker can send a BUR with e.g. itself as the 1743 CoA and snoop the BUC packet between the CN and HA and use it to send 1744 a BU that will be accepted. But if ingress filtering [INGRESS] is 1745 used it can not pick an arbitrary CoA, since the CoA is the source 1746 address in the BUR. 1748 With bu3way+key such an attacker can just silently snoop the key from 1749 the BUC and at some later time during the lifetime of that key, send 1750 a BU using any CoA. 1752 In addition, using DH exchange instead of bu3way+key is different in 1753 that it requires attackers on the CN-HA path to actively insert 1754 themselves as a man-in-the-middle in the DH exchange, which may or 1755 may not be more difficult than just snooping at the packets as they 1756 pass by. 1758 There are also some performance tradeoffs between distributing an 1759 authentication key or not: 1761 o How many binding updates are performed between a pair of MN and CN 1762 vs. the cost of creating the authentication key. If there is only 1763 one binding update than bu3way+key is slower since it needs to 1764 generate a key. 1766 12. SECURITY CONSIDERATIONS 1768 Security issues are discussed in section 7. 1770 TBD Need to evaluate with respect to [SEC-REQ] 1772 13. ACKNOWLEDGEMENTS 1774 The security requirements, threats, and proposed solutions that have 1775 been discussed on the MobileIP WG mailing list have help form this 1776 the approach taken in this document. 1778 Phil Roberts, Jari Arkko, and Claude Castellucci provided comments 1779 that helped clarify the document. Phil suggested making the 1780 CookieLifetime a choice for the CN instead of it being a protocol 1781 constant. 1783 REFERENCES 1785 [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol 1786 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1787 Specification", draft-ietf-ipngwg-icmp-v3-01.txt. 1789 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 1790 (IPv6) Specification", RFC 2460, December 1998. 1792 [MIPv6] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft- 1793 ietf-mobileip-ipv6-14.txt. 1795 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1796 Protocol". RFC 2401, November 1998. 1798 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1799 November 1998. 1801 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 1802 RFC 2406, November 1998. 1804 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1805 Requirement Levels", RFC 2119, March 1997. 1807 [INGRESS] P. Ferguson, D. Senie, "Network Ingress Filtering: 1808 Defeating Denial of Service Attacks which employ IP Source 1809 Address Spoofing.", RFC 2827, May 2000. 1811 [SEC-REQ] A. Mankin et al, "Threat Models introduced by Mobile IPv6 1812 and Requirements for Security in Mobile IPv6", draft-ietf- 1813 mobileip-mipv6-scrty-reqts-02.txt. 1815 [RANDOM] D. Eastlake, S. Crocker, J. Schiller, "Randomness 1816 Recommendations for Security", RFC 1750, December 1994. 1818 AUTHORS' ADDRESSES 1820 Erik Nordmark 1821 Sun Microsystems Laboratories, Europe 1822 29 Chemin du Vieux Chene 1823 38240 Meylan, France 1825 phone: +33 (0)4 76 18 88 03 1826 fax: +33 (0)4 76 18 88 88 1827 email: Erik.Nordmark@sun.com