HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:58:06 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 04 Aug 1997 17:39:00 GMT ETag: "304ed0-4d87-33e613b4" Accept-Ranges: bytes Content-Length: 19847 Connection: close Content-Type: text/plain Network Working Group G. Zorn Internet-Draft Microsoft Corporation Updates: RFC 2058, RFC 2059 D. Leifer Category: Standards Track Ascend Communications John Shriver Shiva Corporation July 1997 RADIUS Attributes for Tunnel Protocol Support 11.. 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 working doc- uments 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 material 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 , and expires February 1, 1997. Please send comments to the RADIUS Working Group mailing list (ietf-radius@liv- ingston.com) or to the authors (liefer@del.com, jas@shiva.com and glennz@microsoft.com). 22.. Abstract This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. RADIUS attributes for both authorization and accounting are specified. Zorn, Leifer & Shriver [Page 1] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 33.. Motivation Many applications of tunneling protocols such as PPTP and 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 created at the request of the user for a spe- cific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and 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 compulsory tunneling, would probably be pro- vided using dedicated networks 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 any Internet service provider (ISP). The most popular means of authorizing dial-up network users today is through the RADIUS protocol. The use of RADIUS allows the dial-up users' authorization and authenti- cation data to be maintained in a central location, rather than on each NAS. It makes sense to use RADIUS to centrally administer compulsory tunneling, since RADIUS is widely deployed and was designed to carry this type of information. In order to provide this functionality, 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 accounting server; this document defines those attributes. Specific recommendations for, and examples of, the application of these attributes for the L2TP and PPTP protocols can be found in draft-ietf- radius-tunnel-imp-XX.txt. 44.. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a Zorn, Leifer & Shriver [Page 2] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 55.. Attributes Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields. 55..11.. Tunnel-Type Description This Attribute indicates the tunneling protocol(s) to be used. It MAY be included in Access-Request, Access-Accept and Accounting- Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the NAS; the RADIUS server MAY ignore the hint, however. A NAS is not required to implement any of these tunnel types; if a NAS receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the NAS MUST behave 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 | Tag | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | Zorn, Leifer & Shriver [Page 3] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Tunnel-Type Length Always 6. Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the Tag field is unused, it MUST be zero. Value The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started. 1 Point-to-Point Tunneling Protocol (PPTP) 2 Layer Two Forwarding (L2F) 3 Layer Two Tunneling Protocol (L2TP) 4 Ascend Tunnel Management Protocol (ATMP) 5 Virtual Tunneling Protocol (VTP) 6 IP Authentication Header in the Tunnel-mode (AH) 7 IP-in-IP Encapsulation (IP-IP) 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) 10 Generic Route Encapsulation (GRE) 11 Bay Dial Virtual Services (DVS) 55..22.. 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. It MAY be included in both Access-Request and Access-Accept packets; if it is present in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server as to the tunnel mediums supported by the NAS. The RADIUS server MAY ignore the hint, however. A summary of the Tunnel-Medium-Type Attribute format is given below. The fields are transmitted left to right. Zorn, Leifer & Shriver [Page 4] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 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 | Tag | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 for Tunnel-Medium-Type Length 6 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the Tag field is unused, it MUST be zero (0x0000). Value The Value field is three octets nd contains one of the following values: 1 IP 2 X.25 3 ATM 4 Frame Relay 55..33.. Acct-Tunnel-Client-Endpoint Description This Attribute contains the address of the NAS end of the tunnel. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop. This Attribute, along with the Tunnel-Server-Endpoint and Acct- Tunnel-Connection-ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing pur- poses. A summary of the Acct-Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right. Zorn, Leifer & Shriver [Page 5] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 66 for Acct-Tunnel-Client-Endpoint. Length >= 2 String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IP (1), then this string is either the fully qualified domain name, or it is a "dotted-decimal" IP address. If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4), this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use. 55..44.. Tunnel-Server-Endpoint Description This Attribute indicates the address of the server end of the tun- nel. The Tunnel-Server-Endpoint Attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if the initiation of a tunnel is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. This Attribute, along with the Acc-Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. A summary of the Tunnel-Server-Endpoint Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 Zorn, Leifer & Shriver [Page 6] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 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 | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 for Tunnel-Server-Endpoint. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the Tag field is unused, it MUST be zero (0x0000). String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IP (1), then this string is either the fully qualified domain name, or it is a "dotted-decimal" IP address. If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4), this string is a tag referring to configuration data local to the RADIUS client that describes the interface and medium-specific address to use. 55..55.. Acct-Tunnel-Connection Description This Attribute indicates the identifier assigned to the call. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop. This attribute, along with the Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes, may be used to provide a glob- ally unique means to identify a call for accounting and auditing purposes. A summary of the Acct-Tunnel-Connection Attribute format is shown below. The fields are transmitted from left to right. Zorn, Leifer & Shriver [Page 7] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 68 for Acct-Tunnel-Connection Length >= 2 String The format of the identifier represented by the String field depends upon the value of the Tunnel-Type attribute. 55..66.. Tunnel-Private-Group-ID Description This Attribute indicates the group ID for a particular tunneled session. The Tunnel-Private-Group-ID Attribute MAY be included in the Access-Request packet if the NAS can pre-determine the group resulting from a particular connection and SHOULD be included in the Access-Reply packet if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. A summary of the Tunnel-Private-Group-ID 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 | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Zorn, Leifer & Shriver [Page 8] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 ?? for Tunnel-Private-Group-ID. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the Tag field is unused, it MUST be zero (0x0000). String This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs. 66.. Table of Attributes The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge Acct-Request # Attribute 0+ 0+ 0 0 0-1 64 Tunnel-Type 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 0 0 0 0 0-1 66 Acct-Tunnel-Client-Endpoint 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 0 0 0 0 0-1 68 Acct-Tunnel-Connection 0+ 0+ 0 0 0-1 ?? Tunnel-Private-Group-ID The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 77.. Security Considerations None (submissions welcome). 88.. Acknowledgements Thanks (in no particular order) to Kory Hamzeh (kory@ascend.com), Bertrand Buclin (Bertrand.Buclin@att.ch), Dave Mitton (dmitton@baynet- works.com), Andy Valencia (vandys@cisco.com), Bill Westfield Zorn, Leifer & Shriver [Page 9] INTERNET-DRAFT RADIUS Tunnel Attributes July 1997 (billw@cisco.com), Kris Michielsen (kmichiel@cisco.com), Gurdeep Singh Pall (gurdeep@microsoft.com), Ran Atkinson (rja@home.net) and Bernard Aboba (aboba@internaut.com) for salient input and review. 99.. Chair's Address The RAQDIUS Working Group can be contacted via the current chair: Carl Rigney Livingston Enterprises 6920 Koll Center Parkway, Suite 220 Pleasanton, California 94566 Phone: +1 510 426 0770 E-Mail: cdr@livingston.com 1100.. Author's Address Questions about this memo can also be directed to: Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052 Phone: +1 206 703 1559 E-Mail: glennz@microsoft.com Dory Leifer Ascend Communications 1678 Broadway Ann Arbor, MI 48105 Phone: +1 313 747 6152 E-Mail: leifer@ascend.com John Shriver Shiva Corporation 28 Crosby Drive Bedford, MA 01730 Phone: +1 617 270 8329 E-Mail: jas@shiva.com Zorn, Leifer & Shriver [Page 10]