idnits 2.17.1 draft-malkin-pnsmip-00.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-24) 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1997) is 9780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft-malkin-pnsmip-00.txt G. Malkin 2 N Kossack 3 P. Raison 4 Bay Networks 5 July 1997 7 Portable Node Support 8 Using Mobile IP Protocol 10 Abstract 12 This document describes an extension to the Mobile IP protocol [1] 13 which allows portable nodes to tunnel, through a Service Provider's 14 network, to their home networks without the need to implement any 15 special code on the portable nodes. 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its Areas, 21 and its Working Groups. Note that other groups may also distribute 22 working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a "working 28 draft" or "work in progress." 30 Please check the I-D abstract listing contained in each Internet 31 Draft directory to learn the current status of this or any other 32 Internet Draft. 34 It is intended that this document will be submitted to the IESG for 35 consideration as a standards document. Distribution of this document 36 is unlimited. 38 Table of Contents 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 41 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2 Component Descriptions . . . . . . . . . . . . . . . . . . . 44 2.2 Operational Timeline . . . . . . . . . . . . . . . . . . . . 45 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 46 3.1 Authentication Request . . . . . . . . . . . . . . . . . . . 47 3.2 Authentication Response . . . . . . . . . . . . . . . . . . . 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . 49 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction 54 The basic Mobile IP protocol requires support for that protocol on 55 the Mobile Node connecting to a network. To support true mobility, 56 this is necessary. However, with a simple extension to the protocol, 57 portable nodes can be made to use the Mobile IP infrastructure 58 without the need to be "Mobile IP aware" themselves. 60 It is necessary to clearly understand the distinction between 61 "mobile" and "portable" nodes. A mobile node is one which can 62 connect to a network at any Point Of Presence (POP), roam between 63 service areas (POPs), and remain connected while roaming. A portable 64 node is one which can connect to a network at any POP, but 65 disconnects prior to moving to another POP. 67 The extension specified in this document allows a portable node, 68 which needs to have a IP address assigned by the Home Network, to 69 connect to that Home Network through a Service Providers existing 70 Mobile IP network. The nature of the extension, in fact, is the 71 process by which the portable node can get its IP address, which is a 72 value required by subsequent steps in the Mobile IP protocol. 74 2. Architecture 76 The architecture for which the Mobile IP extension has been defined 77 consists of a scenario topology, the components which comprise that 78 topology, and the protocol which operates between the components. 80 2.1 Topology 81 (((((((()))))))) {{{{{{{{}}}}}}}} 82 (( )) { } 83 (( )) { } 84 +----+ (( +-----+ +----+ )) { +-----+ +----+ } 85 | PN |====z=====| RAS |<----->| GW |===========| CPE |<->| AS | } 86 +----+ (( +-----+ +----+ )) { +-----+ +----+ } 87 (( ^ )) { } 88 (( | +-----+ )) { } 89 (( +-->| TMS | )) { } 90 (( +-----+ )) { } 91 (( )) { } 92 (( SP )) { HN } 93 (((((((()))))))) {{{{{{{{}}}}}}}} 95 2.2 Component Descriptions 97 There are six key components to the topology: the node dialing into 98 the SP, three in the SP, and two in the HN. 100 PN Portable Node 101 This is the node dialing into the SP. It does not participate 102 in the tunneling protocol or in any of the SP's protocols; it 103 requires only IP/PPP [2]. Note that this is a "portable," as 104 opposed to "mobile," node. This means that the node may connect 105 at any point, but must disconnect prior to moving. A truly 106 mobile, or "roaming," node may move from location to location 107 while remaining active. 109 RAS Remote Access Server 110 This is the dial-in edge access point to the SP. There will be 111 many such access points which may be clustered into 112 geographically diverse Points Of Presence (POPs). The RAS is 113 responsible for one end of tunnel maintenance (i.e., the Foreign 114 Agent), and for reframing packets between PPP (when 115 communicating with the PN) and GRE (when tunneling to the GW). 117 TMS Tunnel Management System 118 This contains the provisioning database which provides the RAS, 119 and through it the GW, with the information needed identify a 120 user's HN, authenticate that user within the HN, and create a 121 tunnel between the RAS and GW through which the PN's packets 122 travel. 124 GW Gateway 125 This is the dedicated edge access point to SP. It may be co- 126 located, within a POP, with RASes. The GW is responsible for 127 one end of tunnel tunnel maintenance (i.e., the Home Agent), and 128 for reframing packets between GRE (when tunneling to the RAS) 129 and whatever framing protocol is used for the connection to the 130 CPE in the HN (e.g., Frame Relay). 132 CPE Customer Premise Equipment 133 This is the SP's point of presence into the HN. The CPE is 134 merely a router; it does not participate in the tunneling 135 protocol or in any of the SP's protocols. 137 AS Authentication Server 138 This is the Authentication Server with which dial-in users are 139 authenticated to the HN. Each HN maintains its own AS and, 140 consequently, retains control over its users' access and 141 passwords. 143 2.3 Operational Timeline 145 This is the operational timeline for the establishment and teardown 146 of a tunneled, dial-in connection. The phases will be referenced 147 throughout this document. 149 PN RAS TMS GW AS host 150 1 |-con--->| | | | | 151 2 |<-LCP-->| | | | | 152 3 |-CHAP-->| | | | | 153 4 | |-infoq->| | | | 154 5 | |<-infor-| | | | 155 6 | |-MIPauthq------->| | | 156 7 | | |-authq->| | 157 8 | | |<-grant-| | 158 9 | |<-------MIPauthr-| | 159 10 | |-MIPregq-------->| | 160 11 | |<--------MIPregr-| | 161 12 |<--CHAP-| | | 162 13 |<-NCPs->| | | 163 14 |<=========open=comm=path==|================>| 164 15 |-disc-->| | 165 16 | |-MIPtermq------->| 166 17 | |<-------MIPtermr-| 168 1 The PN connects to the RAS. This may be an analog or digital 169 connection. 171 2 Standard PPP LCP negotiation occurs between the PN and the RAS. 173 3 CHAP is initiated. PAP may be used, but it is not as secure so 174 it is not recommended. 176 4 The RAS sends an Information Request to the TMS. Based on some 177 criteria (e.g., the domain part of an FQDN username), the TMS 178 determines which GW to use, the address of the AS, and the AS's 179 authentication protocol. 181 5 The TMS sends an Information Response to the RAS containing the 182 provisioned information needed to authenticate the PN with the AS 183 (see phase 4). 185 6 The RAS sends a MIP Authentication Request (see section 3.1) to 186 the GW. 188 7 The GW creates (using information supplied in the MIP Auth 189 Request) and sends an Authentication Request to the AS. The 190 Authentication Protocol (e.g., RADIUS) is also supplied in the 191 MIP Auth Request. 193 8 The AS returns a Grant to the GW. The Grant also contains the IP 194 address to be assigned to the PN during NCP. 196 9 The GW sends a MIP Authentication Response to the RAS, which 197 passes along the PN's IP address. 199 10 The RAS sends a MIP Reqistration Request to the GW to establish 200 the tunnel. 202 11 The GW sends a MIP Reqistration Response to the RAS to complete 203 tunnel establishment. 205 12 The RAS completes CHAP with the PN. 207 13 Any NCPs are now negotiated. Protocols other than IP (e.g., IPX) 208 may be carried over the same tunnel. 210 14 The communication path between the PN and any hosts in the HN is 211 now established. 213 15 The PN disconnects. This may be a graceful LCP shutdown, or the 214 RAS may detect loss of carrier. 216 16 The RAS sends a MIP Termination Request to the GW to tear down 217 the tunnel. 219 17 The GW sends a MIP Termination Response to the RAS to complete 220 tunnel teardown. 222 3. Protocol Extension 224 The protocol extension consists of an Authentication Request, sent by 225 the RAS to the GW, and an Authentication Response, sent by the GW to 226 the RAS. The formats for these packets are described below. 228 3.1 Authentication Request 230 MIP packets are UDP-based and use well-known port 434. The basic 231 format is: 233 0 8 16 24 234 +--------+--------+--------+--------+ 235 | Type | Flags | Time To Keep | 236 +--------+--------+--------+--------+ 237 | Message ID | 238 +--------+--------+--------+--------+ 239 | Identification | 240 | | 241 +--------+--------+--------+--------+ 242 | reserved | Link Auth Type | 243 +--------+--------+--------+--------+ 244 | Parameters and Options ... > 245 +--------+--------+--------+--------+ 247 Type: 249 5 (Authentication Request) 251 Flags: 253 bit 8: Access Request 254 bits 9-15: Reserved (must be zero) 256 Time To Keep: 258 The time, in seconds, the GW should retain the information 259 returned by the AS. This value should not be more than twice the 260 sum of the times for the maximum number of retries. 262 Message ID: 264 An arbitrary number used by the RAS to associate MIP 265 Authentication Responses with the appropriate Requests. 267 Identification: 269 A 64-bit number used to guard against replay attacks. This is 270 generally a timestamp. 272 User Auth Type 274 The authentication protocol used by the AS. The defined types 275 are: 277 1 (RADIUS) 279 There are 10 supported parameters and options. Each has a Type, 280 Length, Value (TLV) format. 282 3.1.1 Link Authentication Method 284 0 8 16 24 285 +--------+--------+--------+--------+ 286 | Type | Length | Value | 287 +--------+--------+--------+--------+ 289 Required: Yes 290 Type: 60 291 Length: 2 292 Value: 293 1 (PAP) 294 2 (CHAP) 296 3.1.2 Accounting Server Addresses 298 This is an ordered list of addresses of the Accounting Servers in the 299 HN. Each should be tried in turn, beginning with the first address 300 in the list. 302 0 8 16 303 +--------+--------+--------+--------+ 304 | Type | Length | Addresses > 305 +--------+--------+--------+--------+ 307 Required: No 308 Type: 63 309 Length: 4 x number of servers in list. 310 Value: List of Accounting Server IP addresses. 312 3.1.3 Authentication Server Addresses 314 This is an ordered list of addresses of the ASes in the HN. Each 315 should be tried in turn, beginning with the first address in the 316 list. 318 0 8 16 319 +--------+--------+--------+--------+ 320 | Type | Length | Addresses > 321 +--------+--------+--------+--------+ 323 Required: Yes 324 Type: 64 325 Length: 4 x number of servers in list. 326 Value: List of AS IP addresses. 328 3.1.4 User Name 330 0 8 16 331 +--------+--------+--------+--------+ 332 | Type | Length | User Name > 333 +--------+--------+--------+--------+ 335 Required: Yes 336 Type: 65 337 Length: Number of characters in the user name. 338 Value: The user name to be authenticated. 340 3.1.5 User Password 342 0 8 16 343 +--------+--------+--------+--------+ 344 | Type | Length | User Password > 345 +--------+--------+--------+--------+ 347 Required: Yes 348 Type: 66 349 Length: Number of characters in the user password. 350 Value: The user password, encrypted as specified by the 351 authentication scheme. 353 3.1.6 Authentication Password 355 This is the password required by the authentication protocol. 357 0 8 16 358 +--------+--------+--------+--------+ 359 | Type | Length | Auth Password > 360 +--------+--------+--------+--------+ 362 Required: only for CHAP 363 Type: 67 364 Length: Number of characters in the authentication password. 365 Value: 1 octet of CHAP ID copied from the Challenge Request 366 followed by the Challenge Value. 368 3.1.7 Remote Access Server IP Address 370 0 8 16 47 371 +--------+--------+-------===-------+ 372 | Type | Length | Address | 373 +--------+--------+-------===-------+ 375 Required: Yes 376 Type: 68 377 Length: 4 378 Value: IP address of RAS 380 3.1.8 Remote Access Server Port Number 382 0 8 16 47 383 +--------+--------+-------===-------+ 384 | Type | Length | Port Number | 385 +--------+--------+-------===-------+ 387 Required: Yes 388 Type: 69 389 Length: 4 390 Value: Port number on the RAS to which the user is connected. 392 3.1.9 Called-Station ID 394 0 8 16 395 +--------+--------+--------+--------+ 396 | Type | Length | String > 397 +--------+--------+--------+--------+ 399 Required: no 400 Type: 94 401 Length: Number of octets in the string. 402 Value: The phone number on which the arrived. 404 3.1.10 Calling Station ID 406 0 8 16 407 +--------+--------+--------+--------+ 408 | Type | Length | String > 409 +--------+--------+--------+--------+ 411 Required: no 412 Type: 95 413 Length: Number of octets in the string. 414 Value: The phone number of the caller. 416 3.2 Authentication Response 418 The basic packet format (see section 3.1) is the same for Request and 419 Response messages. They have different parameters and options, but 420 the headers only differ as follows: 422 Type: 424 7 (Authentication Response) 426 Flags: 428 bit 8: Must be zero 429 bit 9: Access Response 430 bits 8-15: Reserved (must be zero) 432 Code: (was reserved in the Request) 434 If the code is zero, the Authentication was accepted; otherwise, 435 one of the following reason codes will be returned: 437 32 - reason unspecified 438 33 - unsupported authentication type 439 34 - user authentication failed 440 35 - authentication server unreachable 441 36 - insufficient data to authenticate 442 37 - insufficient resources 443 38 - authentication of request message failed 444 39 - request message identification mismatch 446 3.2.1 User IP Address and Netmask 448 0 8 16 449 +--------+--------+-----------------+ 450 | Type | Length | Address/Mask > 451 +--------+--------+-----------------+ 453 Required: Yes 454 Type: 72 455 Length: 4 if address exists, 8 if netmask also exists 456 Value: IP address and netmask assigned by the AS. 458 3.2.2 User IPX Network Address 459 0 8 16 47 460 +--------+--------+-------===-------+ 461 | Type | Length | IPX Network | 462 +--------+--------+-------===-------+ 464 Required: No 465 Type: 87 466 Length: 4 467 Value: IPX network address assigned by the AS. 469 4. Security Considerations 471 This protocol extension adds no additional security risks to the 472 basic Mobile IP protocol when CHAP is used. If PAP is used, the 473 cleartext password does appear on the Service Providers network. For 474 CHAP, it is recommended that the Authentication messages be protected 475 by a cryptographic checksum (e.g., MD5); for PAP, the messages should 476 be completely encrypted. 478 5. References 480 [1] Perkins, C., "IP Mobility Support", RFC 2002, October, 1996. 482 [2] Simpson, W., "The Point-to-Point Protocol (PPP)", July, 1994. 484 Authors' Addresses 486 Gary Scott Malkin 487 Bay Networks 488 8 Federal Street 489 Billerica, MA 01821 491 Phone: (508) 916-4237 492 EMail: gmalkin@baynetworks.com 494 Paul Raisin 495 Bay Networks 496 8 Federal Street 497 Billerica, MA 01821 499 Phone: (508) 916-4284 500 EMail: praison@baynetworks.com 502 Nancy Kossack 503 Bay Networks 504 8 Federal Street 505 Billerica, MA 01821 507 Phone: (508) 916-4240 508 EMail: nkossack@baynetworks.com