idnits 2.17.1 draft-ietf-radius-tunnel-auth-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 72 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 72: '... MAY be used in both Access-...' RFC 2119 keyword, line 74: '... MUST treat unknown or u...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (42 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 November 1996) is 10007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'PPTP' on line 39 looks like a reference -- Missing reference section? 'L2TP' on line 39 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Glen Zorn 3 INTERNET-DRAFT Microsoft Corporation 4 5 25 November 1996 7 RADIUS Attributes for Tunnel Protocol Support 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires May 1, 1997. Please send com- 28 ments to the author. 30 2. Abstract 32 This document specifies a set of RADIUS attributes designed to support 33 the provision of mandatory tunneling in dial-up networks. RADIUS 34 attributes for both authorization and accounting are specified. 36 3. Introduction 38 Many of the most interesting applications of tunneling protocols such 39 as PPTP [PPTP] and L2TP [L2TP] involve dial-up network access. Some, 40 such as the provision of secure access to corporate intranets via the 41 Internet, are characterized by voluntary tunneling: the tunnel is cre- 42 ated at the request of the user for a specific purpose. Other, poten- 43 tially more compelling, applications involve compulsory tunneling: the 44 tunnel is created automatically, without any action from the user and 45 more importantly, without allowing the user any choice in the matter. 46 Examples of applications that might be implemented using compulsory 47 tunnels are Internet software upgrade servers, software registration 48 servers and banking services. These are all services which, without 49 compulsory tunneling, would probably be provided using dedicated net- 50 works or at least dedicated network access servers (NAS), since they 51 are characterized by the need to limit user access to specific hosts. 52 Given the existence of widespread support for compulsory tunneling, 53 however, these types of services could be accessed via virtually any 54 Internet service provider (ISP). The most popular means of authoriz- 55 ing dial-up network users today is through the RADIUS protocol. The 56 use of RADIUS allows the dial-up users' authorization and authentica- 57 tion data to be maintained in a central location, rather than being 58 subject to manual configuration. It makes sense to use RADIUS to cen- 59 trally administer compulsory tunneling, since RADIUS is widely 60 deployed and was designed to carry this type of information. New 61 RADIUS attributes are needed to carry the tunneling information from 62 the RADIUS server to the NAS and to transfer accounting data from the 63 NAS to the RADIUS server; this document defines those attributes. 65 4. Attributes 67 4.1. Tunnel-Type 69 Description 71 This Attribute indicates the tunneling protocol to be used. It 72 MAY be used in both Access-Request and Access-Accept packets. A 73 NAS is not required to implement all of these tunnel types, and 74 MUST treat unknown or unsupported Tunnel-Types as though an 75 Access-Reject had been received instead. 77 A summary of the Tunnel-Type Attribute format is shown below. The 78 fields are transmitted from left to right. 80 0 1 2 3 81 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 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | Type | Length | Value 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 Value (cont) | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 Type 90 64 for Tunnel-Type 92 Length 94 6 96 Value 98 The Value field is four octets. 100 1 PPTP 101 2 L2F 102 3 L2TP 104 4.2. Tunnel-Medium-Type 106 Description 108 The Tunnel-Medium-Type Attribute indicates which transport 109 medium to use when creating a tunnel for those protocols (such 110 as L2TP) that can operate over multiple transports. 112 A summary of the Tunnel-Medium-Type Attribute format is given 113 below. The fields are transmitted left to right. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type | Length | Value 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Value (cont) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Type 125 65 for Tunnel-Medium-Type 127 Length 129 6 131 Value 133 The Value field is four octets. 135 1 IP 136 2 X.25 137 3 ATM 138 4 Frame Relay 140 4.3. Tunnel-Client-Endpoint 142 Description 144 This Attribute indicates the address of the NAS end of the tun- 145 nel. 147 A summary of the Tunnel-Client-Endpoint Attribute format is shown 148 below. The fields are transmitted from left to right. 150 0 1 2 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 153 | Type | Length | String ... 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 156 Type 158 66 for Tunnel-Client-Endpoint. 160 Length 162 >= 3 164 String 165 The format of the address represented by the String field 166 depends upon the value of the Tunnel-Medium-Type attribute. 167 This attribute, along with the Tunnel-Server-Endpoint and Tun- 168 nel-ID attributes, may be used to provide a globally unique 169 means to identify a tunnel for accounting purposes. 171 4.4. Tunnel-Server-Endpoint 173 Description 175 This Attribute indicates the address of the server end of the 176 tunnel. 178 A summary of the Tunnel-Server-Endpoint Attribute format is shown 179 below. The fields are transmitted from left to right. 181 0 1 2 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 184 | Type | Length | String ... 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 187 Type 189 67 for Tunnel-Server-Endpoint. 191 Length 193 >= 3 195 String 196 The format of the address represented by the String field 197 depends upon the value of the Tunnel-Medium-Type attribute. 198 This attribute, along with the Tunnel-Client-Endpoint and Tun- 199 nel-ID attributes, may be used to provide a globally unique 200 means to identify a tunnel for accounting purposes. 202 4.5. Connection-Identifier 204 Description 206 This Attribute indicates the identifier assigned to the call. 208 A summary of the Connection-Identifier Attribute format is shown 209 below. The fields are transmitted from left to right. 211 0 1 2 212 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 214 | Type | Length | String ... 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 217 Type 219 68 for Connection-Identifier 221 Length 223 >= 3 225 String 226 The format of the identifier represented by the String field 227 depends upon the value of the Tunnel-Type attribute. This 228 attribute, along with the Tunnel-Client-Endpoint and Tunnel- 229 Server-Endpoint attributes, may be used to provide a globally 230 unique means to identify a call for accounting purposes. 232 5. Acknowledgements 234 Thanks to Gurdeep Singh Pall and Bernard Aboba of Microsoft Corpora- 235 tion, Andy Valencia of cisco Systems, and Kory Hamzeh of Ascend Commu- 236 nications for salient input and review. 238 6. Author's Address 240 Glen Zorn 241 Microsoft Corporation 242 One Microsoft Way 243 Redmond, WA 98052 245 Phone: 206-703-1559 246 EMail: glennz@microsoft.com