idnits 2.17.1 draft-ietf-radius-tunnel-acct-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-25) 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. 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 12 has weird spacing: '...This document...' == Line 13 has weird spacing: '...as, and its...' == Line 18 has weird spacing: '...and may be ...' == Line 19 has weird spacing: '...ference mater...' == Line 22 has weird spacing: '...To learn the...' == (41 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 (November 1997) is 9658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '3' is mentioned on line 220, but not defined ** Obsolete normative reference: RFC 2139 (ref. '1') (Obsoleted by RFC 2866) Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Updates: RFC 2139 D. Mitton 5 Category: Informational Bay Networks 6 November 1997 8 RADIUS Accounting Modifications for Tunnel Protocol Support 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working doc- 15 uments as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires May 25, 1998. Please send com- 29 ments to the RADIUS Working Group mailing list (ietf-radius@liv- 30 ingston.com) or to the authors (glennz@microsoft.com and dmitton@baynet- 31 works.com). 33 2. Abstract 35 This document defines a new RADIUS accounting Attribute and new values 36 for the existing Acct-Status-Type Attribute [1] designed to support the 37 provision of compulsory tunneling in dial-up networks. 39 3. Motivation 41 Many applications of tunneling protocols such as PPTP and L2TP involve 42 dial-up network access. Some, such as the provision of secure access to 43 corporate intranets via the Internet, are characterized by voluntary 44 tunneling: the tunnel is created at the request of the user for a spe- 45 cific purpose. Other applications involve compulsory tunneling: the 46 tunnel is created without any action from the user and without allowing 47 the user any choice in the matter. Examples of applications that might 48 be implemented using compulsory tunnels are Internet software upgrade 49 servers, software registration servers and banking services. These are 50 all services which, without compulsory tunneling, would probably be pro- 51 vided using dedicated networks or at least dedicated network access 52 servers (NAS), since they are characterized by the need to limit user 53 access to specific hosts. Given the existence of widespread support for 54 compulsory tunneling, however, these types of services could be accessed 55 via any Internet service provider (ISP). Typically, ISPs providing a 56 service want to collect data regarding that service, for billing, net- 57 work planning, etc. The most popular way to collect usage data in dial- 58 up networks today is by means of RADIUS Accounting. The use of RADIUS 59 Accounting allows dial-up usage data to be collected at a central loca- 60 tion, rather than stored on each NAS. It makes sense to use RADIUS 61 Accounting to collect usage data regarding compulsory tunneling, since 62 RADIUS Accounting has been widely implemented and was designed to carry 63 this type of information. In order to provide this functionality, a new 64 RADIUS attribute is needed to aid in the collation of tunnel usage data; 65 this document defines this attribute. In addition, several new values 66 for the Acct-Status-Type attribute are proposed. Specific recommenda- 67 tions for, and examples of, the application of this attribute for the 68 L2TP and PPTP protocols can be found in draft-ietf-radius-tunnel-imp- 69 XX.txt. 71 4. Specification of Requirements 73 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 74 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 75 described in [2]. 77 5. New Acct-Status-Type Values 79 5.1. Tunnel-Start 81 Value 82 ? 84 Description 86 This value MAY be used to mark the establishment of a tunnel with 87 another node. If this value is used, the following attributes 88 SHOULD also be included in the Accounting-Request packet: 90 NAS-IP-Address (4) 91 Acct-Delay-Time (41) 92 Tunnel-Type (64) 93 Tunnel-Medium-Type (65) 94 Tunnel-Client-Endpoint (66) 95 Tunnel-Server-Endpoint (67) 96 Acct-Tunnel-Connection (68) 98 5.2. Tunnel-Stop 100 Value 101 ? 103 Description 105 This value MAY be used to mark the destruction of a tunnel to 106 another node. If this value is used, the following attributes 107 SHOULD also be included in the Accounting-Request packet: 109 NAS-IP-Address (4) 110 Acct-Delay-Time (41) 111 Acct-Terminate-Cause (49) 112 Tunnel-Type (64) 113 Tunnel-Medium-Type (65) 114 Tunnel-Client-Endpoint (66) 115 Tunnel-Server-Endpoint (67) 116 Acct-Tunnel-Connection (68) 118 5.3. Tunnel-Reject 120 Value 121 ? 123 Description 125 This value MAY be used to mark the rejection of the establishment 126 of a tunnel with another node. If this value is used, the follow- 127 ing attributes SHOULD also be included in the Accounting-Request 128 packet: 130 NAS-IP-Address (4) 131 Acct-Delay-Time (41) 132 Acct-Terminate-Cause (49) 133 Tunnel-Type (64) 134 Tunnel-Medium-Type (65) 135 Tunnel-Client-Endpoint (66) 136 Tunnel-Server-Endpoint (67) 137 Acct-Tunnel-Connection (68) 139 5.4. Tunnel-Link-Start 141 Value 142 ? 144 Description 146 This value MAY be used to mark the creation of a tunnel link. If 147 this value is used, the following attributes SHOULD also be 148 included in the Accounting-Request packet: 150 NAS-IP-Address (4) 151 NAS-Port (5) 152 Acct-Delay-Time (41) 153 Tunnel-Type (64) 154 Tunnel-Medium-Type (65) 155 Tunnel-Client-Endpoint (66) 156 Tunnel-Server-Endpoint (67) 157 Acct-Tunnel-Connection (68) 159 5.5. Tunnel-Link-Stop 161 Value 162 ? 164 Description 166 This value MAY be used to mark the destruction of a tunnel link. 167 If this value is used, the following attributes SHOULD also be 168 included in the Accounting-Request packet: 170 NAS-IP-Address (4) 171 NAS-Port (5) 172 Acct-Delay-Time (41) 173 Acct-Input-Octets (42) 174 Acct-Output-Octets (43) 175 Acct-Session-Id (44) 176 Acct-Session-Time (46) 177 Acct-Input-Packets (47) 178 Acct-Output-Packets (48) 179 Acct-Terminate-Cause (49) 180 Acct-Multi-Session-Id (51) 181 NAS-Port-Type (61) 182 Tunnel-Type (64) 183 Tunnel-Medium-Type (65) 184 Tunnel-Client-Endpoint (66) 185 Tunnel-Server-Endpoint (67) 186 Acct-Tunnel-Connection (68) 188 6. Attributes 190 6.1. Acct-Tunnel-Connection 192 Description 194 This Attribute indicates the identifier assigned to the session. 195 It SHOULD be included in Accounting-Request packets which contain 196 Acct-Status-Type attributes with values of either Start or Stop. 197 This attribute, along with the Tunnel-Client-Endpoint and Tunnel- 198 Server-Endpoint attributes [3], may be used to provide a means to 199 uniquely identify a tunnel session for auditing purposes. 201 A summary of the Acct-Tunnel-Connection Attribute format is shown 202 below. The fields are transmitted from left to right. 204 0 1 2 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | String ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Type 212 68 for Acct-Tunnel-Connection 214 Length 216 >= 3 218 String 219 The format of the identifier represented by the String field 220 depends upon the value of the Tunnel-Type attribute [3]. 222 7. Security Considerations 224 None (submissions welcome). 226 8. References 228 [1] Rigney, "RADIUS Accounting", RFC 2139, April 1997 230 [2] Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 231 els", RFC 2119, March 1997 233 9. Acknowledgements 235 Thanks to Bernard Aboba (aboba@internaut.com) for salient input and 236 review. 238 10. Chair's Address 240 The RADIUS Working Group can be contacted via the current chair: 242 Carl Rigney 243 Livingston Enterprises 244 6920 Koll Center Parkway, Suite 220 245 Pleasanton, California 94566 247 Phone: +1 510 426 0770 248 E-Mail: cdr@livingston.com 250 11. Authors' Addresses 252 Questions about this memo can also be directed to: 254 Glen Zorn 255 Microsoft Corporation 256 One Microsoft Way 257 Redmond, Washington 98052 259 Phone: +1 206 703 1559 260 E-Mail: glennz@microsoft.com 262 Dave Mitton 263 Bay Networks, Inc. 265 E-Mail: dmitton@baynetworks.com 267 12. Expiration Date 269 This memo is filed as draft-ietf-radius-tunnel-acct-00.txt and expires 270 on May 25, 1998.