idnits 2.17.1 draft-ietf-mobileip-3gwireless-ext-05.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 7) being 60 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 135 == Unused Reference: '2' is defined on line 598, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 610, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 614, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 626, 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 2356 (ref. '3') == 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. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 1700 (ref. '8') (Obsoleted by RFC 3232) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Yingchun Xu (editor) 3 Internet Draft WaterCove Networks 4 November, 2000 Rajesh Bhalla 5 Ed Campbell 6 Karl Freter 7 3Com Corporation 8 Eileen McGrath Hadwen 9 Alcatel 10 Gopal Dommety 11 Kirit Joshi 12 Cisco Systems 13 Parviz Yegani 14 Ericson Wireless Communication Inc 15 Takeo Matsumura 16 FUJITSU 17 Atsushi Teshima 18 HITACHI Ltd. 19 Lee Dong Hyun 20 HYUNDAI Electronics 21 Naoto Itoh 22 IDO Corporation 23 Kimihiro Ohki 24 KDD Corporation 25 Byung-Keun Lim 26 LG Information & Communications,Ltd 27 Peter J. McCann 28 Thomas Towle 29 Lucent Technologies 30 Jay Jayapalan 31 Motorola Inc. 32 Peter W. Wenzel 33 Carey B. Becker 34 James Jiang 35 Nortel Networks 36 Shota Shikano 37 Oki Electric Industry Co., Ltd. 38 Woojune Kim 39 Yong Chang 40 Bill Semper 41 Samsung Electronics Ltd. 42 Jun Mo Koo 43 SK Telecom 44 Mark A. Lipford 45 Frederic Leroudier 46 Sprint PCS 47 Jim Gately 48 USWest Advanced Technologies 50 Mobile IP Based Micro Mobility Management Protocol in 51 The Third Generation Wireless Network 52 54 Xu et al. Expires April 2001 1 55 Nov. 2000 57 Status of this Memo 59 This document is an Internet Draft and is in full conformance with 60 all provisions of Section 10 of RFC2026. Internet Drafts are working 61 documents of the Internet Engineering Task Force (IETF), its areas, 62 and working groups. Note that other groups may also distribute 63 working documents as Internet Drafts. 65 Internet Drafts are draft documents valid for a maximum of six 66 months and may be updated, replaced, or obsolete by other documents 67 at anytime. It is inappropriate to use Internet Drafts as reference 68 material or to cite them other than as "work in progress." 70 The list of current Internet-Drafts can be accessed at 71 http://www.ietf.org/ietf/1id-abstracts.txt. 73 The list of Internet-Draft Shadow Directories can be accessed at 74 http://www.ietf.org/shadow.html. 76 Abstract 78 This document defines extensions to the Mobile IP protocol [1] to 79 allow mobility management for the interface between a radio network 80 and a packet data network in the third generation cdma2000 network. 82 Mobile IP requires link layer connectivity between the Mobile Node 83 and the Foreign Agent. This draft proposes a protocol for achieving 84 this when the physical layer terminates at a point distant from the 85 FA. In particular, this protocol applies to cdma2000 networks where 86 the physical layer terminates at a Radio Network Node (RNN) and the 87 FA resides inside a separate Packet Data Serving Node (PDSN). The 88 PDSN is responsible for establishing, maintaining, and terminating 89 the link layer to the Mobile Node. A RNN is responsible for relaying 90 the link layer protocol between a Mobile Node and its corresponding 91 PDSN. 93 The interface between the RNN and the PDSN is called the RP 94 interface. This interface requires mobility management for handling 95 handoff from one RNN to another without interrupting end to end 96 communication. It also requires the support of the link layer 97 protocol encapsulation. 99 1. Introduction 101 This document defines extensions to the Mobile IP protocol [1] to 102 allow mobility management for the interface between a radio network 103 and a packet data network in the third generation cdma2000 network. 105 Mobile IP requires link layer connectivity between the Mobile Node 106 and the Foreign Agent. This draft proposes a protocol for achieving 108 Xu et al. Expires April 2001 2 109 Nov. 2000 111 this when the physical layer terminates at a point distant from the 112 FA. In particular, this protocol applies to cdma2000 networks where 113 the physical layer terminates at a Radio Network Node (RNN) and the 114 FA resides inside a separate Packet Data Serving Node (PDSN). The 115 PDSN is responsible for establishing, maintaining, and terminating 116 the link layer to the Mobile Node. A RNN is responsible for relaying 117 the link layer protocol between a Mobile Node and its corresponding 118 PDSN. 120 The interface between the RNN and the PDSN is called the RP 121 interface. This interface requires mobility management for handling 122 handoff from one RNN to another without interrupting end to end 123 communication. It also requires the support of the link layer 124 protocol encapsulation. 126 The messages used for mobility management across the RP interface 127 include Registration Request, Registration Reply, Registration 128 Update and Registration Acknowledge. Both Registration Request and 129 Registration Update messages MUST be sent with UDP using well-known 130 port number 699. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 134 this document are to be interpreted as described in [RFC-2119]. 136 2. Glossary 138 CDMA Code Division Multiple Access 139 FA Foreign Agent 140 HA Home Agent 141 MN Mobile Node 142 PDSN Packet Data Serving Node 143 RNN Radio Network Node 144 RP Interface between the RNN and the PDSN 146 3. cdma2000 Network RP Interface Overview 148 The high level architecture of a third generation cdma2000 network 149 RP interface is shown in Figure 1. 151 +---------+ +---------+ +---------+ 152 | | | | | | 153 | RNN |----RP------| PDSN |---------| HA | 154 | | Interface | | | | 155 +---------+ +---------+ +---------+ 156 /|\ 157 | Visited Access Home Network 158 | Provider Network 159 | 160 | 161 \|/ 162 +--------+ 164 Xu et al. Expires April 2001 3 165 Nov. 2000 167 | Mobile | 168 | Node | 169 +--------+ 171 Figure 1: The Third Generation cdma2000 Network RP Interface 173 In above figure 1, the PDSN will be responsible for establishing, 174 maintaining, and terminating the link layer to the Mobile Node. It 175 initiates the authentication, authorization, and accounting for the 176 Mobile Node and optionally, securely tunnels to the Home Agent. 178 The RNN is responsible for mapping the Mobile Node identifier 179 reference to a unique link layer identifier used to communicate with 180 the PDSN. RNN validates the Mobile Station for access service and 181 manages the physical layer connection to the Mobile Node. 183 4. Mobile IP Extensions 185 This section describes extensions to the Mobile IP protocol for the 186 RP interface within the third generation cdma2000 network. 188 4.1 Registration Request 190 In a cdma2000 network, the mobile node initiates a connection by 191 sending a call setup indication to the RNN across the radio network. 192 When this indication is received by a RNN, a Registration Request 193 will be sent from the RNN to the PDSN to setup a new RP session. 195 A RNN MUST send a Registration Request with the GRE encapsulation 196 and the reverse tunneling bit set. The Home Address field is set to 197 zero. The Home Agent field will be assigned to the IP address of the 198 PDSN and the Care-of Address field will be assigned to the IP 199 address of RNN. 201 When a Registration Request is received by a PDSN, the information 202 from the Session Specific Extension (see next section) will be used 203 to identify a RP session. When a registration is accepted, a GRE 204 tunnel will be created for this Mobile Node. 206 The message is sent with UDP using well-known port number 699. 208 The fields of the Registration Request message are shown below: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type |S|B|D|M|G|V|T| | Lifetime | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Home Address | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Home Agent | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Xu et al. Expires April 2001 4 221 Nov. 2000 223 | Care-of Address | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + Identification + 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Extensions ... 230 +-+-+-+-+-+-+-+- 232 Type 1 (Registration Request) 234 G This bit MUST be set to 1 for GRE tunneling. 236 T This bit MUST be set to 1 for reverse 237 tunneling. 239 Home Address 240 The field is set to zero. 242 Home Agent 243 This field is assigned to the IP address of the 244 PDSN. 246 Care-of Address 247 This field is assigned to the IP address of 248 RNN. 250 Extensions 251 The Session Specific Extension as described in 252 the next section MUST be included along with 253 the ones described in RFC2002. Specifically, 254 the MN-HA Authentication extension as described 255 in RFC2002 MUST be included along with this 256 extension. 258 4.2 Session Specific Extension 260 This extension is defined to carry information related to the 261 session between a Mobile Node and its serving PDSN. 263 The detailed format of the extension is shown as follows. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length | Protocol Type | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Key 271 | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Reserved | MN Connection ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Xu et al. Expires April 2001 5 277 Nov. 2000 279 | MN ID Type | MN ID Length | MN ID | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | MN ID ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type 39 (not-skippable). 286 Length This is a one octet field and it indicates the 287 length (in bytes) of the extension, NOT 288 including the Type and Length fields. 290 Protocol Type 291 This is a two octet field. It indicates the 292 type of the protocol to be tunneled across the 293 RP interface. It is same as the Protocol Type 294 field in the GRE header. 296 Key 297 This is a four octet value assigned by the RNN 298 and inserted in every GRE frame across the RP 299 interface during user data tunneling. 301 Reserved 302 This is a two octet field. It is not used and is 303 set to zero. 305 MN Connection ID 306 This is a two octet field and it is used to 307 differentiate the multiple sessions from the 308 same Mobile Node. It is locally unique to a 309 Mobile Node. 311 MN ID Type 312 This is a two octet field and it indicates the 313 type of the following Mobile Node ID value. 315 Type value 1 will be reserved for International 316 Mobile Station Identity (IMSI) encoded in ASCII 317 format. For detailed description of the IMSI, 318 see reference [8]. 320 MN ID Length 321 This is a one octet field and it indicates the 322 length (in bytes) of the following Mobile Node 323 ID field. For IMSI MN ID encoded in ASCII 324 format, the length field value ranges from 10 325 to 15 bytes. 327 MN ID 328 This is the Mobile Node ID, which is globally 329 unique. It is used to uniquely identify a Mobile 330 Node. 332 Xu et al. Expires April 2001 6 333 Nov. 2000 335 For Type 1 MN ID, the most significant digit of 336 IMSI will be coded in ASCII and stored as the 337 most significant byte of the MN ID. 339 This extension MUST be included in the Registration Request, 340 Registration Reply, Registration Update and Registration Acknowledge 341 (see section 4.5) messages. It will be included before the MN-HA 342 Authentication extension in the Registration Request and 343 Registration Reply messages and before the Registration Update 344 Authentication Extension in the Registration Update and Registration 345 Acknowledge messages. 347 The MN ID and the MN Connection ID together will uniquely identify a 348 Mobile Session. 350 4.3 Registration Reply 352 The Registration Reply will be sent by a PDSN following the 353 procedure as described in [1]. The Home Address field will be the 354 same value as the Home Address field from the corresponding 355 Registration Request message received by the PDSN. 357 The message is sent with UDP to the source port of the received 358 Registration Request message. 360 4.4 Registration Update/Acknowledge 362 Two new messages are defined to support PDSN initiated RP tunnel 363 tear down and to speed up resource reclamation on the RNN. 365 The Registration Update message is used for notification of the 366 change of the registration associated with a call. It shall be sent 367 by the PDSN to the previous RNN when a RNN to RNN handoff happens. 369 The Registration Update message is sent with UDP using well-known 370 port number 699. And the Registration Acknowledge message is sent 371 with UDP to the source port from the received correspondent 372 Registration Update message. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Reserved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Home Address | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Home Agent Address | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 + Identification + 386 Xu et al. Expires April 2001 7 387 Nov. 2000 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Extensions ... 392 +-+-+-+-+-+-+-+- 394 The format of the Registration Update message is illustrated above, 395 and contains the following fields: 397 Type 20 399 Reserved Sent as 0; ignored on reception. 401 Home Address Sent as 0; 403 Home Agent Address 404 The IP Address of the PDSN. 406 Identification 407 A 64-bit number assigned by the node sending 408 the Registration Update message. It is used to 409 assist in matching requests with replies, and 410 in protecting against replay attacks. 411 Extensions 412 Both Registration Update Authentication 413 Extension (see section 4.6) and Session 414 Specific Extension (see section 4.2) SHALL be 415 included. 417 A Registration Update shall be sent by a PDSN to indicate the 418 closure of a RP session. The RNN may reclaim the resource associated 419 with that session. 421 A Registration Acknowledge message is used to acknowledge receipt of 422 a Registration Update message. It MUST be sent by a node receiving a 423 Registration Update message. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type | Status | Reserved | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Home Address | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Care Of Address | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 + Identification + 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Extensions ... 439 +-+-+-+-+-+-+-+- 441 Xu et al. Expires April 2001 8 442 Nov. 2000 444 The format of the Registration Acknowledge message is illustrated 445 above, and contains the following fields: 447 Type 21 449 Status If the Status is nonzero, this acknowledgment is 450 negative. 452 Reserved 453 Sent as 0; ignored on reception. 455 Home Address 456 Copied from the Registration Update message 457 being acknowledged. 459 Care of Address 460 The IP address of the RNN. 462 Identification 463 Copied from the Registration Update message 464 being acknowledged. 466 Extensions 467 Both Registration Update Authentication 468 Extension (see section 4.6) and Session 469 Specific Extension (see section 4.2) SHALL be 470 included. 472 Allowable values for the Status include: 474 0 successful acknowledgement 475 128 reason unspecified 476 129 administratively prohibited 477 131 sending node failed authentication 478 133 identification mismatch 479 134 poorly formed Registration Update 481 4.5 Registration Update Authentication Extension 483 The Registration Update Authentication extension is used to 484 authenticate the Registration Update and Registration Acknowledge 485 messages. It has the same format and default algorithm support 486 requirements as the authentication extension defined for Mobile IP 487 protocol [1], but with a different type (40). The authenticator 488 value is computed from the stream of bytes including the shared 489 secret, the UDP payload all prior extensions in their entirety, and 490 the type and length of this extension, but not including the 491 authenticator field itself nor the UDP header. The secret used for 492 computing the authenticator field is shared between the RN and PDSN. 493 This extension is required in both Registration Update and 494 Registration Acknowledge messages. 496 Xu et al. Expires April 2001 9 497 Nov. 2000 499 4.6 Summary 501 The extensions to Mobile IP include enabling the GRE encapsulation 502 and reverse tunneling during Registration. A new extension called 503 Session Specific Extension is defined and is mandatory in the 504 Registration Request, Registration Reply, Registration Update and 505 Registration Acknowledge messages. The Home Address field MUST be 506 set to zero in the Registration Request, Registration Reply, 507 Registration Update and Registration Acknowledge messages. 509 Two new messages (Registration Update and Registration Acknowledge) 510 are defined to support the RP session disconnection in order to 511 speed up resource reclamation. 513 5.0 GRE Encapsulation 515 GRE encapsulation as described in [3] shall be supported during user 516 data transmission. A new protocol type might be required to support 517 the link layer protocol defined for the third generation cdma2000 518 network. The Key field shall be required and its value shall be same 519 as the one from the Session Specific Extension as described above. 520 The sequence number may be required, depending on the requirement of 521 the protocol encapsulated within the GRE frame. 523 During traffic tunneling, the sender will insert the Key value from 524 the Registration Request message into the Key field of the GRE 525 header. The receiver will use the Key value from the GRE header to 526 decide where to forward the user data. 528 6.0 IANA Considerations 530 This document specifies two new messages and two new extensions to 531 Mobile IP protocol [1]. The numbers to be assigned to these messages 532 and extensions have been taken from the numbering space assigned to 533 Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4]. 535 The Registration Request and Registration Update messages MUST be 536 sent with UDP using well-known port number 699. This port number is 537 chosen from the unassigned port range as specified in RFC1700 [9]. 539 The Registration Update and Registration Acknowledge messages 540 defined in section 4.4 MUST be assigned the Type values of 20 and 21 541 respectively. 543 The Session Specific Extension defined in section 4.2 MUST be 544 assigned the Type value of 39, and the Registration Update 545 Authentication Extension defined in section 4.5 MUST be assigned a 546 value of 40. The Status values defined in section 4.4 are the error 547 codes defined in RFC 2002 [1]. They correspond to the error values 548 conventionally associated with a rejection by a home agent (i.e., 550 Xu et al. Expires April 2001 10 551 Nov. 2000 553 the values from the range 128-255). The IANA MUST record the Status 554 values as defined in section 4.4 of this document. 556 With these assignments, the Type values assigned to the two new 557 messages and to two new extensions, and the error values for the 558 Status field, have been identified as not conflicting with any 559 numbers defined for Mobile IP to date and documented at 560 http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 562 7.0 Security Considerations 564 The protocol presented in this draft is designed for use over a 565 protected, private network between RNN and PDSN. Pre-arranged 566 security associations in the style of Mobile IPv4 are assumed to 567 exist among every (RNN, PDSN) pair that will form an RP connection. 568 Also, it is assumed that the session specific information is 569 authenticated by means outside the scope of this draft. 571 Several potential vulnerabilities exist if these assumptions are not 572 met. First, if the network connecting the RNN and PDSN is accessible 573 to an attacker, user traffic may be intercepted and/or spoofed if 574 there are no other end-to-end security mechanisms in place. Second, 575 the Mobile IP control messages must be authenticated, to prevent 576 tunnel setup and tear down by unauthorized parties. Mobile IP 577 Authentication Extensions are used to provide this additional 578 protection for control messages. Finally, if session specific 579 information is not authenticated, a denial-of-service attack is 580 possible if a RNN unknowingly sends a registration request to the 581 PDSN with a spoofed session specific extension. The PDSN would then 582 send an explicit tunnel tear down to the previous RNN, causing user 583 traffic to be misdirected to the new RNN. This would cause a loss of 584 service and possibly interception of traffic, depending on what 585 other security measures are in place. 587 8.0 Acknowledgments 589 The authors of this draft would like to thank Charles E. Perkins and 590 David B. Johnson for the ideas presented in the Route Optimization 591 draft [7]. 593 References 595 [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 596 1996. 598 [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 599 1998. 601 Xu et al. Expires April 2001 11 602 Nov. 2000 604 [3] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for 605 Mobile IP". RFC 2356, June 1998. 607 [4] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network 608 Address Identifier Extension". RFC2794, March 2000. 610 [5] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ 611 Response Extensions". draft-ietf-mobileip-challenge-06.txt, 612 October 1999. (work in progress). 614 [6] Charles E. Perkins and David B. Johnson. "Route Optimization in 615 Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. 616 (work in progress). 618 [7] TIA/EIA/IS-95-B 620 [8] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October 621 1994. 623 [9] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P., 624 "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. 626 [10] Gopal Dommety. "Key and Sequence Number Extensions to GRE". 627 RFC2890, September 2000. 629 Author's Addresses 631 Yingchun Xu 632 WaterCove Networks 633 285 Billerica Road 634 Chelmsford, MA, 635 USA 01824 636 Phone: (847) 477-9280 637 Email: yxu@watercove.com 639 Rajesh Bhalla 640 3Com Corporation 641 1800 West Central Road 642 Mount Prospect, 643 USA 60056 644 Phone: (847) 797-2618 645 Email: rajesh_bhalla@3com.com 647 Karl Freter 648 3Com Corporation 649 1800 W. Central Road 650 Mount Prospect, IL 60056 651 Phone: (847) 222-2268 652 Email: karl_freter@3com.com 654 Xu et al. Expires April 2001 12 655 Nov. 2000 657 Ed Campbell 658 3Com Corporation 659 1800 W. Central Road 660 Mount Prospect, IL 60056 661 Phone:(847) 342-6769 662 Email: ed_campbell@3com.com 664 Eileen McGrath Hadwen 665 Alcatel 666 PO Box 4442, 667 Boulder CO 80306 668 Phone: 303 499 1496 669 Email: mcgrath.hadwen@worldnet.att.net 671 Gopal Dommety 672 Cisco Systems 673 170 West Tasman Drive 674 San Jose, CA 95134 675 Phone: (408) 525-1404 676 Email: gdommety@cisco.com 678 Kirit Joshi 679 Cisco Systems 680 170 West Tasman Drive 681 San Jose, CA 95134 682 Phone: (408) 525 7367 683 Email: kjoshi@cisco.com 685 Parviz Yegani 686 Ericson Wireless Communication Inc. 687 6455 Lusk Blvd. 688 San Diego, CA 92121 689 Phone: (858) 332-6017 690 Email: p.yeqani@ericsson.com 692 Takeo Matsumura 693 FUJITSU 694 Kamiodanaka 695 Nakahara-ku, Kawasaki-City 696 Phone: +81-44-740-8109 697 Email: matumura@mcs.ts.fujitsu.co.jp 699 Atsushi Teshima 700 HITACHI Ltd. 701 216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567 702 Phone:+81-45-865-7003 703 Email: atsushi_teshima@cm.tcd.hitachi.co.jp 705 Lee Dong Hyun 706 HYUNDAI Electronics Industry 707 KOREA Kyungkido Icheonsi 435-050 708 Phone: 82-336-630-2756 709 Email: jihs@hei.co.kr 711 Xu et al. Expires April 2001 13 712 Nov. 2000 714 Naoto Itoh 715 IDO Corporation 716 Gobancho YS building 717 12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361 718 Phone: +81-3-3263-9660 719 Email: nao-itoh@ido.co.jp 721 Kimihiro Ohki 722 KDD Corporation 723 3-2, Nishi-Shinjuku 2-chome, 724 Shinjuku-ku, Tokyo 163-8003, Japan 725 Phone: +81-3-3347-5477 726 Email: ki-ohki@kdd.co.jp 728 Byung-Keun Lim, 729 LG Information & Communications, Ltd. 730 533, Hogye-dong, Dongan-ku, Anyang-shi, 731 Kyungki-do,431-080, Korea 732 Phone: +82-343-450-7199 733 Email: bklim@lgic.co.kr 735 Peter J. McCann 736 Lucent Technologies 737 Rm 2Z-305 738 263 Shuman Blvd 739 Naperville, IL 60566 740 Phone: (630) 713 9359 741 EMail: mccap@lucent.com 743 Thomas Towle 744 Lucent Technologies 745 Rm. 2D-225 746 263 Shuman Blvd 747 Naperville, IL 60566 748 Phone: 630-979-7303 749 Email: ttowle@lucent.com 751 Jay Jayapalan 752 Motorola Inc. 753 1501 W Shure Drive 754 Arlington Heights,IL 60004 755 Phone: (847) 642-4031 756 Email: jayapal@cig.mot.com 758 Peter W. Wenzel 759 Nortel Networks 760 2201 Lakeside Blvd. 761 Richardson, TX 75082, USA 762 Phone: (972) 684-7134 763 Email: wenzel@nortelnetworks.com 765 Carey B. Becker 767 Xu et al. Expires April 2001 14 768 Nov. 2000 770 Nortel Networks 771 2201 Lakeside Blvd. 772 Richardson, TX 75082, USA 773 Phone: (972) 685-0560 774 Email: becker@nortelnetworks.com 776 James Jiang 777 Nortel Networks 778 2201 Lakeside Blvd. 779 Richardson, TX 75082, USA 780 Phone: (972)684-5885 781 Email: jjiang@nortelnetworks.com 783 Shota Shikano 784 Oki Electric Industry Co., Ltd. 785 Phone:+81-3-3454-2111 786 Email: shikano471@oki.co.jp 788 Woojune Kim 789 Samsung Electronics Ltd. 790 11th Fl, Samsung Plaza Bldg, 791 263, Seohyeon-dong, Pundang-gu, 792 Sungnam-shi, Kyunggi-do, 793 463-050 Pundang P.O. Box 32, Korea 794 Phone: +82-342-779-8526 795 Email: keg@telecom.samsung.co.kr 797 Yong Chang 798 Samsung Electronics Ltd. 799 11th Fl, Samsung Plaza Bldg, 800 263, Seohyeon-dong, Pundang-gu, 801 Sungnam-shi, Kyunggi-do, 802 463-050 Pundang P.O. Box 32, Korea 803 Phone: +82-342-779-6822 804 Email : yong@telecom.samsung.co.kr 806 Bill Semper 807 Samsung Telecommunications 808 1130 Arapaho Rd 809 Richardson, TX 75082 810 Phone: 972-761-7996 811 Email: bsemper@telecom.samsung.com 813 Jun Mo Koo 814 SK Telecom 815 Phone: 650-568-5762 816 Email: jmkoo@sktelecom.com 818 Mark A. Lipford 819 Sprint PCS 820 8001 College Blvd. Suite 210 821 KSOPKZ0101 822 Overland Park, KS 66210 824 Xu et al. Expires April 2001 15 825 Nov. 2000 827 Phone: 913-664-8335 828 Email: Mlipfo01@sprintspectrum.com 830 Frederic Leroudier 831 Sprint PCS 832 8001 College Blvd. Suite 210 833 KSOPKZ0101 834 Overland Park, KS 66210 835 Phone: 913-664-8350 836 Email: FLerou01@sprintspectrum.com 838 Jim Gately 839 USWest Advanced Technologies 840 4001 Discovery Drive 841 Boulder, CO 80303 842 Phone: 303-541-6415 843 Email: jgately@uswest.com 845 Xu et al. Expires April 2001 16