[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]