HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:58:23 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "3619e9-4dc2-350ea544" Accept-Ranges: bytes Content-Length: 19906 Connection: close Content-Type: text/plain Draft-malkin-pnsmip-00.txt G. Malkin N Kossack P. Raison Bay Networks July 1997 Portable Node Support Using Mobile IP Protocol Abstract This document describes an extension to the Mobile IP protocol [1] which allows portable nodes to tunnel, through a Service Provider's network, to their home networks without the need to implement any special code on the portable nodes. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Malkin, Raison, Kossack Expires: 30Jan98 [Page 1] Internet Draft PNS-MIP July 1997 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Component Descriptions . . . . . . . . . . . . . . . . . . . 2.2 Operational Timeline . . . . . . . . . . . . . . . . . . . . 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 3.1 Authentication Request . . . . . . . . . . . . . . . . . . . 3.2 Authentication Response . . . . . . . . . . . . . . . . . . . 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction The basic Mobile IP protocol requires support for that protocol on the Mobile Node connecting to a network. To support true mobility, this is necessary. However, with a simple extension to the protocol, portable nodes can be made to use the Mobile IP infrastructure without the need to be "Mobile IP aware" themselves. It is necessary to clearly understand the distinction between "mobile" and "portable" nodes. A mobile node is one which can connect to a network at any Point Of Presence (POP), roam between service areas (POPs), and remain connected while roaming. A portable node is one which can connect to a network at any POP, but disconnects prior to moving to another POP. The extension specified in this document allows a portable node, which needs to have a IP address assigned by the Home Network, to connect to that Home Network through a Service Providers existing Mobile IP network. The nature of the extension, in fact, is the process by which the portable node can get its IP address, which is a value required by subsequent steps in the Mobile IP protocol. Malkin, Raison, Kossack Expires: 30Jan98 [Page 2] Internet Draft PNS-MIP July 1997 2. Architecture The architecture for which the Mobile IP extension has been defined consists of a scenario topology, the components which comprise that topology, and the protocol which operates between the components. 2.1 Topology (((((((()))))))) {{{{{{{{}}}}}}}} (( )) { } (( )) { } +----+ (( +-----+ +----+ )) { +-----+ +----+ } | PN |====z=====| RAS |<----->| GW |===========| CPE |<->| AS | } +----+ (( +-----+ +----+ )) { +-----+ +----+ } (( ^ )) { } (( | +-----+ )) { } (( +-->| TMS | )) { } (( +-----+ )) { } (( )) { } (( SP )) { HN } (((((((()))))))) {{{{{{{{}}}}}}}} 2.2 Component Descriptions There are six key components to the topology: the node dialing into the SP, three in the SP, and two in the HN. PN Portable Node This is the node dialing into the SP. It does not participate in the tunneling protocol or in any of the SP's protocols; it requires only IP/PPP [2]. Note that this is a "portable," as opposed to "mobile," node. This means that the node may connect at any point, but must disconnect prior to moving. A truly mobile, or "roaming," node may move from location to location while remaining active. RAS Remote Access Server This is the dial-in edge access point to the SP. There will be many such access points which may be clustered into geographically diverse Points Of Presence (POPs). The RAS is responsible for one end of tunnel maintenance (i.e., the Foreign Agent), and for reframing packets between PPP (when communicating with the PN) and GRE (when tunneling to the GW). TMS Tunnel Management System This contains the provisioning database which provides the RAS, and through it the GW, with the information needed identify a user's HN, authenticate that user within the HN, and create a tunnel between the RAS and GW through which the PN's packets Malkin, Raison, Kossack Expires: 30Jan98 [Page 3] Internet Draft PNS-MIP July 1997 travel. GW Gateway This is the dedicated edge access point to SP. It may be co- located, within a POP, with RASes. The GW is responsible for one end of tunnel tunnel maintenance (i.e., the Home Agent), and for reframing packets between GRE (when tunneling to the RAS) and whatever framing protocol is used for the connection to the CPE in the HN (e.g., Frame Relay). CPE Customer Premise Equipment This is the SP's point of presence into the HN. The CPE is merely a router; it does not participate in the tunneling protocol or in any of the SP's protocols. AS Authentication Server This is the Authentication Server with which dial-in users are authenticated to the HN. Each HN maintains its own AS and, consequently, retains control over its users' access and passwords. 2.3 Operational Timeline This is the operational timeline for the establishment and teardown of a tunneled, dial-in connection. The phases will be referenced throughout this document. PN RAS TMS GW AS host 1 |-con--->| | | | | 2 |<-LCP-->| | | | | 3 |-CHAP-->| | | | | 4 | |-infoq->| | | | 5 | |<-infor-| | | | 6 | |-MIPauthq------->| | | 7 | | |-authq->| | 8 | | |<-grant-| | 9 | |<-------MIPauthr-| | 10 | |-MIPregq-------->| | 11 | |<--------MIPregr-| | 12 |<--CHAP-| | | 13 |<-NCPs->| | | 14 |<=========open=comm=path==|================>| 15 |-disc-->| | 16 | |-MIPtermq------->| 17 | |<-------MIPtermr-| 1 The PN connects to the RAS. This may be an analog or digital connection. Malkin, Raison, Kossack Expires: 30Jan98 [Page 4] Internet Draft PNS-MIP July 1997 2 Standard PPP LCP negotiation occurs between the PN and the RAS. 3 CHAP is initiated. PAP may be used, but it is not as secure so it is not recommended. 4 The RAS sends an Information Request to the TMS. Based on some criteria (e.g., the domain part of an FQDN username), the TMS determines which GW to use, the address of the AS, and the AS's authentication protocol. 5 The TMS sends an Information Response to the RAS containing the provisioned information needed to authenticate the PN with the AS (see phase 4). 6 The RAS sends a MIP Authentication Request (see section 3.1) to the GW. 7 The GW creates (using information supplied in the MIP Auth Request) and sends an Authentication Request to the AS. The Authentication Protocol (e.g., RADIUS) is also supplied in the MIP Auth Request. 8 The AS returns a Grant to the GW. The Grant also contains the IP address to be assigned to the PN during NCP. 9 The GW sends a MIP Authentication Response to the RAS, which passes along the PN's IP address. 10 The RAS sends a MIP Reqistration Request to the GW to establish the tunnel. 11 The GW sends a MIP Reqistration Response to the RAS to complete tunnel establishment. 12 The RAS completes CHAP with the PN. 13 Any NCPs are now negotiated. Protocols other than IP (e.g., IPX) may be carried over the same tunnel. 14 The communication path between the PN and any hosts in the HN is now established. 15 The PN disconnects. This may be a graceful LCP shutdown, or the RAS may detect loss of carrier. 16 The RAS sends a MIP Termination Request to the GW to tear down the tunnel. Malkin, Raison, Kossack Expires: 30Jan98 [Page 5] Internet Draft PNS-MIP July 1997 17 The GW sends a MIP Termination Response to the RAS to complete tunnel teardown. 3. Protocol Extension The protocol extension consists of an Authentication Request, sent by the RAS to the GW, and an Authentication Response, sent by the GW to the RAS. The formats for these packets are described below. 3.1 Authentication Request MIP packets are UDP-based and use well-known port 434. The basic format is: 0 8 16 24 +--------+--------+--------+--------+ | Type | Flags | Time To Keep | +--------+--------+--------+--------+ | Message ID | +--------+--------+--------+--------+ | Identification | | | +--------+--------+--------+--------+ | reserved | Link Auth Type | +--------+--------+--------+--------+ | Parameters and Options ... > +--------+--------+--------+--------+ Type: 5 (Authentication Request) Flags: bit 8: Access Request bits 9-15: Reserved (must be zero) Time To Keep: The time, in seconds, the GW should retain the information returned by the AS. This value should not be more than twice the sum of the times for the maximum number of retries. Message ID: An arbitrary number used by the RAS to associate MIP Authentication Responses with the appropriate Requests. Malkin, Raison, Kossack Expires: 30Jan98 [Page 6] Internet Draft PNS-MIP July 1997 Identification: A 64-bit number used to guard against replay attacks. This is generally a timestamp. User Auth Type The authentication protocol used by the AS. The defined types are: 1 (RADIUS) There are 10 supported parameters and options. Each has a Type, Length, Value (TLV) format. 3.1.1 Link Authentication Method 0 8 16 24 +--------+--------+--------+--------+ | Type | Length | Value | +--------+--------+--------+--------+ Required: Yes Type: 60 Length: 2 Value: 1 (PAP) 2 (CHAP) 3.1.2 Accounting Server Addresses This is an ordered list of addresses of the Accounting Servers in the HN. Each should be tried in turn, beginning with the first address in the list. 0 8 16 +--------+--------+--------+--------+ | Type | Length | Addresses > +--------+--------+--------+--------+ Required: No Type: 63 Length: 4 x number of servers in list. Value: List of Accounting Server IP addresses. 3.1.3 Authentication Server Addresses This is an ordered list of addresses of the ASes in the HN. Each Malkin, Raison, Kossack Expires: 30Jan98 [Page 7] Internet Draft PNS-MIP July 1997 should be tried in turn, beginning with the first address in the list. 0 8 16 +--------+--------+--------+--------+ | Type | Length | Addresses > +--------+--------+--------+--------+ Required: Yes Type: 64 Length: 4 x number of servers in list. Value: List of AS IP addresses. 3.1.4 User Name 0 8 16 +--------+--------+--------+--------+ | Type | Length | User Name > +--------+--------+--------+--------+ Required: Yes Type: 65 Length: Number of characters in the user name. Value: The user name to be authenticated. 3.1.5 User Password 0 8 16 +--------+--------+--------+--------+ | Type | Length | User Password > +--------+--------+--------+--------+ Required: Yes Type: 66 Length: Number of characters in the user password. Value: The user password, encrypted as specified by the authentication scheme. 3.1.6 Authentication Password This is the password required by the authentication protocol. 0 8 16 +--------+--------+--------+--------+ | Type | Length | Auth Password > +--------+--------+--------+--------+ Required: only for CHAP Malkin, Raison, Kossack Expires: 30Jan98 [Page 8] Internet Draft PNS-MIP July 1997 Type: 67 Length: Number of characters in the authentication password. Value: 1 octet of CHAP ID copied from the Challenge Request followed by the Challenge Value. 3.1.7 Remote Access Server IP Address 0 8 16 47 +--------+--------+-------===-------+ | Type | Length | Address | +--------+--------+-------===-------+ Required: Yes Type: 68 Length: 4 Value: IP address of RAS 3.1.8 Remote Access Server Port Number 0 8 16 47 +--------+--------+-------===-------+ | Type | Length | Port Number | +--------+--------+-------===-------+ Required: Yes Type: 69 Length: 4 Value: Port number on the RAS to which the user is connected. 3.1.9 Called-Station ID 0 8 16 +--------+--------+--------+--------+ | Type | Length | String > +--------+--------+--------+--------+ Required: no Type: 94 Length: Number of octets in the string. Value: The phone number on which the arrived. 3.1.10 Calling Station ID 0 8 16 +--------+--------+--------+--------+ | Type | Length | String > +--------+--------+--------+--------+ Malkin, Raison, Kossack Expires: 30Jan98 [Page 9] Internet Draft PNS-MIP July 1997 Required: no Type: 95 Length: Number of octets in the string. Value: The phone number of the caller. 3.2 Authentication Response The basic packet format (see section 3.1) is the same for Request and Response messages. They have different parameters and options, but the headers only differ as follows: Type: 7 (Authentication Response) Flags: bit 8: Must be zero bit 9: Access Response bits 8-15: Reserved (must be zero) Code: (was reserved in the Request) If the code is zero, the Authentication was accepted; otherwise, one of the following reason codes will be returned: 32 - reason unspecified 33 - unsupported authentication type 34 - user authentication failed 35 - authentication server unreachable 36 - insufficient data to authenticate 37 - insufficient resources 38 - authentication of request message failed 39 - request message identification mismatch 3.2.1 User IP Address and Netmask 0 8 16 +--------+--------+-----------------+ | Type | Length | Address/Mask > +--------+--------+-----------------+ Required: Yes Type: 72 Length: 4 if address exists, 8 if netmask also exists Value: IP address and netmask assigned by the AS. 3.2.2 User IPX Network Address Malkin, Raison, Kossack Expires: 30Jan98 [Page 10] Internet Draft PNS-MIP July 1997 0 8 16 47 +--------+--------+-------===-------+ | Type | Length | IPX Network | +--------+--------+-------===-------+ Required: No Type: 87 Length: 4 Value: IPX network address assigned by the AS. 4. Security Considerations This protocol extension adds no additional security risks to the basic Mobile IP protocol when CHAP is used. If PAP is used, the cleartext password does appear on the Service Providers network. For CHAP, it is recommended that the Authentication messages be protected by a cryptographic checksum (e.g., MD5); for PAP, the messages should be completely encrypted. 5. References [1] Perkins, C., "IP Mobility Support", RFC 2002, October, 1996. [2] Simpson, W., "The Point-to-Point Protocol (PPP)", July, 1994. Malkin, Raison, Kossack Expires: 30Jan98 [Page 11] Internet Draft PNS-MIP July 1997 Authors' Addresses Gary Scott Malkin Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (508) 916-4237 EMail: gmalkin@baynetworks.com Paul Raisin Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (508) 916-4284 EMail: praison@baynetworks.com Nancy Kossack Bay Networks 8 Federal Street Billerica, MA 01821 Phone: (508) 916-4240 EMail: nkossack@baynetworks.com Malkin, Raison, Kossack Expires: 30Jan98 [Page 12]