idnits 2.17.1 draft-ietf-mobileip-3gwireless-ext-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 129 == Unused Reference: '2' is defined on line 576, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 587, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 591, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 604, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 607, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2344 (ref. '2') (Obsoleted by RFC 3024) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2356 (ref. '4') == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mn-nai-05 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-06 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-08 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1700 (ref. '9') (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Yingchun Xu (editor) 2 Internet Draft Rajesh Bhalla 3 June 2000 Ed Campbell 4 Karl Freter 5 3Com Corporation 6 Eileen McGrath Hadwen 7 Alcatel 8 Gopal Dommety 9 Kirit Joshi 10 Cisco Systems 11 Parviz Yegani 12 Ericson Wireless Communication Inc 13 Takeo Matsumura 14 FUJITSU 15 Atsushi Teshima 16 HITACHI Ltd. 17 Lee Dong Hyun 18 HYUNDAI Electronics 19 Naoto Itoh 20 IDO Corporation 21 Kimihiro Ohki 22 KDD Corporation 23 Byung-Keun Lim 24 LG Information & Communications,Ltd 25 Peter J. McCann 26 Thomas Towle 27 Lucent Technologies 28 Jay Jayapalan 29 Motorola Inc. 30 Peter W. Wenzel 31 Carey B. Becker 32 James Jiang 33 Nortel Networks 34 Shota Shikano 35 Oki Electric Industry Co., Ltd. 36 Woojune Kim 37 Yong Chang 38 Bill Semper 39 Samsung Electronics Ltd. 40 Jun Mo Koo 41 SK Telecom 42 Mark A. Lipford 43 Frederic Leroudier 44 Sprint PCS 45 Jim Gately 46 USWest Advanced Technologies 48 Mobile IP Based Micro Mobility Management Protocol in 49 The Third Generation Wireless Network 50 52 Xu et al. Expires December 2000 1 53 Status of this Memo 55 This document is an Internet Draft and is in full conformance with 56 all provisions of Section 10 of RFC2026. Internet Drafts are working 57 documents of the Internet Engineering Task Force (IETF), its areas, 58 and working groups. Note that other groups may also distribute 59 working documents as Internet Drafts. 61 Internet Drafts are draft documents valid for a maximum of six 62 months and may be updated, replaced, or obsolete by other documents 63 at anytime. It is inappropriate to use Internet Drafts as reference 64 material or to cite them other than as "work in progress." 66 The list of current Internet-Drafts can be accessed at 67 http://www.ietf.org/ietf/1id-abstracts.txt. 69 The list of Internet-Draft Shadow Directories can be accessed at 70 http://www.ietf.org/shadow.html. 72 Abstract 74 This document defines extensions to the Mobile IP protocol [1] to 75 allow mobility management for the interface between a radio network 76 and a packet data network in the third generation cdma2000 network. 78 Mobile IP requires link layer connectivity between the Mobile Node 79 and the Foreign Agent. This draft proposes a protocol for achieving 80 this when the physical layer terminates at a point distant from the 81 FA. In particular, this protocol applies to cdma2000 networks where 82 the physical layer terminates at a Radio Network Node (RNN) and the 83 FA resides inside a separate Packet Data Serving Node (PDSN). The 84 PDSN is responsible for establishing, maintaining, and terminating 85 the link layer to the Mobile Node. A RNN is responsible for relaying 86 the link layer protocol between a Mobile Node and its corresponding 87 PDSN. 89 The interface between the RNN and the PDSN is called the RP 90 interface. This interface requires mobility management for handling 91 handoff from one RNN to another without interrupting end to end 92 communication. It also requires the support of the link layer 93 protocol encapsulation. 95 1. Introduction 97 This document defines extensions to the Mobile IP protocol [1] to 98 allow mobility management for the interface between a radio network 99 and a packet data network in the third generation cdma2000 network. 101 Mobile IP requires link layer connectivity between the Mobile Node 102 and the Foreign Agent. This draft proposes a protocol for achieving 103 this when the physical layer terminates at a point distant from the 105 Xu et al. Expires December 2000 2 106 FA. In particular, this protocol applies to cdma2000 networks where 107 the physical layer terminates at a Radio Network Node (RNN) and the 108 FA resides inside a separate Packet Data Serving Node (PDSN). The 109 PDSN is responsible for establishing, maintaining, and terminating 110 the link layer to the Mobile Node. A RNN is responsible for relaying 111 the link layer protocol between a Mobile Node and its corresponding 112 PDSN. 114 The interface between the RNN and the PDSN is called the RP 115 interface. This interface requires mobility management for handling 116 handoff from one RNN to another without interrupting end to end 117 communication. It also requires the support of the link layer 118 protocol encapsulation. 120 The messages used for mobility management across the RP interface 121 include Registration Request, Registration Reply, Registration 122 Update and Registration Acknowledge. Both Registration Request and 123 Registration Update messages MUST be sent with UDP using well-known 124 port number 697. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 128 this document are to be interpreted as described in [RFC-2119]. 130 2. Glossary 132 CDMA Code Division Multiple Access 133 FA Foreign Agent 134 HA Home Agent 135 MN Mobile Node 136 PDSN Packet Data Serving Node 137 RNN Radio Network Node 138 RP Interface between the RNN and the PDSN 140 3. cdma2000 Network RP Interface Overview 142 The high level architecture of a third generation cdma2000 network 143 RP interface is shown in Figure 1. 145 +---------+ +---------+ +---------+ 146 | | | | | | 147 | RNN |----RP------| PDSN |---------| HA | 148 | | Interface | | | | 149 +---------+ +---------+ +---------+ 150 /|\ 151 | Visited Access Home Network 152 | Provider Network 153 | 154 | 155 \|/ 156 +--------+ 157 | Mobile | 159 Xu et al. Expires December 2000 3 160 | Node | 161 +--------+ 163 Figure 1: The Third Generation cdma2000 Network RP Interface 165 In above figure 1, the PDSN will be responsible for establishing, 166 maintaining, and terminating the link layer to the Mobile Node. It 167 initiates the authentication, authorization, and accounting for the 168 Mobile Node and optionally, securely tunnels to the Home Agent. 170 The RNN is responsible for mapping the Mobile Node identifier 171 reference to a unique link layer identifier used to communicate with 172 the PDSN. RNN validates the Mobile Station for access service and 173 manages the physical layer connection to the Mobile Node. 175 4. Mobile IP Extensions 177 This section describes extensions to the Mobile IP protocol for the 178 RP interface within the third generation cdma2000 network. 180 4.1 Registration Request 182 In a cdma2000 network, the mobile node initiates a connection by 183 sending a call setup indication to the RNN across the radio network. 184 When this indication is received by a RNN, a Registration Request 185 will be sent from the RNN to the PDSN to setup a new RP session. 187 A RNN MUST send a Registration Request with the GRE encapsulation 188 and the reverse tunneling bit set. The Home Address field is set to 189 zero. The Home Agent field will be assigned to the IP address of the 190 PDSN and the Care-of Address field will be assigned to the IP 191 address of RNN. 193 When a Registration Request is received by a PDSN, the information 194 from the Session Specific Extension (see next section) will be used 195 to identify a RP session. When a registration is accepted, a GRE 196 tunnel will be created for this Mobile Node. 198 The message is sent with UDP using well-known port number 697. 200 The fields of the Registration Request message are shown below: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type |S|B|D|M|G|V|T| | Lifetime | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Home Address | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Home Agent | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Care-of Address | 213 Xu et al. Expires December 2000 4 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 + Identification + 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Extensions ... 220 +-+-+-+-+-+-+-+- 222 Type 1 (Registration Request) 224 G This bit MUST be set to 1 for GRE tunneling. 226 T This bit MUST be set to 1 for reverse 227 tunneling. 229 Home Address 230 The field is set to zero. 232 Home Agent 233 This field is assigned to the IP address of the 234 PDSN. 236 Care-of Address 237 This field is assigned to the IP address of 238 RNN. 240 Extensions 241 The Session Specific Extension as described in 242 the next section MUST be included along with 243 the ones described in RFC2002. Specifically, 244 the MN-HA Authentication extension as described 245 in RFC2002 MUST be included along with this 246 extension. 248 4.2 Session Specific Extension 250 This extension is defined to carry information related to the 251 session between a Mobile Node and its serving PDSN. 253 The detailed format of the extension is shown as follows. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | Protocol Type | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Key 261 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved | MN Connection ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | MN ID Type | MN ID Length | MN ID | 267 Xu et al. Expires December 2000 5 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | MN ID ... 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Type 39 (not-skippable). 274 Length This is a one octet field and it indicates the 275 length (in bytes) of the extension, NOT 276 including the Type and Length fields. 278 Protocol Type 279 This is a two octet field. It indicates the 280 type of the protocol to be tunneled across the 281 RP interface. It is same as the Protocol Type 282 field in the GRE header. 284 Key 285 This is a four octet value assigned by the RNN 286 and inserted in every GRE frame across the RP 287 interface during user data tunneling. 289 Reserved 290 This is a two octet field. It is not used and is 291 set to zero. 293 MN Connection ID 294 This is a two octet field and it is used to 295 differentiate the multiple sessions from the 296 same Mobile Node. It is locally unique to a 297 Mobile Node. 299 MN ID Type 300 This is a two octet field and it indicates the 301 type of the following Mobile Node ID value. 303 Type value 1 will be reserved for International 304 Mobile Station Identity (IMSI) encoded in ASCII 305 format. For detailed description of the IMSI, 306 see reference [8]. 308 MN ID Length 309 This is a one octet field and it indicates the 310 length (in bytes) of the following Mobile Node 311 ID field. For IMSI MN ID encoded in ASCII 312 format, the length field value ranges from 10 313 to 15 bytes. 315 MN ID 316 This is the Mobile Node ID, which is globally 317 unique. It is used to uniquely identify a Mobile 318 Node. 320 Xu et al. Expires December 2000 6 321 For Type 1 MN ID, the most significant digit of 322 IMSI will be coded in ASCII and stored as the 323 most significant byte of the MN ID. 325 This extension MUST be included in the Registration Request, 326 Registration Reply, Registration Update and Registration Acknowledge 327 (see section 4.5) messages. It will be included before the MN-HA 328 Authentication extension in the Registration Request and 329 Registration Reply messages and before the Registration Update 330 Authentication Extension in the Registration Update and Registration 331 Acknowledge messages. 333 The MN ID and the MN Connection ID together will uniquely identify a 334 Mobile Session. 336 4.3 Registration Reply 338 The Registration Reply will be sent by a PDSN following the 339 procedure as described in [1]. The Home Address field will be the 340 same value as the Home Address field from the corresponding 341 Registration Request message received by the PDSN. 343 The message is sent with UDP to the source port of the received 344 Registration Request message. 346 4.4 Registration Update/Acknowledge 348 Two new messages are defined to support PDSN initiated RP tunnel 349 tear down and to speed up resource reclamation on the RNN. 351 The Registration Update message is used for notification of the 352 change of the registration associated with a call. It shall be sent 353 by the PDSN to the previous RNN when a RNN to RNN handoff happens. 355 The Registration Update message is sent with UDP using well-known 356 port number 697. And the Registration Acknowledge message is sent 357 with UDP to the source port from the received correspondent 358 Registration Update message. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Reserved | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Home Address | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Home Agent Address | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 + Identification + 371 | | 373 Xu et al. Expires December 2000 7 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Extensions ... 376 +-+-+-+-+-+-+-+- 378 The format of the Registration Update message is illustrated above, 379 and contains the following fields: 381 Type 20 383 Reserved Sent as 0; ignored on reception. 385 Home Address Sent as 0; 387 Home Agent Address 388 The IP Address of the PDSN. 390 Identification 391 A 64-bit number assigned by the node sending 392 the Registration Update message. It is used to 393 assist in matching requests with replies, and 394 in protecting against replay attacks. 395 Extensions 396 Both Registration Update Authentication 397 Extension (see section 4.6) and Session 398 Specific Extension (see section 4.2) SHALL be 399 included. 401 A Registration Update shall be sent by a PDSN to indicate the 402 closure of a RP session. The RNN may reclaim the resource associated 403 with that session. 405 A Registration Acknowledge message is used to acknowledge receipt of 406 a Registration Update message. It MUST be sent by a node receiving a 407 Registration Update message. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Status | Reserved | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Home Address | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Care Of Address | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 + Identification + 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Extensions ... 423 +-+-+-+-+-+-+-+- 425 Xu et al. Expires December 2000 8 426 The format of the Registration Acknowledge message is illustrated 427 above, and contains the following fields: 429 Type 21 431 Status If the Status is nonzero, this acknowledgment is 432 negative. 434 Reserved 435 Sent as 0; ignored on reception. 437 Home Address 438 Copied from the Registration Update message 439 being acknowledged. 441 Care of Address 442 The IP address of the RNN. 444 Identification 445 Copied from the Registration Update message 446 being acknowledged. 448 Extensions 449 Both Registration Update Authentication 450 Extension (see section 4.6) and Session 451 Specific Extension (see section 4.2) SHALL be 452 included. 454 Allowable values for the Status include: 456 0 successful acknowledgement 457 128 reason unspecified 458 129 administratively prohibited 459 131 sending node failed authentication 460 133 identification mismatch 461 134 poorly formed Registration Update 463 4.5 Registration Update Authentication Extension 465 The Registration Update Authentication extension is used to 466 authenticate the Registration Update and Registration Acknowledge 467 messages. It has the same format and default algorithm support 468 requirements as the authentication extension defined for Mobile IP 469 protocol [1], but with a different type (40). The authenticator 470 value is computed from the stream of bytes including the shared 471 secret, the UDP payload all prior extensions in their entirety, and 472 the type and length of this extension, but not including the 473 authenticator field itself nor the UDP header. The secret used for 474 computing the authenticator field is shared between the RN and PDSN. 475 This extension is required in both Registration Update and 476 Registration Acknowledge messages. 478 Xu et al. Expires December 2000 9 479 4.6 Summary 481 The extensions to Mobile IP include enabling the GRE encapsulation 482 and reverse tunneling during Registration. A new extension called 483 Session Specific Extension is defined and is mandatory in the 484 Registration Request, Registration Reply, Registration Update and 485 Registration Acknowledge messages. The Home Address field MUST be 486 set to zero in the Registration Request, Registration Reply, 487 Registration Update and Registration Acknowledge messages. 489 Two new messages (Registration Update and Registration Acknowledge) 490 are defined to support the RP session disconnection in order to 491 speed up resource reclamation. 493 5.0 GRE Encapsulation 495 GRE encapsulation as described in [3] shall be supported during user 496 data transmission. A new protocol type might be required to support 497 the link layer protocol defined for the third generation cdma2000 498 network. The Key field shall be required and its value shall be same 499 as the one from the Session Specific Extension as described above. 500 The sequence number may be required, depending on the requirement of 501 the protocol encapsulated within the GRE frame. 503 During traffic tunneling, the sender will insert the Key value from 504 the Registration Request message into the Key field of the GRE 505 header. The receiver will use the Key value from the GRE header to 506 decide where to forward the user data. 508 6.0 IANA Considerations 510 This document specifies two new messages and two new extensions to 511 Mobile IP protocol [1]. The numbers to be assigned to these messages 512 and extensions have been taken from the numbering space assigned to 513 Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4]. 515 The Registration Request and Registration Update messages MUST be 516 sent with UDP using well-known port number 697. This port number is 517 chosen from the unassigned port range as specified in RFC1700 [9]. 519 The Registration Update and Registration Acknowledge messages 520 defined in section 4.4 MUST be assigned the Type values of 20 and 21 521 respectively. 523 The Session Specific Extension defined in section 4.2 MUST be 524 assigned the Type value of 39, and the Registration Update 525 Authentication Extension defined in section 4.5 MUST be assigned a 526 value of 40. The Status values defined in section 4.4 are the error 527 codes defined in RFC 2002 [1]. They correspond to the error values 528 conventionally associated with a rejection by a home agent (i.e., 530 Xu et al. Expires December 2000 10 531 the values from the range 128-255). The IANA MUST record the Status 532 values as defined in section 4.4 of this document. 534 With these assignments, the Type values assigned to the two new 535 messages and to two new extensions, and the error values for the 536 Status field, have been identified as not conflicting with any 537 numbers defined for Mobile IP to date and documented at 538 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 540 7.0 Security Considerations 542 The protocol presented in this draft is designed for use over a 543 protected, private network between RNN and PDSN. Pre-arranged 544 security associations in the style of Mobile IPv4 are assumed to 545 exist among every (RNN, PDSN) pair that will form an RP connection. 546 Also, it is assumed that the session specific information is 547 authenticated by means outside the scope of this draft. 549 Several potential vulnerabilities exist if these assumptions are not 550 met. First, if the network connecting the RNN and PDSN is accessible 551 to an attacker, user traffic may be intercepted and/or spoofed if 552 there are no other end-to-end security mechanisms in place. Second, 553 the Mobile IP control messages must be authenticated, to prevent 554 tunnel setup and tear down by unauthorized parties. Mobile IP 555 Authentication Extensions are used to provide this additional 556 protection for control messages. Finally, if session specific 557 information is not authenticated, a denial-of-service attack is 558 possible if a RNN unknowingly sends a registration request to the 559 PDSN with a spoofed session specific extension. The PDSN would then 560 send an explicit tunnel tear down to the previous RNN, causing user 561 traffic to be misdirected to the new RNN. This would cause a loss of 562 service and possibly interception of traffic, depending on what 563 other security measures are in place. 565 8.0 Acknowledgments 567 The authors of this draft would like to thank Charles E. Perkins and 568 David B. Johnson for the ideas presented in the Route Optimization 569 draft [7]. 571 References 573 [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 574 1996. 576 [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 577 1998. 579 [3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic 580 Routing Encapsulation (GRE)", RFC 1701, October 1994. 582 Xu et al. Expires December 2000 11 584 [4] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for 585 Mobile IP". RFC 2356, June 1998. 587 [5] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network 588 Address Identifier Extension". draft-ietf-mobileip-mn-nai- 589 05.txt, October 1999. (work in progress). 591 [6] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ 592 Response Extensions". draft-ietf-mobileip-challenge-06.txt, 593 October 1999. (work in progress). 595 [7] Charles E. Perkins and David B. Johnson. "Route Optimization in 596 Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. 597 (work in progress). 599 [8] TIA/EIA/IS-95-B 601 [9] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October 602 1994. 604 [10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P., 605 "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. 607 [11] Gopal Dommety. "Key and Sequence Number Extensions to GRE". 608 draft-dommety-gre-ext-04.txt, June 2000. (work in progress) 610 Author's Addresses 612 Yingchun Xu 613 3Com Corporation 614 1800 West Central Road 615 Mount Prospect, 616 USA 60056 617 Phone: (847) 342-6814 618 Email: Yingchun_Xu@3com.com 620 Rajesh Bhalla 621 3Com Corporation 622 1800 West Central Road 623 Mount Prospect, 624 USA 60056 625 Phone: (847) 797-2618 626 Email: rajesh_bhalla@3com.com 628 Karl Freter 629 3Com Corporation 630 1800 W. Central Road 631 Mount Prospect, IL 60056 632 Phone: (847) 222-2268 634 Xu et al. Expires December 2000 12 635 Email: karl_freter@3com.com 637 Ed Campbell 638 3Com Corporation 639 1800 W. Central Road 640 Mount Prospect, IL 60056 641 Phone:(847) 342-6769 642 Email: ed_campbell@3com.com 644 Eileen McGrath Hadwen 645 Alcatel 646 PO Box 4442, 647 Boulder CO 80306 648 Phone: 303 499 1496 649 Email: mcgrath.hadwen@worldnet.att.net 651 Gopal Dommety 652 Cisco Systems 653 170 West Tasman Drive 654 San Jose, CA 95134 655 Phone: (408) 525-1404 656 Email: gdommety@cisco.com 658 Kirit Joshi 659 Cisco Systems 660 170 West Tasman Drive 661 San Jose, CA 95134 662 Phone: (408) 525 7367 663 Email: kjoshi@cisco.com 665 Parviz Yegani 666 Ericson Wireless Communication Inc. 667 6455 Lusk Blvd. 668 San Diego, CA 92121 669 Phone: (858) 332-6017 670 Email: p.yeqani@ericsson.com 672 Takeo Matsumura 673 FUJITSU 674 Kamiodanaka 675 Nakahara-ku, Kawasaki-City 676 Phone: +81-44-740-8109 677 Email: matumura@mcs.ts.fujitsu.co.jp 679 Atsushi Teshima 680 HITACHI Ltd. 681 216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567 682 Phone:+81-45-865-7003 683 Email: atsushi_teshima@cm.tcd.hitachi.co.jp 685 Lee Dong Hyun 686 HYUNDAI Electronics Industry 687 KOREA Kyungkido Icheonsi 435-050 689 Xu et al. Expires December 2000 13 690 Phone: 82-336-630-2756 691 Email: jihs@hei.co.kr 693 Naoto Itoh 694 IDO Corporation 695 Gobancho YS building 696 12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361 697 Phone: +81-3-3263-9660 698 Email: nao-itoh@ido.co.jp 700 Kimihiro Ohki 701 KDD Corporation 702 3-2, Nishi-Shinjuku 2-chome, 703 Shinjuku-ku, Tokyo 163-8003, Japan 704 Phone: +81-3-3347-5477 705 Email: ki-ohki@kdd.co.jp 707 Byung-Keun Lim, 708 LG Information & Communications, Ltd. 709 533, Hogye-dong, Dongan-ku, Anyang-shi, 710 Kyungki-do,431-080, Korea 711 Phone: +82-343-450-7199 712 Email: bklim@lgic.co.kr 714 Peter J. McCann 715 Lucent Technologies 716 Rm 2Z-305 717 263 Shuman Blvd 718 Naperville, IL 60566 719 Phone: (630) 713 9359 720 EMail: mccap@lucent.com 722 Thomas Towle 723 Lucent Technologies 724 Rm. 2D-225 725 263 Shuman Blvd 726 Naperville, IL 60566 727 Phone: 630-979-7303 728 Email: ttowle@lucent.com 730 Jay Jayapalan 731 Motorola Inc. 732 1501 W Shure Drive 733 Arlington Heights,IL 60004 734 Phone: (847) 642-4031 735 Email: jayapal@cig.mot.com 737 Peter W. Wenzel 738 Nortel Networks 739 2201 Lakeside Blvd. 740 Richardson, TX 75082, USA 741 Phone: (972) 684-7134 742 Email: wenzel@nortelnetworks.com 744 Xu et al. Expires December 2000 14 745 Carey B. Becker 746 Nortel Networks 747 2201 Lakeside Blvd. 748 Richardson, TX 75082, USA 749 Phone: (972) 685-0560 750 Email: becker@nortelnetworks.com 752 James Jiang 753 Nortel Networks 754 2201 Lakeside Blvd. 755 Richardson, TX 75082, USA 756 Phone: (972)684-5885 757 Email: jjiang@nortelnetworks.com 759 Shota Shikano 760 Oki Electric Industry Co., Ltd. 761 Phone:+81-3-3454-2111 762 Email: shikano471@oki.co.jp 764 Woojune Kim 765 Samsung Electronics Ltd. 766 11th Fl, Samsung Plaza Bldg, 767 263, Seohyeon-dong, Pundang-gu, 768 Sungnam-shi, Kyunggi-do, 769 463-050 Pundang P.O. Box 32, Korea 770 Phone: +82-342-779-8526 771 Email: keg@telecom.samsung.co.kr 773 Yong Chang 774 Samsung Electronics Ltd. 775 11th Fl, Samsung Plaza Bldg, 776 263, Seohyeon-dong, Pundang-gu, 777 Sungnam-shi, Kyunggi-do, 778 463-050 Pundang P.O. Box 32, Korea 779 Phone: +82-342-779-6822 780 Email : yong@telecom.samsung.co.kr 782 Bill Semper 783 Samsung Telecommunications 784 1130 Arapaho Rd 785 Richardson, TX 75082 786 Phone: 972-761-7996 787 Email: bsemper@telecom.samsung.com 789 Jun Mo Koo 790 SK Telecom 791 Phone: 650-568-5762 792 Email: jmkoo@sktelecom.com 794 Mark A. Lipford 795 Sprint PCS 796 8001 College Blvd. Suite 210 798 Xu et al. Expires December 2000 15 799 KSOPKZ0101 800 Overland Park, KS 66210 801 Phone: 913-664-8335 802 Email: Mlipfo01@sprintspectrum.com 804 Frederic Leroudier 805 Sprint PCS 806 8001 College Blvd. Suite 210 807 KSOPKZ0101 808 Overland Park, KS 66210 809 Phone: 913-664-8350 810 Email: FLerou01@sprintspectrum.com 812 Jim Gately 813 USWest Advanced Technologies 814 4001 Discovery Drive 815 Boulder, CO 80303 816 Phone: 303-541-6415 817 Email: jgately@uswest.com 819 Xu et al. Expires December 2000 16