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

Versions: 00 01 02 03 04 05 06 07 08 rfc2868                            
     Network Working Group                                        Glen Zorn
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-radius-tunnel-auth-00.txt>
     25 November 1996
     
     
     
                 RADIUS Attributes for Tunnel Protocol Support
     
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The distribution of this memo is unlimited. It is filed as <draft-ietf-
     radius-tunnel-auth-00.txt>, and expires May 1, 1997.  Please send com-
     ments to the author.
     
     
     2.  Abstract
     
     This document specifies a set of RADIUS attributes designed to support
     the provision of mandatory  tunneling  in  dial-up  networks.   RADIUS
     attributes for both authorization and accounting are specified.
     
     
     
     3.  Introduction
     
     Many  of the most interesting applications of tunneling protocols such
     as PPTP [PPTP] and L2TP [L2TP] involve dial-up network access.   Some,
     such  as the provision of secure access to corporate intranets via the
     Internet, are characterized by voluntary tunneling: the tunnel is cre-
     ated at the request of the user for a specific purpose.  Other, poten-
     tially more compelling, applications involve compulsory tunneling: the
     tunnel  is created automatically, without any action from the user and
     more importantly, without allowing the user any choice in the  matter.
     Examples  of  applications  that might be implemented using compulsory
     tunnels are Internet software upgrade servers,  software  registration
     servers  and  banking services.  These are all services which, without
     
     
     
     Zorn                                                          [Page 1]


     INTERNET-DRAFT                                        25 November 1996
     
     
     compulsory tunneling, would probably be provided using dedicated  net-
     works  or  at least dedicated network access servers (NAS), since they
     are characterized by the need to limit user access to specific  hosts.
     Given  the  existence  of widespread support for compulsory tunneling,
     however, these types of services could be accessed via  virtually  any
     Internet  service provider (ISP).  The most popular means of authoriz-
     ing dial-up network users today is through the RADIUS  protocol.   The
     use  of RADIUS allows the dial-up users' authorization and authentica-
     tion data to be maintained in a central location,  rather  than  being
     subject to manual configuration.  It makes sense to use RADIUS to cen-
     trally  administer  compulsory  tunneling,  since  RADIUS  is   widely
     deployed  and  was  designed  to  carry this type of information.  New
     RADIUS attributes are needed to carry the tunneling  information  from
     the  RADIUS server to the NAS and to transfer accounting data from the
     NAS to the RADIUS server; this document defines those attributes.
     
     
     4.  Attributes
     
     4.1.  Tunnel-Type
     
        Description
     
           This Attribute indicates the tunneling protocol to be used.   It
           MAY be used in both Access-Request and Access-Accept packets.  A
           NAS is not required to implement all of these tunnel types,  and
           MUST  treat  unknown  or  unsupported  Tunnel-Types as though an
           Access-Reject had been received instead.
     
        A summary of the Tunnel-Type Attribute format is shown below.   The
        fields are transmitted from left to right.
     
         0                   1                   2                   3
         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |             Value
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Value (cont)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
        Type
     
           64 for Tunnel-Type
     
        Length
     
           6
     
        Value
     
           The Value field is four octets.
     
            1      PPTP
     
     
     
     Zorn                                                          [Page 2]


     INTERNET-DRAFT                                        25 November 1996
     
     
            2      L2F
            3      L2TP
     
     
     4.2.  Tunnel-Medium-Type
     
        Description
     
           The   Tunnel-Medium-Type  Attribute  indicates  which  transport
           medium to use when creating a tunnel for those  protocols  (such
           as L2TP) that can operate over multiple transports.
     
        A  summary  of  the  Tunnel-Medium-Type  Attribute  format is given
        below.  The fields are transmitted left to right.
     
         0                   1                   2                   3
         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |             Value
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Value (cont)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
        Type
     
           65 for Tunnel-Medium-Type
     
        Length
     
           6
     
        Value
     
           The Value field is four octets.
     
            1      IP
            2      X.25
            3      ATM
            4      Frame Relay
     
     
     4.3.  Tunnel-Client-Endpoint
     
        Description
     
           This Attribute indicates the address of the NAS end of the  tun-
           nel.
     
        A  summary  of the Tunnel-Client-Endpoint Attribute format is shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     
     
     
     Zorn                                                          [Page 3]


     INTERNET-DRAFT                                        25 November 1996
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |     Type      |    Length     |  String ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
     
        Type
     
           66 for Tunnel-Client-Endpoint.
     
        Length
     
           >= 3
     
        String
           The format of  the  address  represented  by  the  String  field
           depends  upon  the  value  of  the Tunnel-Medium-Type attribute.
           This attribute, along with the Tunnel-Server-Endpoint  and  Tun-
           nel-ID  attributes,  may  be  used  to provide a globally unique
           means to identify a tunnel for accounting purposes.
     
     
     4.4.  Tunnel-Server-Endpoint
     
        Description
     
           This Attribute indicates the address of the server  end  of  the
           tunnel.
     
        A  summary  of the Tunnel-Server-Endpoint Attribute format is shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |     Type      |    Length     |  String ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
     
        Type
     
           67 for Tunnel-Server-Endpoint.
     
        Length
     
           >= 3
     
        String
           The format of  the  address  represented  by  the  String  field
           depends  upon  the  value  of  the Tunnel-Medium-Type attribute.
           This attribute, along with the Tunnel-Client-Endpoint  and  Tun-
           nel-ID  attributes,  may  be  used  to provide a globally unique
           means to identify a tunnel for accounting purposes.
     
     
     
     
     
     Zorn                                                          [Page 4]


     INTERNET-DRAFT                                        25 November 1996
     
     
     4.5.  Connection-Identifier
     
        Description
     
           This Attribute indicates the identifier assigned to the call.
     
        A summary of the Connection-Identifier Attribute  format  is  shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        |     Type      |    Length     |  String ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
     
     
        Type
     
           68 for Connection-Identifier
     
        Length
     
           >= 3
     
        String
           The  format  of  the  identifier represented by the String field
           depends upon the  value  of  the  Tunnel-Type  attribute.   This
           attribute,  along  with  the  Tunnel-Client-Endpoint and Tunnel-
           Server-Endpoint attributes, may be used to  provide  a  globally
           unique means to identify a call for accounting purposes.
     
     
     
     5.  Acknowledgements
     
     Thanks  to  Gurdeep Singh Pall and Bernard Aboba of Microsoft Corpora-
     tion, Andy Valencia of cisco Systems, and Kory Hamzeh of Ascend Commu-
     nications for salient input and review.
     
     
     6.  Author's Address
     
     Glen Zorn
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-703-1559
     EMail: glennz@microsoft.com
     
     
     
     
     
     
     
     
     Zorn                                                          [Page 5]