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]