idnits 2.17.1 draft-ietf-radius-tunnel-acct-01.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-26) 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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2139, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...This document...' == Line 12 has weird spacing: '...as, and its...' == Line 17 has weird spacing: '...and may be ...' == Line 18 has weird spacing: '...ference mater...' == Line 21 has weird spacing: '...To learn the...' == (42 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2139, updated by this document, for RFC5378 checks: 1997-04-01) -- 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 (July 1998) is 9417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '3' is mentioned on line 219, but not defined ** Obsolete normative reference: RFC 2139 (ref. '1') (Obsoleted by RFC 2866) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Updates: RFC 2139 D. Mitton 4 Category: Informational Bay Networks 5 July 1998 7 RADIUS Accounting Modifications 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 its 13 working groups. Note that other groups may also distribute working doc- 14 uments 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 material 19 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 (Europe), 24 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 January 15, 1999. Please send 28 comments to the RADIUS Working Group mailing list (ietf-radius@liv- 29 ingston.com) or to the authors (glennz@microsoft.com and dmitton@baynet- 30 works.com). 32 2. Abstract 34 This document defines a new RADIUS accounting Attribute and new values 35 for the existing Acct-Status-Type Attribute [1] designed to support the 36 provision of compulsory tunneling in dial-up networks. 38 3. Motivation 40 Many applications of tunneling protocols such as PPTP and L2TP involve 41 dial-up network access. Some, such as the provision of secure access to 42 corporate intranets via the Internet, are characterized by voluntary 43 tunneling: the tunnel is created at the request of the user for a spe- 44 cific purpose. Other applications involve compulsory tunneling: the 45 tunnel is created without any action from the user and without allowing 46 the user any choice in the matter. Examples of applications that might 47 be implemented using compulsory tunnels are Internet software upgrade 48 servers, software registration servers and banking services. These are 49 all services which, without compulsory tunneling, would probably be pro- 50 vided using dedicated networks or at least dedicated network access 51 servers (NAS), since they are characterized by the need to limit user 52 access to specific hosts. Given the existence of widespread support for 53 compulsory tunneling, however, these types of services could be accessed 54 via any Internet service provider (ISP). Typically, ISPs providing a 55 service want to collect data regarding that service, for billing, net- 56 work planning, etc. The most popular way to collect usage data in dial- 57 up networks today is by means of RADIUS Accounting. The use of RADIUS 58 Accounting allows dial-up usage data to be collected at a central loca- 59 tion, rather than stored on each NAS. It makes sense to use RADIUS 60 Accounting to collect usage data regarding compulsory tunneling, since 61 RADIUS Accounting has been widely implemented and was designed to carry 62 this type of information. In order to provide this functionality, a new 63 RADIUS attribute is needed to aid in the collation of tunnel usage data; 64 this document defines this attribute. In addition, several new values 65 for the Acct-Status-Type attribute are proposed. Specific recommenda- 66 tions for, and examples of, the application of this attribute for the 67 L2TP and PPTP protocols can be found in draft-ietf-radius-tunnel-imp- 68 XX.txt. 70 4. Specification of Requirements 72 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 73 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 74 described in [2]. 76 5. New Acct-Status-Type Values 78 5.1. Tunnel-Start 80 Value 81 9 83 Description 85 This value MAY be used to mark the establishment of a tunnel with 86 another node. If this value is used, the following attributes 87 SHOULD also be included in the Accounting-Request packet: 89 NAS-IP-Address (4) 90 Acct-Delay-Time (41) 91 Tunnel-Type (64) 92 Tunnel-Medium-Type (65) 93 Tunnel-Client-Endpoint (66) 94 Tunnel-Server-Endpoint (67) 95 Acct-Tunnel-Connection (68) 97 5.2. Tunnel-Stop 99 Value 100 10 102 Description 104 This value MAY be used to mark the destruction of a tunnel to 105 another node. If this value is used, the following attributes 106 SHOULD also be included in the Accounting-Request packet: 108 NAS-IP-Address (4) 109 Acct-Delay-Time (41) 110 Acct-Terminate-Cause (49) 111 Tunnel-Type (64) 112 Tunnel-Medium-Type (65) 113 Tunnel-Client-Endpoint (66) 114 Tunnel-Server-Endpoint (67) 115 Acct-Tunnel-Connection (68) 117 5.3. Tunnel-Reject 119 Value 120 11 122 Description 124 This value MAY be used to mark the rejection of the establishment 125 of a tunnel with another node. If this value is used, the follow- 126 ing attributes SHOULD also be included in the Accounting-Request 127 packet: 129 NAS-IP-Address (4) 130 Acct-Delay-Time (41) 131 Acct-Terminate-Cause (49) 132 Tunnel-Type (64) 133 Tunnel-Medium-Type (65) 134 Tunnel-Client-Endpoint (66) 135 Tunnel-Server-Endpoint (67) 136 Acct-Tunnel-Connection (68) 138 5.4. Tunnel-Link-Start 140 Value 141 12 143 Description 145 This value MAY be used to mark the creation of a tunnel link. If 146 this value is used, the following attributes SHOULD also be 147 included in the Accounting-Request packet: 149 NAS-IP-Address (4) 150 NAS-Port (5) 151 Acct-Delay-Time (41) 152 Tunnel-Type (64) 153 Tunnel-Medium-Type (65) 154 Tunnel-Client-Endpoint (66) 155 Tunnel-Server-Endpoint (67) 156 Acct-Tunnel-Connection (68) 158 5.5. Tunnel-Link-Stop 160 Value 161 13 163 Description 165 This value MAY be used to mark the destruction of a tunnel link. 166 If this value is used, the following attributes SHOULD also be 167 included in the Accounting-Request packet: 169 NAS-IP-Address (4) 170 NAS-Port (5) 171 Acct-Delay-Time (41) 172 Acct-Input-Octets (42) 173 Acct-Output-Octets (43) 174 Acct-Session-Id (44) 175 Acct-Session-Time (46) 176 Acct-Input-Packets (47) 177 Acct-Output-Packets (48) 178 Acct-Terminate-Cause (49) 179 Acct-Multi-Session-Id (51) 180 NAS-Port-Type (61) 181 Tunnel-Type (64) 182 Tunnel-Medium-Type (65) 183 Tunnel-Client-Endpoint (66) 184 Tunnel-Server-Endpoint (67) 185 Acct-Tunnel-Connection (68) 187 6. Attributes 189 6.1. Acct-Tunnel-Connection 191 Description 193 This Attribute indicates the identifier assigned to the session. 194 It SHOULD be included in Accounting-Request packets which contain 195 Acct-Status-Type attributes with values of either Start or Stop. 196 This attribute, along with the Tunnel-Client-Endpoint and Tunnel- 197 Server-Endpoint attributes [3], may be used to provide a means to 198 uniquely identify a tunnel session for auditing purposes. 200 A summary of the Acct-Tunnel-Connection Attribute format is shown 201 below. The fields are transmitted from left to right. 203 0 1 2 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | String ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Type 211 68 for Acct-Tunnel-Connection 213 Length 215 >= 3 217 String 218 The format of the identifier represented by the String field 219 depends upon the value of the Tunnel-Type attribute [3]. 221 7. Security Considerations 223 None (submissions welcome). 225 8. References 227 [1] Rigney, "RADIUS Accounting", RFC 2139, April 1997 229 [2] Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 230 els", RFC 2119, March 1997 232 9. Acknowledgements 234 Thanks to Bernard Aboba (aboba@internaut.com) for salient input and 235 review. 237 10. Chair's Address 239 The RADIUS Working Group can be contacted via the current chair: 241 Carl Rigney 242 Livingston Enterprises 243 6920 Koll Center Parkway, Suite 220 244 Pleasanton, California 94566 246 Phone: +1 510 426 0770 247 E-Mail: cdr@livingston.com 249 11. Authors' Addresses 251 Questions about this memo can also be directed to: 253 Glen Zorn 254 Microsoft Corporation 255 One Microsoft Way 256 Redmond, Washington 98052 258 Phone: +1 425 703 1559 259 E-Mail: glennz@microsoft.com 261 Dave Mitton 262 Bay Networks, Inc. 263 8 Federal Street, BL8-05 264 Bilerica, MA 01821 266 Phone: +1 978 916 4570 267 E-Mail: dmitton@baynetworks.com 269 12. Expiration Date 271 This memo is filed as draft-ietf-radius-tunnel-acct-01.txt and expires 272 on January 15, 1999.