idnits 2.17.00 (12 Aug 2021) /tmp/idnits48879/draft-na-nemo-nested-path-info-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' Scope Binding Updates)", draft-ernst-mobileip-v6-network-03' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) ** There are 440 instances of too long lines in the document, the longest one being 37 characters in excess of 72. ** The abstract seems to contain references ([2], [15], [3], [16], [4], [5], [7], [8], [9], [10], [11], [IDX], [12], [13], [ARO], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 2003) is 6823 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) -- Missing reference section? '15' on line 721 looks like a reference -- Missing reference section? '14' on line 717 looks like a reference -- Missing reference section? '4' on line 730 looks like a reference -- Missing reference section? '5' on line 730 looks like a reference -- Missing reference section? '8' on line 698 looks like a reference -- Missing reference section? '2' on line 678 looks like a reference -- Missing reference section? 'ARO' on line 134 looks like a reference -- Missing reference section? '1' on line 674 looks like a reference -- Missing reference section? 'IDX' on line 245 looks like a reference -- Missing reference section? '10' on line 704 looks like a reference -- Missing reference section? '16' on line 725 looks like a reference -- Missing reference section? '7' on line 695 looks like a reference -- Missing reference section? '9' on line 701 looks like a reference -- Missing reference section? '3' on line 681 looks like a reference -- Missing reference section? '11' on line 707 looks like a reference -- Missing reference section? '12' on line 710 looks like a reference -- Missing reference section? '13' on line 714 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group Jongkeun Na 3 Internet Draft Seongho Cho 4 Expires: March 2004 Chongkwon Kim 5 Seoul National University 6 Sunjin Lee 7 Hyunjeong Kang 8 Changhoi Koo 9 Samsung Electronics 10 September 2003 12 Secure Nested Tunnels Optimization using Nested Path Information 13 draft-na-nemo-nested-path-info-00 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document addresses how to securely achieve the nested tunnels 39 optimization using nested path information that reflects the 40 optimized path from Top Level Mobile Router(TLMR) to Mobile 41 Router(MR) in nested mobile networks. The solution is based on 42 Reverse Routing Header(RRH) idea and the concern of security 43 problem in RRH. By carefully taking a look at the simplicity of 44 Routing Header Type 2 routing mechanism and the complexity of 45 Access Router Option(ARO) based solution to get rid of the threat 46 of possible attack for RRH, the proposed solution has been 47 considered to preserve the efficiency of RRH without the lack of 48 security. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 54 this document are to be interpreted as described in RFC-2119. 56 Table of Contents 58 1. Introduction.................................................4 59 2. Terminology..................................................5 60 3. Overview of Operation........................................6 61 3.1 Reverse Packet Delivery(MR3 -> HA3).....................7 62 3.2 Forward Packet Delivery(HA3 -> MR3).....................8 63 4. Extensions..................................................10 64 4.1 Neighbor Discovery Extensions..........................10 65 4.2 MIPv6 Extensions.......................................11 66 4.3 MR Extension...........................................14 67 4.4 HA Extension...........................................15 68 5. Further Route Optimization..................................17 69 5.1 MN-HA Tunnel Optimization in Mobile Networks...........17 70 5.2 MN-CN Route Optimization in Mobile Networks............17 71 6. Security Considerations.....................................18 72 6.1 NPI Authenticity.......................................18 73 6.2 How to avoid the spoofing attack.......................18 74 6.3 The existence of fake MR...............................18 75 References.....................................................19 76 Acknowledgments................................................20 77 Authors' Addresses.............................................20 79 1. Introduction 81 NEMO Basic Support Solution[15] would suppose to support 82 transparent mobility to mobile network nodes(MNNs) in mobile 83 networks by using MR-HA bi-directional tunneling. However, if 84 multiple mobile networks are nested, that brings an routing 85 overhead to us which is well known as "pinball" routing problem[14]. 86 So, it needs to avoid routing overhead like this because we can 87 easily imagine the applications of nested mobile networks such as 88 NEMO in public transportations e.g. train, bus, airplane. In [4] 89 and [5], the nested routing problem has been broadly touched but in 90 general still not acceptable we think. 92 To get generally acceptable solution for this problem, this 93 document addresses how to securely achieve the nested tunnels 94 optimization using nested path information that reflects the 95 optimized path from Top Level Mobile Router(TLMR) to Mobile 96 Router(MR) in nested mobile networks. The solution is based on 97 Reverse Routing Header(RRH)[4] idea and the concern of spoofing 98 attack(or redirect attack) from [5]. By carefully taking a look at 99 the simplicity of Routing Header Type 2 routing mechanism and the 100 complexity of Access Router Option(ARO) solution to get rid of the 101 threat of possible attack for RRH, the proposed solution has been 102 considered to preserve the efficiency of RRH without the lack of 103 security. 105 In proposed solution, MR uses Nested Path Information(NPI) to 106 inform the optimized routing path of its HA. It discovers NPI in RA 107 sent from its Access Router(AR) and deliver that information to its 108 HA through BU. Unlike RRH of [4], NPI cannot be modified or forged 109 by the intermediate ARs. In case of the existence of fake AR on the 110 nested path, Of course, false NPI information may be used by AR. 111 It's impossible that there is unauthenticated fake AR if only 112 network access control properly applied. But, although it's 113 possible, the fake AR would not get any reward for such an 114 impersonating if the HA-MR tunnel could be protected by IPSEC and 115 the integrity of NPI also additionally protected by Authentication 116 Header[8]. In section 6, the security considerations will be more 117 mentioned. 119 2. Terminology 121 It is assumed that readers are familiar with NEMO terminology 122 described in [2][14], and the terms described in [4][5]. In 123 addition, we define a few of terms used in describing the operation 124 of our solution. 126 Nested Path Information (NPI) 128 A form of array of IPv6 global addresses that are the 129 addresses of Mobile Routers on the nested path which means 130 from TLMR to any nested MR in nested mobile networks. 132 RO-enabled 134 That is a similar with "NEMO-enabled" used in [ARO]. Simply, 135 any tunnel that applied with the scheme of route 136 optimization proposed by this document is referred to a "RO- 137 enabled" tunnel. 139 Nested Path Option (NP Option) 141 New type of option added in Router Advertisement to discover 142 NPI in nested mobile networks. That information is flowed 143 from TLMR to downward by relaying of each AR. 145 Nested Routing Path Option (NRP Option) 147 New type of mobility option used in BU message. That carries 148 NPI to Home Agent(HA). 150 3. Overview of Operation 152 We use the nested mobile network example as following Fig.1. 154 +---------------------+ 155 | Internet |---CN 156 +---------------|-----+ 157 / Access Router 158 HA3 | 159 ======*====== {RA[NPO:1:MR1-CoA]} 160 MR1(TLMR) 161 | 162 ====*==============================*========== 163 MR2 {RA[NPO:2:MR1-CoA|MR2-CoA]} MR4 {RA[NPO:2:MR1-CoA|MR4-CoA]} 164 | | 165 =======*==== =====================?==== 166 MR3 {RA[NPO:3:MR1-CoA|MR2-CoA|MR3-CoA]} VMN 167 | 168 ====|=======|===== <--- MONET3 169 LFN LMN 171 Fig.1 An example nested Mobile Network 173 In this example, we would have three bi-directional nested tunnels 174 by using NEMO Basic Solution if any nested tunnel optimization not 175 applied. 176 -----------. 177 --------/ /-----------. 178 -------/ | | /--------- 179 CN -----( - - | - - - | - - - | - - - | - - -(----- LFN 180 _HA3-------\ | | \--------- MR3 181 _HA2--------\ \----------- MR2 182 _HA1----------- MR1 184 With the proposed solution, we can get one optimized tunnel as 185 follows. From the following optimized tunnel, we can see that our 186 solution's optimized result is same with one in [4]. 188 ---------------------------------------------- 189 CN -----(|- - - - - - - - - - - - - - - - - - - - -|||(----- LFN 190 HA3---------------------------------------------- MR3 191 MR1 MR2 193 No receiving RA with NP Option in the access link gets MR1 know 194 that it is TLMR of nested mobile networks. As in Fig.1, MR1 sends 195 periodically RA with NP Option to its ingress link. MR2 and MR3 196 each relays its RA with modified NP Option, in which IPv6 global 197 address of the egress interface is appended, to ingress links. 199 Through the NP Option relay of MRs, MR3 results in getting know the 200 nested path such like MR1-CoA->MR2-CoA->MR3-CoA, the path to TLMR 201 from MR3. 203 MR3 can start extended Binding Update(BU) with HA3 for the route 204 optimization after getting NPI from RA with NP Option. MR3 uses NRP 205 Option, newly introduced mobility option to securely carry NPI to 206 HA3. This kind of BU with NRP Option makes it possible that the 207 nested tunnels optimization between MR3 and HA3. Basically, BU/BACK 208 message is exchanged to HA3 through normal nested tunnels. MR3_HA 209 receiving BU with NRP Option makes new Binding Cache(BC) entry with 210 NPI and RO-enabled tunnel-interface for forward tunneling. With 211 receiving successful BACK, MR3 also sets up the RO-enabled tunnel 212 interface for reverse tunneling. In RO-enabled tunnel interfaces 213 each created in MR3 and HA3 through MIPv6 BU/BACK exchange, NPI is 214 effectively used in routing that optimizing the nested tunnels. 216 After the establishment of RO-enabled bi-directional tunnel, MR3 217 can forward the packets from its ingress interfaces to RO-enabled 218 reverse tunnel interface and HA3 can do the packets destined to 219 MONET3 to RO-enabled forward tunnel interface. For details, the 220 following subsections describe the procedure of reverse and forward 221 packet delivery using the RO-enabled tunnel. 223 3.1 Reverse Packet Delivery(MR3 -> HA3) 225 In order to forward the packets sent from ingress side to HA3, MR3 226 makes sure that the correspondent tunnel interface is already 227 established by both MR3 and HA3. If that tunnel interface marked 228 with RO-enabled and NPI available in Binding Update List(BUL) entry, 229 MR3 builds the tunneling packet like below and forwards to next-hop 230 MR on the nested path. In the outer IPv6 header, Type 6 Routing 231 Header(RH) needs to be used to indicate next-hop MRs that this 232 tunneling packet can be delivered to the Home Agent through the 233 nested tunnels optimization using NPI. 235 <--------------- outer IPv6 header ---------------> 236 +-------+-------++ -- ++----+---+--------+---------++-------- 237 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || 238 MR3: |MR3-CoA| HA3 |:oEXT:|type| 2 |MR1-CoA | MR2-CoA || iPACKET 239 | | |: :| 6 | | | || 240 +-------+-------++ -- ++----+---+--------+---------++-------- 242 In the example, MR2 does not forward packets to HA2 via default 243 reverse tunnel(nested tunnel) if they have RH Type 6 optional 244 header. Instead of reverse tunneling, MR2 refers to the address, 245 Addr[IDX] indexed by IDX field, and makes sure that it is MR2's 246 address. If the indexed address matched with any of addresses of 247 its egress interfaces, MR2 forwards the packet, for which the 248 source address and IDX field in outer IPv6 header are only changed 249 as below, to that interface. Otherwise, the packet will be 250 discarded. As like MR2's operation, MR1 does the same thing as 251 below. 253 <--------------- outer IPv6 header ---------------> 254 +-------+-------++ -- ++----+---+--------+---------++-------- 255 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || 256 MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR2-CoA || iPACKET 257 | | |: :| 6 | | | || 258 +-------+-------++ -- ++----+---+--------+---------++-------- 260 <--------------- outer IPv6 header ---------------> 261 +-------+-------++ -- ++----+---+--------+---------++-------- 262 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || 263 MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR1-CoA | MR2-CoA || iPACKET 264 | | |: :| 6 | | | || 265 +-------+-------++ -- ++----+---+--------+---------++-------- 267 The packet sent from MR1 through the RO-enabled tunnel is delivered 268 to HA3. HA3 detects the existence of Type 6 RH optional header and 269 searches a BC entry with NPI that has TLMR on the nested path that 270 is exactly matched with the source address of the packet. If BU 271 entry is valid and the correspondent RO-enabled tunnel interface 272 exists, the packet is forwarded to the interface so that it is 273 properly decapsulated. As a result of the MR3-HA3 tunneling, the 274 inner packet properly routed to the original destination by HA3. 276 3.2 Forward Packet Delivery(HA3 -> MR3) 278 The packet destined to the LFN in MONET3 is intercepted by HA3 and 279 delivered by the procedure as follows. HA3 gets know that MR3-HA3 280 tunnel is RO-enabled. Therefore, the packet is forwarded to MR3 281 with encapsulated as below via RO-enabled tunnel interface. 283 <--------------- outer IPv6 header ---------------> 284 +-------+-------++ -- ++----+---+--------+---------++-------- 285 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 286 HA3:| HA3 |MR1-CoA|:oEXT:|type| 2 |MR2-CoA | MR3-CoA || iPACKET 287 | | |: :| 2 | | | || 288 +-------+-------++ -- ++----+---+--------+---------++-------- 290 MR1 does routing with extended semantics for the packets that have 291 RH Type 2 optional header as in [4]. The packets with RH Type 2 292 header sent from HA3 properly delivered to MR3 by MR1 and MR2 on 293 the nested path as follows: 295 <--------------- outer IPv6 header ---------------> 296 +-------+-------++ -- ++----+---+--------+---------++-------- 297 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 298 MR1:|_HA3 |MR2-CoA|:oEXT:|type| 1 |MR2-CoA | MR3-CoA || iPACKET 299 | | |: :| 2 | | | || 300 +-------+-------++ -- ++----+---+--------+---------++-------- 302 <--------------- outer IPv6 header ---------------> 303 +-------+-------++ -- ++----+---+--------+---------++-------- 304 |oSRC |oDST |: :|oRH |LS |Addr[1] | Addr[2] || 305 MR2:| HA3 |MR3-CoA|:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET 306 | | |: :| 2 | | | || 307 +-------+-------++ -- ++----+---+--------+---------++-------- 309 The packets with LS=0 are no more routed in MR3, therefore they are 310 processed by MR3 as if sent from nested forward tunneling between 311 MR3 and HA3. In the end, the packets decapsulated, and forwarded to 312 LFN. 314 4. Extensions 316 The proposed solution requires some extensions for existing MIPv6 317 and IPv6 protocols. 319 4.1 Neighbor Discovery Extensions 321 4.1.1 Nested Path Option(NP Option) 323 Basically, we use the same RA format used in [4] section 6.1. And 324 also, the format of additional NP Option inherits most of fields in 325 Tree Information Option used in [4] section 6.2 because of the 326 similarity of usage. The format of NP Option is as follows: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | Tree_Prefer. | NP_Length=n | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |F|H| Reserved | Bandwidth | DelayTime | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | MRPreference | BootTimeRandom | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | PathCRC | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 + + 341 | | 342 + Addr[1] + 343 | | 344 + + 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | o | 348 | o | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + + 352 | | 353 + Addr[n] + 354 | | 355 + + 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 This format represents the following changes over the originally 360 specified for Tree Information Option in [4]: 362 Type 364 8-bit unsigned integer set to the assigned value by the IANA. 365 TBD. 367 Length 369 8-bit unsigned integer updated by each MR on the nested path. 370 The length of the option (including the type and length 371 fields) in units of 8 octets. 373 NP_Length 375 4.1.2 8-bit unsigned integer set to 1 by the TLMR. That indicates 376 the size of Addr[] array. 378 Addr[1] 380 TLMR's IPv6 global address, set by the TLMR. Identifier of 381 the tree. 383 Addr[n] 385 IPv6 global address of n-th MRs on the way, set by n-th MR. 387 The TLMR MUST include this option in its Router Advertisements. 389 A MR receiving this option from its Attachment Router MUST update 390 the Length, TreeDepth, MRPreference, BootTimeRandom and PathCRC 391 fields,and addtionally MUST append its IPv6 global address as a 392 Addr[n] slot if it is n-th MR on the path, and MUST propagate it on 393 its ingress interface(s). The alignment requirement of the NP 394 Option is 8n. 396 4.2 MIPv6 Extensions 398 4.2.1 Nested Routing Path Option(NRP Option) 400 MR adds new mobility option, NRP Option in BU message to set up the 401 RO-enabled tunnel with its HA. The format of this option is as 402 follows: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type = TBA | Length=16*n | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | NP_Length=n | Reserved | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 + + 413 | | 414 + Addr[1](=TLMR address) + 415 | | 416 + + 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | o | 420 | o | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 + + 424 | | 425 + Addr[n] + 426 | | 427 + + 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Type 433 8-bit identifier of the Mobility Header option type. The 434 value that identifies an Access Router Option is yet to be 435 assigned. 437 Length 439 8-bit unsigned integer that specifies the length of the 440 mobility option in octets, excluding Type and Length fields. 442 NP_Length 444 8-bit unsigned integer that indicates the number of Addr[] 445 slots. 447 Addr[1..n] 449 Vector of IPv6 global addresses of MRs on the nested path, 450 numbered 1 to n. 452 NRP Option is only valid in a Binding Update message. The purpose 453 of this option is to inform HA that it can do optimize the nested 454 tunnels overhead. Using this information, HA can route packets to 455 the sender via the MRs on the nested path by extended Type 2 RH 456 optional header. 458 4.2.2 Extended Type 2 Routing Header(RH) 460 The format and semantics of Type 2 Routing Header is perfectly same 461 with one defined in [4] section 4.1. 463 4.2.3 Type 6 Routing Header 465 Type 6 Routing Header is newly defined to enable the NPI-aware 466 routing by MRs on the nested path. the format of this header is as 467 follows: 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Next Header | Hdr Ext Len | Routing Type=6| NextIndex=n | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Reserved | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 + + 478 | | 479 + Addr[1] + 480 | | 481 + + 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 . . 486 . . . . . 487 . . 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 + + 492 | | 493 + Addr[n] + 494 | | 495 + + 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Next Header 500 8-bit selector. Identifies the type of header immediately 501 following the Routing Header. Uses the same value as the 502 IPv6 Next Header field [10]. 504 Hdr Ext Len 506 8-bit unsigned integer. Length of the routing header in 8- 507 octet units, not including the first 8 octets. This value 508 is always equal to twice the number of addresses in the 509 Address vector. 511 Routing Type 513 8-bit unsigned integer that contains the value 6. This is 514 type value unconfirmed by IANA. TBD. 516 NextIndex 518 8-bit unsigned integer. This value identifies the index of 519 address vector. The forwarder needs to make sure that 520 indexed address is same with its address. If yes, it changes 521 the source address of the packet to its address and forwards 522 the packet. By hop-by-hop, the mobile router that 523 understands this type of routing header MUST decrements 524 NextIndex by 1 at forwarding. If NextIndex is 0, ignore this 525 option. 527 Address[1..n] 529 Vector of 128-bit addresses, numbered 1 to n. 531 4.3 MR Extension 533 According to MIPv6 Spec.[1], MR MUST maintain Binding Update 534 List(BU List). In managing BU List, the following information MUST 535 be maintained additionally to use RO-enabled MR-HA tunnel defined 536 in this proposed solution. 538 Nested Tunnels Optimization(NTO) flag : 540 When set indicates that the associated BU entry is RO- 541 enabled for nested tunnels optimization. 543 Nested Path Information(NPI) Address Vector : 545 The path vector information transferred in Nested Routing 546 Path Option at BU. 548 The successful BU with NRP Option allows the ready of RO-enabled 549 tunnel interface that would be associated with the correspondent 550 entry of BU List. That tunnel interface is set up to add Type 6 RH 551 optional header at the encapsulation of tunneled packets. After RO- 552 enabled BU, all packets through RO-enabled reverse tunnel have Type 553 6 RH optional header in tunnel extension header so that they are 554 properly delivered to HA through the optimized nested path. 556 For packets sent from HA through Type 2 RH, MR decapsulates the 557 outer packet, and forwards the inner packet to the ingress side. 558 There is no difference with normal packets routed via nested tunnel 559 because source address is HA and destination address is MR. 561 4.4 HA Extension 563 According to MIPv6 Spec.[1], HA MUST maintain Binding Cache(BC). 564 Like MR extension, HA MUST maintain additionally the following 565 information in associated BC entry in case of receiving BU with NRP 566 Option. 568 Nested Tunnels Optimization(NTO) flag : 570 When set indicates that the associated BU entry is RO- 571 enabled for nested tunnels optimization. 573 Nested Path Information(NPI) Address Vector : 575 The path vector information carried in Nested Routing Path 576 Option during BU. 578 With the success of BU, HA has to add new entry in tunnel interface 579 table. At that time, the tunnel interface is being marked with RO- 580 enabled so that Extended Type 2 RH[4] inserted into Tunnel 581 Extension Header[16] at processing packet tunneling encapsulation. 582 As a result of applying Type 2 RH based on NPI, all packets 583 destined to mobile networks are forwarded to TLMR on the nested 584 path through the RO-enabled forward tunnel. 586 For the packets forwarded via RO-enabled reverse tunnel by MR, HA 587 decapsulates them, and checks the validity of Type 6 RH. the 588 conditions are as follows: 590 (1) NextIndex MUST be zero. 592 (2) There is at least one entry registered by BU with NPI in 593 which TLMR address matches the source address of incoming 594 outer packet. 596 (3) CareOf address of the BC entry MUST match the last one's 597 address(e.g. MR3) which is the result of subtracting from 598 NPI address vector(e.g. MR1->MR2->MR3) to the addresses in 599 Type 6 RH(e.g. MR1->MR2) in order. 601 If above conditions are all satisfied, inner packets are forwarded 602 by MIPv6 specification. Otherwise, they are discarded by HA. 604 5. Further Route Optimization 606 5.1 MN-HA Tunnel Optimization in Mobile Networks 608 In Fig.1, VMN can do RO-enabled binding update with MR4_HA using 609 nested path MR1_CoA->MR4_CoA. VMN-VMN_HA tunnel can be optimized if 610 VMN follows faithfully extension of the operation like MR does in 611 section 4.4. 613 5.2 MN-CN Route Optimization in Mobile Networks 615 MIPv6 Route Optimization can be considered in nested mobile 616 networks. To apply our solution, the following extensions are 617 required to MN and CN. 619 (1) MN and CN MUST use the nested routing path option in 620 doing BU. 621 (2) RH Type 6 optional header MUST be applied to the packets 622 sent from MN to CN. 623 (3) Extended RH Type 2 optional header MUST be applied to 624 the packets sent from CN to MN. 626 We see the possibility and detailed protocol design of MN-CN route 627 optimization using NPI will be next our work item. 629 6. Security Considerations 631 Basically, MR-HA bi-directional tunneling is protected by 632 IPSEC[7][8][9]. However, we can suspect that the part of NPI maybe 633 untrustworthy by itself or can be modified by the intermediate AR 634 that be fake. In case of [4], the vulnerability for spoofing attack 635 by an attacker on the nested path has been known. Those kinds of 636 attack can be avoided in the proposed solution as the integrity of 637 NPI is guaranteed on the fly. 639 6.1 NPI Authenticity 641 We need to assure that NPI is an available path and intact. To get 642 the assurance, there MUST be any security mechanism to authenticate 643 AR on access link by MR each other. That would be implemented with 644 some types of Network Access Control(NAC) or domain-specific 645 authentication method. Due to out of scope of this document, the 646 details for those mechanisms will not be described in here, but our 647 solution needs to assume pre-established security association 648 between visited AR and visiting MR for NPI authenticity. 650 6.2 How to avoid the spoofing attack 652 The integrity of information chunks of RH Type 6/2 used in our 653 solution can be guaranteed by using AH[8]. It means that the 654 intermediate forwarders on the nested path for RH Type 6/2 cannot 655 modify any part of NPI. Unlike RRH, NPI is immutable except for 656 NextIndex so that it can be protected by AH. Any attacker that 657 doesn't know secret key used in MR-HA tunnel cannot forge NPI 658 protected by AH for its own benefit. 660 6.3 The existence of fake MR 662 There may be a fake MR acting as a forwarder on NPI path. 663 Inadvertently or not, it's possible because of the lack of network 664 access security mentioned in section 6.1. Although in this case, 665 NPI in RH Type 6/2 cannot be modified because of AH protection. And, 666 Any contents through MR-HA tunnel cannot be disclosed because it 667 can be protected by ESP[9]. Merely, the possible attack is a 668 passive denial-of-service that means the denial of routing service. 669 However, as these types of attacks can be easily detected, it 670 cannot be an effective attack in itself. 672 References 674 [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in 675 IPv6", draft-ietf-mobileip-ipv6-18 (work in progress), July 676 2002. 678 [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 679 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 681 [3] Ernst, T., Castelluccia, C., Bellier, L., Lach, H. and A. 682 Olivereau, "Mobile Networks Support in Mobile IPv6 (Prefix 683 Scope Binding Updates)", draft-ernst-mobileip-v6-network-03 684 (work in progress), March 2002. 686 [4] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header 687 and Its Application to Mobile Networks", Internet Draft: 688 draft-thubert-nemo-reverse-routing-header-01 689 (work in progress), Oct 2002. 691 [5] Chan-Wah Ng, and Takeshi Tanaka, "Securing Nested Tunnels 692 Optimization with Access Router Option", Internet Draft:draft 693 -ng-nemo-access-router-option-00(work in progress), Oct 2002. 695 [7] Kent, S. and R. Atkinson, "Security Architecture for the 696 Internet Protocol", RFC 2401, November 1998. 698 [8] Kent, S. and R. Atkinson, "IP Authentication Header", 699 RFC 2402, November 1998. 701 [9] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 702 (ESP)", RFC 2406, November 1998. 704 [10] Deering, S. and R. Hinden, "Internet Protocol, 705 Version 6 (IPv6) Specification", RFC 2460, December 1998. 707 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 708 for IP Version 6 (IPv6)", RFC 2461, December 1998. 710 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 711 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 712 Specification", RFC 2463, December 1998. 714 [13] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 715 an On-line Database", RFC 3232, January 2002. 717 [14] Thubert, P., and Molteni, M., "Taxonomy of Route Optimization 718 Models in the NEMO Context", Internet Draft: draft-thubert- 719 nemo-ro-taxonomy-00(work in progress), Oct 2002. 721 [15] vijay, D., Ryuji, W., Alexandru, P., Pascal, T., "NEMO Basic 722 Support Protocol", draft-ietf-nemo-basic-support-00(work in 723 process), June 2003. 725 [16] A. Conta, S. Deering, "Generic Packet Tunneling in IPv6 726 Specificiation", RFC2473, December 1998. 728 Acknowledgments 730 Authors would like to thank you the authors of [4] and [5] for a 731 fruitful comments on this problem area. 733 Authors' Addresses 735 Jongkeun Na 736 Information Networking & Computing Lab. 737 School of Computer Science and Engineering, 738 Seoul National University, Seoul Korea 739 EMail: jkna@popeye.snu.ac.kr 741 Sungho Cho 742 Information Networking & Computing Lab. 743 School of Computer Science and Engineering, 744 Seoul National University, Seoul Korea 745 EMail: shcho@popeye.snu.ac.kr 747 Chongkwon Kim 748 Information Networking & Computing Lab. 749 School of Computer Science and Engineering, 750 Seoul National University, Seoul Korea 751 EMail: ckim@popeye.snu.ac.kr 753 Sungjin Lee 754 Telecommunication R&D Center, 755 Samsung Electronics 756 Dong Suwon P.O. BOX 105 757 416, Maetan-3Dong, Paldal-Gu 758 Suwon-City, Gyunggi-Do, 442-600 759 KOREA 760 EMail : steve.lee@samsung.com 761 Hyungjeong Kang 762 Telecommunication R&D Center, 763 Samsung Electronics 764 Dong Suwon P.O. BOX 105 765 416, Maetan-3Dong, Paldal-Gu 766 Suwon-City, Gyunggi-Do, 442-600 767 KOREA 768 EMail : hyunjeong.kang@samsung.com 770 Changhoi Koo 771 Telecommunication R&D Center, 772 Samsung Electronics 773 Dong Suwon P.O. BOX 105 774 416, Maetan-3Dong, Paldal-Gu 775 Suwon-City, Gyunggi-Do, 442-600 776 KOREA 777 EMail : chkoo@samsung.com