idnits 2.17.00 (12 Aug 2021) /tmp/idnits43696/draft-ng-nemo-rrnp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 925. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 915. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 9) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 7, 2004) is 6435 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) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: A later version (-04) exists of draft-thubert-nemo-ro-taxonomy-02 -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-ro-sec (ref. '7') == Outdated reference: A later version (-01) exists of draft-wakikawa-nemo-orc-00 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group C. Ng 2 Internet-Draft Panasonic Singapore Labs 3 Expires: April 7, 2005 J. Hirano 4 Panasonic 5 October 7, 2004 7 Extending Return Routability Procedure for Network Prefix (RRNP) 8 draft-ng-nemo-rrnp-00 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 7, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This memo highlights the inadequacy of existing return routability 44 procedure when one takes network prefix into consideration under the 45 context of route optimization with Network Mobility (NEMO). An 46 extended return routability procedure, called Return Routability with 47 Network Prefix (RRNP), is thus proposed to address this problem. 48 With RRNP, a correspondent node can verify the collocation of care-of 49 address, home address, and network prefix(es) specified in a binding 50 update message. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Inadequacy of Existing RR Procedure . . . . . . . . . . . . . 4 57 2.1 Possible Route Optimization Mechanism in NEMO . . . . . . 4 58 2.2 Security Threats with Unverified Network Prefixes . . . . 5 60 3. Overview of RRNP . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Modifications to Existing Protocols . . . . . . . . . . . . . 8 63 4.1 New Network Prefix Test Message . . . . . . . . . . . . . 8 64 4.2 New Number of Prefixes Option . . . . . . . . . . . . . . 9 65 4.3 Modifications to Home Test Init Message . . . . . . . . . 10 66 4.4 Modifications to Home Test Message . . . . . . . . . . . . 10 68 5. Detailed Description of RRNP . . . . . . . . . . . . . . . . . 11 69 5.1 Initiating the RRNP: Sending HoTI and CoTI . . . . . . . . 11 70 5.2 Responding to the CoTI with CoT . . . . . . . . . . . . . 12 71 5.3 Responding to the HoTI with HoT and NPT . . . . . . . . . 13 72 5.4 Intercepting the NPT messages . . . . . . . . . . . . . . 15 73 5.5 Sending the Binding Update . . . . . . . . . . . . . . . . 16 74 5.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . 18 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 82 A. Applicability of RRNP . . . . . . . . . . . . . . . . . . . . 23 84 Intellectual Property and Copyright Statements . . . . . . . . 24 86 1. Introduction 88 Currently, mobile node uses a procedure known as the Return 89 Routability (RR) procedure [1] to allow a correspondent node to be 90 assured of the collocation of the mobile node's home address and 91 care-of address. When one consider network mobility [2], it is 92 foreseeable that for route optimization to work [3], it might be 93 necessary for a mobile router to inform the correspondent node which 94 network prefixes the mobile network is using, so that the 95 correspondent node can forward packets destined to mobile network 96 nodes in the mobile network directly to the mobile router's care-of 97 address. 99 In such situation, the original return routability procedure is 100 inadequate since it does not provide a means for the correspondent 101 node to ascertain that the network prefixes specified by the mobile 102 router are in fact handled by the mobile router. In order to solve 103 this problem, this memo describes an improved procedure known as the 104 Return Routability with Network Prefix (RRNP) procedure where the 105 mobile router will first list the network prefixes it owns in the 106 Home Test Init (HoTI) message. The correspondent node tests the 107 collocation of these network prefixes by generating some 108 cryptographic tokens and sending each of these tokens to an address 109 randomly selected from each network prefix. The mobile router must 110 capture these packets, extract the cryptographic tokens, and use 111 these tokens to generate a hash value in the binding update message 112 it later sends to the correspondent node. In this way, the 113 correspondent node can verify that the mobile router indeed owns the 114 network prefixes it claims to own. 116 It is assumed that readers are familiar with the original return 117 routability procedure specified in [1], and the terminology related 118 to network mobility (NEMO) defined in [4]. 120 We begin by first describing the problem of the existing return 121 routability procedure when Mobile Network Prefix option is inserted 122 into Binding Update messages in Section 2. Section 3 then presents 123 an overview of the extended return routability procedure to solve 124 this problem. The new mobility message and option formats are then 125 introduced in Section 4 before we explain the improved procedure with 126 greater detail in Section 5. Finally, Section 6 discusses some 127 security considerations in the design of the RRNP. 129 2. Inadequacy of Existing RR Procedure 131 2.1 Possible Route Optimization Mechanism in NEMO 133 There is currently no accepted route optimization solution for 134 Network Mobility. However, it is foreseeable that a possible 135 approach to route optimization involves sending binding updates with 136 Network Prefix Options as defined in [2] to correspondent nodes. As 137 an illustration of how this will work, consider the deployment 138 scenario depicted in Figure 1 below. 140 +----------------+ +------+ 141 | | +---+ MNN1 | 142 +-----+ | | +-----+ | +------+ 143 | CN1 +-----+ INTERNET +----+ MR1 +--+ 144 +-----+ | | +-----+ | +------+ 145 | | +---+ MNN2 | 146 +-------+--------+ +------+ 147 | 148 +--+--+ 149 | HA1 | 150 +-----+ 152 Figure 1: Deployment Scenario 154 Here, the mobile network with mobile network prefix MNP consists of a 155 mobile router MR1 with two mobile network nodes, MNN1 and MNN2, 156 behind MR1. The home address of MR1 is MR1.HoA, and current care-of 157 address of MR1 is MR1.CoA. HA1 is the home agent of MR1 and CN1 is 158 the correspondent node communicating with, say MNN1. If route 159 optimization is not used, a packet sent from CN1 to MNN1 will follow 160 the path: 162 CN1 ---> HA1 ===> MR1 ---> MNN1 164 Now, suppose MR1 sends CN1 a Binding Update message with the Mobile 165 Network Prefix option, such that within CN1, it will insert a route 166 into its own routing table that all packets sent to the prefix MNP 167 will be tunneled to the address MR1.CoA, then route optimization will 168 have been achieved. The path of the packet will now be: 170 CN1 ===> MR1 ---> MNN1 172 2.2 Security Threats with Unverified Network Prefixes 174 Although the inclusion of Mobile Network Prefix option allows route 175 optimization to be setup between a mobile network and a correspondent 176 node, existing return routability procedure as defined in [1] does 177 not provide a means for correspondent node to verify that the Mobile 178 Network Prefix option specified in the binding update is valid and 179 legitimate. This exposes the correspondent node to additional 180 security threats. 182 One immediate threat is that the Mobile Network Prefix option may be 183 changed, or inserted, by an attacker. This cause the correspondent 184 node to send data packets meant for other network to the mobile 185 router. This can be used to launch a flooding attack on the mobile 186 router, overwhelming the mobile router with data packets not meant 187 for its network. However, this attack is inherently diverted by the 188 existing return routability procedure, since the integrity of the 189 Binding Update message is protected by the binding management key, 190 Kbm. So any change in the Mobile Network Prefix option will cause 191 the Binding Authorization Data option to carry a wrong Authenticator 192 value. This could be easily checked by the correspondent node. 194 Another threat is when a "mobile router" is itself malicious. It can 195 specify prefixes that it does not actually own in the Mobile Network 196 Prefix option. This way, the correspondent node is tricked into 197 forwarding packets (which it intends to send to some other network) 198 to the malicious "mobile router". Thus, this allows the "mobile 199 router" to spoofed into packets sent by the correspondent node to 200 some destination, which is otherwise not possible. This threat is 201 illustrated in Figure 2 below. 203 (1) Initially, CN1 sends 204 packets directly to 205 +-----+ victim's network. +------------+ 206 | CN1 | ---------------------> | victim's | 207 +-----+ | network | 208 (2) Attacker ^ || (3) CN1 now starts +------------+ 209 sends BU to CN1 | || to tunnel all data 210 with MNP option | || packets for 211 claiming to | || victim's network 212 handle victim's | || to attacker. 213 network prefix. | \/ 214 +----------+ 215 | Attacker | 216 +----------+ 218 Figure 2: Attacker claiming to handle victim's network prefix 220 Existing return routability procedure cannot prevent such attacks. 221 This is because return routability procedure can only verify that the 222 home address and care-of address are collocated. Thus an attacker 223 may very well own both the home address and care-of address specified 224 in the Binding Update, causing the return routability procedure to 225 pass successfully. The correspondent node has no way of checking if 226 the network prefix claimed to be owned by a sender of the Binding 227 Update message is indeed owned by the sender. 229 Thus, an improved return routability procedure has to be designed to 230 allow the correspondent node to check the validity of the Mobile 231 Network Prefix option, before route optimization between CN and MR 232 can be established without exposing the nodes involved to additional 233 security threats. 235 3. Overview of RRNP 237 The improved return routability procedure, known as the RRNP, is 238 meant to extend the existing return routability procedure to bindings 239 of network prefixes. In the RRNP, the mobile router will first list 240 the network prefixes it owns in the Home Test Init (HoTI) message. 241 When the correspondent node sees these prefixes, it sends, in 242 addition to the normal HoT message, a new message referred to as 243 Network Prefix Test (NPT) message for each network prefix included in 244 the HoTI message. The NPT message contains a token that is 245 cryptographically generated based on the network prefix, and is 246 addressed to an address that is randomly generated from the network 247 prefix. The mobile router must intercept all the NPT messages, and 248 store these tokens. In the Binding Update message the mobile router 249 send to the correspondent node, the Authenticator value of the 250 Binding Authorization Data option is generated using the tokens 251 contained in the Home Test (HoT), Care-of Test (CoT) and NPT messages 252 sent from the correspondent node. In this way, the correspondent 253 node can verify that the care-of address and home address of the 254 mobile router are collocated, and that the mobile router indeed owns 255 the network prefixes it claimed to own. 257 Figure 3 below illustrates the message sequence diagram of the RRNP. 259 Mobile Home Correspondent 260 Router Agent Node 261 --+-- --+-- ------+----- 262 | CoTI | 263 |------------------------------------------------------->| 264 | Encapsulated HoTI | | 265 |===========================>| HoTI | 266 | |-------------------------->| 267 | CoT (Care-of Keygen) | 268 |<-------------------------------------------------------| 269 | | HoT (Home Keygen) | 270 | Encapsulated HoT |<--------------------------| 271 |<===========================| | 272 | | NPT (Prefix Keygen) | 273 | Encapsulated NPT |<--------------------------| 274 |<===========================| | 275 | BU (Hash(Home Keygen,Care-of Keygen,Prefix Keygen)) | 276 |------------------------------------------------------->| 278 Figure 3: Message sequence diagram of a RRNP procedure 280 4. Modifications to Existing Protocols 282 4.1 New Network Prefix Test Message 284 The Network Prefix Test (NPT) message is sent by a correspondent node 285 to a random address selected from a prefix. This message is meant to 286 be intercepted by a mobile router owning the prefix. Figure 4 below 287 shows the format of Network Prefix Test message. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Home Nonce Index | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | 295 + Home Init Cookie + 296 | | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 + Network Prefix Keygen Token + 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 . . 304 . Mobility Options . 305 . . 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 4: Network Prefix Test Message 311 MH Type 313 To be assigned. Identifies the mobility message as a Network 314 Prefix Test message. 316 Home Nonce Index 318 The index of the nonce used to generate the Network Prefix Keygen 319 Token. Note that this should be the same as the once used to 320 generate the Home Keygen Token. 322 Home Init Cookie 324 This value is copied from the Home Test Init message. 326 Network Prefix Keygen Token 328 This is the keygen token generated based on the network prefix 329 specified in a Mobile Network Prefix option. 331 Mobility Options 333 The Network Prefix Test message should contain one (and only one) 334 Mobile Network Prefix option as defined in [2]. This value is 335 copied from the Home Test Init message. 337 4.2 New Number of Prefixes Option 339 The Number of Network Prefixes option is included in a Home Test 340 (HoT) message sent by a correspondent node to indicate to the mobile 341 router how many network prefixes is accepted. This option is 342 included to allow the mobile router to know how many Network Prefix 343 Test message it needs to intercept. In addition, it also serves to 344 indicate to the mobile router that the correspondent node understands 345 the Mobile Network Prefix options included in the Home Test Init 346 message. Figure 5 below shows the format of option. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Option Type | Option Length | 352 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Num Prefix | 354 +-+-+-+-+-+-+-+-+ 356 Figure 5: Number of Prefixes Option 358 Option Type 360 To be assigned. Identifies the mobility option as a Number of 361 Prefixes option. 363 Option Length 365 The length in octets of this option, excluding the first 2 octets. 366 Always equal to 1. 368 Num Prefix 370 The number of prefixes the correspondent node is willing to 371 accept. 373 4.3 Modifications to Home Test Init Message 375 There is no change to the format of the Home Test Init (HoTI) message 376 as per defined by Mobile IPv6 [1], except that the Home Test Init 377 message is now extended to be able to include the Mobile Network 378 Prefix option as defined by NEMO Basic Support [2]. 380 4.4 Modifications to Home Test Message 382 There is no change to the format of the Home Test (HoT) message as 383 per defined by Mobile IPv6 [1], except that the Home Test message is 384 now extended to be able to include the Number of Prefixes option as 385 defined in Section 4.2. 387 5. Detailed Description of RRNP 389 5.1 Initiating the RRNP: Sending HoTI and CoTI 391 Once the mobile router determines that it wishes to perform route 392 optimization with a correspondent node, it initiates the return 393 routability procedure by sending the Home Test Init and Care-of Test 394 messages to the correspondent node. 396 Sending of the Care-of Test Init message is exactly the same as the 397 original return routability procedure. The packet contents is shown 398 below: 400 IPv6 Header { 401 Source = care-of address of mobile router 402 Destination = correspondent node 403 } 404 Mobility Header { 405 MH Type = Care-of Test Init 406 Care-of Init Cookie = random value 407 } 409 Sending of the Home Test Init message is also largely similar to that 410 in the original return routability procedure, except that the mobile 411 router inserts one (or more, depending on the number of prefixes the 412 mobile router owns and wishes to perform route optimization with the 413 correspondent node) Mobile Network Prefix option in the Home Test 414 Init message. It may not be to the benefit of the mobile router to 415 inform the correspondent node of all the NEMO prefixes it owns since 416 this may result in a longer message and a longer time period of 417 intercepting NPT messages (see Section 5.4). 419 The packet contents of the HoTI message is shown below: 421 IPv6 Header { 422 Source = home address of mobile router 423 Destination = correspondent node 424 } 425 Mobility Header { 426 MH Type = Home Test Init 427 Home Init Cookie = random value 428 Mobile Network Prefix Option { 429 Prefix Length = length of prefix 430 Mobile Network Prefix = prefix of the mobile network 431 } 432 } 434 Since the Home Test Init message is sent using the home address as 435 the source, this packet is encapsulated into a tunnel back to the 436 home agent of the mobile router. 438 5.2 Responding to the CoTI with CoT 440 When the correspondent node receives the Care-of Test Init message, 441 and decides to accept route optimization with the mobile router, it 442 responds with a Care-of Test message. Preparation of the Care-of 443 Test message is exactly the same as that specified in Mobile IPv6 444 [1]. First, the correspondent node selects a nonce to generate a 445 keygen token. The nonce selected should be identifiable by a 16-bits 446 nonce index. The Care-of Keygen Token, CoK, is then generated by 448 CoK := First(64, 449 HMAC_SHA1(Kcn, (care-of address | nonce | 0x01))) (Eq 1) 451 where 453 First(L,m) is to truncate the message m leaving the leftmost L 454 bits, 456 HMAC_SHA1(K,m) is the hash result of taking the HMAC-SHA1 hash 457 function [5][6] on the message m using the cryptographic key K, 459 Kcn is a secret key of the correspondent node, and 461 '|' denotes concatenation of bit stream. 463 The Care-of Keygen Token and the nonce index are then included in a 464 Care-of Test message to be returned to the mobile router, including 465 the Care-of Init Cookie copied from the Care-of Test Init message. 466 The packet contents is shown below: 468 IPv6 Header { 469 Source = correspondent node 470 Destination = care-of-address of mobile router 471 } 472 Mobility Header { 473 MH Type = Care-of Test 474 Care-of Nonce Index 475 Care-of Init Cookie = copied from CoTI 476 Care-of Keygen Token = generated as per (Eq 1) 477 } 479 5.3 Responding to the HoTI with HoT and NPT 481 When the correspondent node receives the Home Test Init message, and 482 decides to accept route optimization with the mobile router, it 483 responds with a Home Test message. In addition, for every network 484 prefix specified in a Mobile Network Prefix option in the Home Test 485 message it is prepared to accept, the correspondent node will reply 486 with a Network Prefix Test message. Note that it is up to the 487 discretion of the correspondent node whether to respond to the 488 HoTI/CoTI message, and the number of network prefixes to accept (see 489 Section 6). 491 In preparation of the Home Test message, the correspondent node first 492 selects a nonce to generate the keygen token. The nonce selected 493 should be identifiable by a 16-bits nonce index. The Home Keygen 494 Token, HoK, is then generated by 496 HoK := First(64, 497 HMAC_SHA1(Kcn, (home address | nonce | 0x00))) (Eq 2) 499 The Home Keygen Token and the nonce index are then included in a Home 500 Test message to be returned to the mobile router, including the Home 501 Init Cookie copied from the Home Test Init message. In addition, a 502 Number of Network Prefix option is also included to indicate to the 503 mobile router how many network prefixes specified in the Home Test 504 Init message the correspondent node is prepared to accept. For every 505 network prefix the correspondent node is willing to accept, the 506 correspondent node will sent a separate Network Prefix Test message. 507 The packet contents is shown below: 509 IPv6 Header { 510 Source = correspondent node 511 Destination = home address of mobile router 512 } 513 Mobility Header { 514 MH Type = Home Test 515 Home Nonce Index 516 Home Init Cookie = copied from HoTI 517 Home Keygen Token = generated as per (Eq 2) 518 Number of Network Prefix Option { 519 Number of Prefix = maximum number of prefixes accepted 520 } 521 } 523 For the Network Prefix Test message, a Network Prefix Keygen Token is 524 also generated. The nonce selected is the same as the one used to 525 generate the Home Keygen Token. The Network Prefix Keygen Token, 526 NPK, is given by 528 NPK := First(64, 529 HMAC_SHA1(Kcn, (network prefix | nonce | 0x02))) (Eq 3) 531 The Network Prefix Keygen Token and the nonce index are then included 532 in a Network Prefix Test message to be returned to the mobile router, 533 including the Home Init Cookie copied from the Home Test Init 534 message. In addition, a Mobile Network Prefix option is also 535 included to indicate to the mobile router which mobile network prefix 536 this Network Prefix Test message is for. The packet contents is 537 shown below: 539 IPv6 Header { 540 Source = correspondent node 541 Destination = random address selected from network prefix 542 } 543 Mobility Header { 544 MH Type = Network Prefix Test 545 Home Nonce Index 546 Home Init Cookie = copied from HoTI 547 Network Prefix Keygen Token = generated as per (Eq 3) 548 Mobile Network Prefix Option { 549 Copied from the HoTI message 550 } 551 } 553 The Network Prefix Test message is sent to an address randomly 554 selected from the mobile network prefix that this Network Prefix Test 555 message is for. Because the correspondent node sent more than one 556 packet for each Home Test Init message with Mobile Network Prefix 557 option received, the correspondent should add a random delay before 558 sending each Network Prefix Test message sent to avoid amplification 559 effect. The delay, however, must be within a known limit. For the 560 purpose of this document, we specify the random delay selected must 561 be within the range of (0, MAX_NPT_DELAY). A suitable value of 562 MAX_NPT_DELAY can be 0.5 seconds. 564 In addition, the correspondent node should also take note of the 565 mobile router sending the HoTI message. Should multiple HoTI 566 messages are received from the same mobile router within a short time 567 span, the correspondent node should reject subsequent HoTI messages 568 as it is possible that the mobile router is trying to stage a 569 denial-of-service attack against the network prefix specified. 571 5.4 Intercepting the NPT messages 573 After sending the Home Test Init and Care-of Test Init messages, the 574 mobile router must start intercepting the Home Test, Care-of Test, 575 and Network Prefix Test messages. The Home Test and Care-of Test 576 messages should not pose any problem, as they are addressed to the 577 home address and care-of address of the mobile router respectively. 578 To intercept the Network Prefix Test messages, the mobile router must 579 inspect every packet addressed to the mobile network to see if they 580 are indeed a Network Prefix Test message. 582 It is recommended that the mobile router starts a timer after sending 583 the Home Test Init message. During this time period, the mobile 584 router will inspect every packet that satisfies all of the following 585 criteria to check if it is a Network Prefix Test message: 587 o the packet arrives in a tunnel from the home agent 589 o the packet bears the correspondent node's address as the source 590 address 592 o the packet bears a destination address that is formed from a 593 network prefix that is sent to the correspondent node in a Mobile 594 Network Prefix option in the Home Test Init message 596 The timer value should be chosen such that it is sufficiently long 597 for all Network Prefix Test message to be received by the mobile 598 router. A reasonable value is given by 600 timer = T_rtt + n * MAX_NPT_DELAY (Eq 4) 602 where 604 T_rtt is the round-trip time taken for a packet to be sent from 605 the mobile router to the correspondent node and back again, via 606 the home agent, and 608 n is a number of Mobile Network Prefix options included in the 609 HoTI message. 611 This a best estimate assuming there is no congestion in the network. 612 A more conservative value can be given by 614 timer = 2 * T_rtt + n * MAX_NPT_DELAY (Eq 5) 616 In addition, once the mobile router has received the Home Test 617 message, it will know from the Number of Prefixes option how many 618 network prefixes the correspondent node is willing to accept. The 619 mobile router can then adjust the timer value accordingly. 621 Once the mobile router has received the Home Test message, Care-of 622 Test message, and all the Network Prefix Test messages (as specified 623 by the Number of Prefixes option) or when the timer expires, it can 624 proceed to complete the return routability procedure by sending the 625 Binding Update message. This is described in the next sub-section 626 (Section 5.5). 628 There are several sanity checks the mobile router can perform when 629 receiving the Home Test, Care-of Test, and Network Prefix Test 630 messages. Firstly, the mobile router can verify that the Home Init 631 Cookie and Care-of Init Cookie are the same as those it has sent in 632 the Home Test Init and Care-of Test Init messages. Secondly, it can 633 check that the Network Prefix Test message specifies the same Home 634 Init Cookie. Thirdly, it can verify that the Network Prefix Test 635 message specifies the same Home Nonce Index as that specified in the 636 Home Test message. 638 5.5 Sending the Binding Update 640 To complete the return routability procedure, the mobile router will 641 have to send the Binding Update message to the correspondent node. 642 In the Binding Update message, the mobile router should include the 643 nonce indices in the Nonce Indices option. In addition, a Mobile 644 Network Prefix option should also be included for every network 645 prefix that the mobile router has received a Network Prefix Test 646 message. Furthermore, the mobile router should include a 647 cryptographic checksum in the Authenticator field of a Binding 648 Authorization Data option. To generate the checksum, the mobile 649 router must first obtain the binding management key, Kbm, given by 651 Kbm := SHA1 (HoK | CoK | NPK_1 | ... | NPK_n) (Eq 6) 653 where 655 SHA1(m) is the result of applying the Secure Hash Algorithm [5] on 656 the message m, 658 HoK is the Home Keygen Token from the HoT message, 660 CoK is the Care-of Keygen Token from the CoT message, and 662 NPK_i is the Network Prefix Keygen Token from the i-th NPT 663 message. 665 This gives the Kbm as a 20 octets (160 bits) long value. It is used 666 by both the mobile router and the correspondent node to generate the 667 Authenticator value. For the Binding Update message, the 668 Authenticator value is given by 670 Authenticator := First(96, 671 HMAC_SHA1(Kbm, (CoA | correspondent | BU)) (Eq 6) 673 where 675 CoA is the care-of address of the mobile router, 677 correspondent is the address of the correspondent node, and 679 BU is the entire Binding Update message except the Authenticator 680 field itself. 682 When generating the Authenticator value, the Checksum field of the 683 Mobility Header is first initialized as zero. Before sending the 684 Binding Update message, the Binding Authorization Data option is 685 appended as the last option, and the Checksum is finally calculated, 686 including the Authenticator field in the calculation. If there are 687 multiple Mobile Network Prefix options, the mobile router must be 688 careful to ensure that the order of the Mobile Network Prefix options 689 is the same as the order the corresponding Network Prefix Keygen 690 Token is concatenated in (Eq 6) to generate the Kbm. The packet 691 contents of the Binding Update message is shown below: 693 IPv6 Header { 694 Source = care-of address of mobile router 695 Destination = correspondent node 696 } 697 Mobility Header { 698 MH Type = Binding Update 699 Flags = H,K must be cleared, R should be set 700 Nonce Indices Option { 701 Home Nonce Index 702 Care-of Nonce Index 703 } 704 Mobile Network Prefix Option { 705 Prefix Length = length of prefix 706 Mobile Network Prefix = prefix of the mobile network 707 } 708 Binding Authorization Data Option { 709 Authenticator = calculated as per (Eq 7) 710 } 711 } 713 It must again be noted that the correspondent node need not maintain 714 any state information before the receipt of the Binding Update 715 message. Using information contained in the Binding Update message, 716 it is sufficient for the correspondent node to generate the Home 717 Keygen Token, Care-of Keygen Token, and Network Prefix Keygen 718 Token(s) to derive the binding management key independently and 719 verify the Authenticator value. 721 5.6 Error Handling 723 This section outlines some of the possible error conditions that 724 might occur during a RRNP procedure. 726 o Failure to receive HoT/CoT message 728 When a mobile router fails to receive a HoT or CoT message after 729 sending the HoTI and CoTI message, the mobile router must not 730 proceed with sending of binding update. If a pre-determined time 731 period, possibly determined by (Eq 5), has elapsed, the mobile 732 router may assume that some packets are lost, and re-initiate the 733 RRNP procedure. The mobile router may give up after consecutive 734 failed attempts. 736 o Failure to receive NPT message 738 If the mobile router failed to receive any NPT message, even 739 though the HoT message indicates that the correspondnet node has 740 accepted one or more Mobile Network Prefix options, the mobile 741 router may choose to proceed with sending normal Binding Update 742 message (without any Mobile Network Prefix options) or to 743 re-initiate the RRNP procedure. It makes sense to proceed with 744 sending normal Binding Update message only if the mobile router 745 itself is communicating with the correspondent node. If the 746 mobile router choose to re-initiate the RRNP procedure, it may 747 give up after consecutive failed attempts. 749 o Correspondent node does not support RR procedure 751 If the correspondent node does not support the original return 752 routability procedure, it will respond to the HoTI and CoTI 753 messages with an ICMP parameter problem code 1. The mobile router 754 should take such messages as indication of the correspondent node 755 not supporting the RR procedure. 757 o Correspondent node does not support RRNP procedure 759 If the correspondent node supports the original return routability 760 procedure, but not the RRNP extension, it will silently ignore the 761 Mobile Network Prefix option in HoTI message. This will result in 762 the correspondent node returning a HoT message without any Number 763 of Prefixes option. The mobile router should take the absence of 764 Number of Network Prefixes option as an indication of the 765 correspondent node not supporting the RRNP procedure, and either 766 proceed with the normal RR procedure, or give up the RRNP 767 procedure. It makes sense to proceed with the normal RR procedure 768 only if the mobile router itself is communicating with the 769 correspondent node. 771 6. Security Considerations 773 The RRNP procedure described is designed to minimize the possible 774 security threats mobile routers and correspondent nodes are exposed 775 to when attempting to achieve route optimization. The RRNP procedure 776 described here is an extension of the original RR procedure described 777 in Mobile IPv6. This extension has been carefully designed to retain 778 all the beneficial features of the original RR procedure [7]. 780 Firstly, keys and nonce used are never transmitted in clear. For an 781 attacker to independently derive the binding management key, the 782 attacker must be able to intercept all the Home Test, Care-of Test 783 and Network Prefix Test messages sent by the correspondent node. It 784 is especially difficult for the attacker to intercept the Network 785 Prefix Test message since the destination is a randomly selected 786 address. 788 Secondly, the correspondent node is not required to maintain any 789 state information before accepting the binding update. This reduces 790 the possibility of the correspondent node being exposed to 791 denial-of-service attack. 793 Thirdly, replay attacks are diverted since the Binding 794 Update/Acknowledgment message is protected by the Authenticator data, 795 so a replay attack staged by simply changing the sequence number of 796 previously snooped Binding Update/Acknowledgment message and 797 re-calculating the mobility header checksum will not work since the 798 cryptographic hash value in the Authenticator data will not tally. 800 The only relaxation in terms of security this RRNP procedure has is 801 that the correspondent node will need to send more than one packets 802 for every HoTI message received. It is thus possible for an attacker 803 to make use of this amplification effect to launch a distributed 804 denial-of-service attack against a victim, by having the 805 correspondent node send large number of HoT and NPT messages to the 806 victim. As mentioned in the earlier text, the correspondent node can 807 somewhat ameliorate this by adding random delays before sending the 808 NPT messages. In addition, the correspondent node can also refuse to 809 process subsequent HoTI messages when it has received a large number 810 of HoTI messages in a short span of time. Finally, the option of 811 whether to respond to route optimization should be made configurable 812 in implementations of correspondent node, and the default 813 configuration should be set to not perform route optimization. 815 7 References 817 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 818 IPv6", RFC 3775, June 2004. 820 [2] Devarapalli, V., "Network Mobility (NEMO) Basic Support 821 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 822 June 2004. 824 [3] Thubert, P., Molteni, M. and C. Ng, "Taxonomy of Route 825 Optimization models in the Nemo Context", 826 draft-thubert-nemo-ro-taxonomy-02 (work in progress), February 827 2004. 829 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 830 draft-ietf-nemo-terminology-01 (work in progress), February 831 2004. 833 [5] National Institute of Standards and Technology, "Secure Hash 834 Standard", FIPS PUB 180-1, April 1995, 835 . 837 [6] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 838 for Message Authentication", RFC 2104, February 1997. 840 [7] Nikander, P., "Mobile IP version 6 Route Optimization Security 841 Design Background", draft-ietf-mip6-ro-sec-01 (work in 842 progress), July 2004. 844 [8] Wakikawa, R., "Optimized Route Cache Protocol (ORC)", 845 draft-wakikawa-nemo-orc-00 (work in progress), July 2004. 847 Authors' Addresses 849 Chan-Wah Ng 850 Panasonic Singapore Laboratories Pte Ltd 851 Blk 1022 Tai Seng Ave #06-3530 852 Tai Seng Industrial Estate 853 Singapore 534415 854 SG 856 Phone: +65 65505420 857 EMail: cwng@psl.com.sg 858 Jun Hirano 859 Matsushita Electric Industrial Co., Ltd. (Panasonic) 860 5-3 Hikarino-oka 861 Yokosuka, Kanagawa 239-0847 862 JP 864 Phone: +81 46 840 5123 865 EMail: hirano.jun@jp.panasonic.com 867 Appendix A. Applicability of RRNP 869 Although this memo assumes route optimization to be achieved by 870 binding network prefixes to care-of address at the correspondent 871 node, the same principle behind RRNP can be used as long as a node 872 needs to verify if prefixes are indeed owned by some other node that 873 claims to own them. 875 For instance, in [8], correspondent router is performing route 876 optimization in proxy of correspondent node. The correspondent 877 router can then use RRNP to verify that mobile router owns the mobile 878 network prefix it claims to own. In addition, if the correspondent 879 router sends to the mobile router one or more network prefixes that 880 the correspondent router claims to be able to perform route 881 optimization on behalf of, the mobile router can use the same 882 principle behind RRNP to test the validity of such a claim. 884 In the latter case, there is no need to send the CoTI message if the 885 correspondent router is a fix node. The correspondent router can 886 simple send the HoTI message to the mobile router with network prefix 887 information. To test the validity, the mobile router responds with 888 HoT and NPT messages. The mobile router only accepts the 889 correspondent router as a valid proxy for the correspondent nodes the 890 correspondent router claims to manage when the RRNP procedure is 891 succesfully completed. 893 Intellectual Property Statement 895 The IETF takes no position regarding the validity or scope of any 896 Intellectual Property Rights or other rights that might be claimed to 897 pertain to the implementation or use of the technology described in 898 this document or the extent to which any license under such rights 899 might or might not be available; nor does it represent that it has 900 made any independent effort to identify any such rights. Information 901 on the procedures with respect to rights in RFC documents can be 902 found in BCP 78 and BCP 79. 904 Copies of IPR disclosures made to the IETF Secretariat and any 905 assurances of licenses to be made available, or the result of an 906 attempt made to obtain a general license or permission for the use of 907 such proprietary rights by implementers or users of this 908 specification can be obtained from the IETF on-line IPR repository at 909 http://www.ietf.org/ipr. 911 The IETF invites any interested party to bring to its attention any 912 copyrights, patents or patent applications, or other proprietary 913 rights that may cover technology that may be required to implement 914 this standard. Please address the information to the IETF at 915 ietf-ipr@ietf.org. 917 Disclaimer of Validity 919 This document and the information contained herein are provided on an 920 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 921 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 922 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 923 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 924 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 925 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 927 Copyright Statement 929 Copyright (C) The Internet Society (2004). This document is subject 930 to the rights, licenses and restrictions contained in BCP 78, and 931 except as set forth therein, the authors retain all their rights. 933 Acknowledgment 935 Funding for the RFC Editor function is currently provided by the 936 Internet Society.