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