idnits 2.17.1 draft-ietf-radius-tunnel-acct-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2], [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: ---------------------------------------------------------------------------- == 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 (April 1999) is 9114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2139 (ref. '1') (Obsoleted by RFC 2866) == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-06 == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-14 == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-08 Summary: 8 errors (**), 0 flaws (~~), 5 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 Nortel Networks 5 B. Aboba 6 Microsoft Corporation 7 April 1999 9 RADIUS Accounting Modifications for Tunnel Protocol Support 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 The distribution of this memo is unlimited. It is filed as , and expires October 17, 1999. Please send 33 comments to the RADIUS Working Group mailing list (ietf- 34 radius@livingston.com) or to the authors (gwz@acm.org, 35 dmitton@baynetworks.com and aboba@internaut.com). 37 Abstract 39 This document defines new RADIUS accounting Attributes and new values 40 for the existing Acct-Status-Type Attribute [1] designed to support the 41 provision of compulsory tunneling in dial-up networks. 43 Specification of Requirements 45 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 46 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 47 described in [2]. 49 1. Introduction 51 Many applications of tunneling protocols such as PPTP [5] and L2TP [4] 52 involve dial-up network access. Some, such as the provision of secure 53 access to corporate intranets via the Internet, are characterized by 54 voluntary tunneling: the tunnel is created at the request of the user 55 for a specific purpose. Other applications involve compulsory 56 tunneling: the tunnel is created without any action from the user and 57 without allowing the user any choice in the matter, as a service of the 58 Internet service provider (ISP). Typically, ISPs providing a service 59 want to collect data regarding that service for billing, network 60 planning, etc. One way to collect usage data in dial-up networks is by 61 means of RADIUS Accounting [1]. The use of RADIUS Accounting allows 62 dial-up usage data to be collected at a central location, rather than 63 stored on each NAS. 65 In order to collect usage data regarding tunneling, new RADIUS 66 attributes are needed; this document defines these attributes. In 67 addition, several new values for the Acct-Status-Type attribute are 68 proposed. Specific recommendations for, and examples of, the 69 application of this attribute for the L2TP protocol can be found in 70 draft-ietf-radius-tunnel-imp-XX.txt. 72 2. Implementation Notes 74 Compulsory tunneling may be part of a package of services provided by 75 one entity to another. For example, a corporation might contract with 76 an ISP to provide remote intranet access to its employees via compulsory 77 tunneling. In this case, the integration of RADIUS and tunnel protocols 78 allows the ISP and the corporation to synchronize their accounting 79 activities so that each side receives a record of the user's resource 80 consumption. This provides the corporation with the means to audit ISP 81 bills. 83 In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client- 84 Endpoint and Tunnel-Server-Endpoint attributes are typically used to 85 uniquely identify the call, allowing the Accounting-Request sent by the 86 NAS to be reconciled with the corresponding Accounting-Request sent by 87 the tunnel server. 89 When implementing RADIUS accounting for L2TP/PPTP tunneling, the Call- 90 Serial-Number SHOULD be used in the Acct-Tunnel-Connection attribute. 91 In L2TP, the Call-Serial-Number is a 32-bit field and in PPTP it is a 92 16-bit field. In PPTP the combination of IP Address and Call-Serial- 93 Number SHOULD be unique, but this is not required. In addition, no 94 method for determining the Call-Serial-Number is specified, which leaves 95 open the possibility of wrapping after a reboot. 97 Note that a 16-bit Call-Serial-Number is not sufficient to distinguish a 98 given call from all other calls over an extended time period. For 99 example, if the Call-Serial-Number is assigned monotonically, the NAS in 100 question has 96 ports which are continually busy and the average call is 101 of 20 minutes duration, then a 16-bit Call-Serial-Number will wrap 102 within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days. 104 3. New Acct-Status-Type Values 106 3.1. Tunnel-Start 108 Value 110 9 112 Description 114 This value MAY be used to mark the establishment of a tunnel with 115 another node. If this value is used, the following attributes 116 SHOULD also be included in the Accounting-Request packet: 118 User-Name (1) 119 NAS-IP-Address (4) 120 Acct-Delay-Time (41) 121 Event-Timestamp (55) 122 Tunnel-Type (64) 123 Tunnel-Medium-Type (65) 124 Tunnel-Client-Endpoint (66) 125 Tunnel-Server-Endpoint (67) 126 Acct-Tunnel-Connection (68) 128 3.2. Tunnel-Stop 130 Value 132 10 134 Description 136 This value MAY be used to mark the destruction of a tunnel to or 137 from another node. If this value is used, the following 138 attributes SHOULD also be included in the Accounting-Request 139 packet: 141 User-Name (1) 142 NAS-IP-Address (4) 143 Acct-Delay-Time (41) 144 Acct-Terminate-Cause (49) 145 Event-Timestamp (55) 146 Tunnel-Type (64) 147 Tunnel-Medium-Type (65) 148 Tunnel-Client-Endpoint (66) 149 Tunnel-Server-Endpoint (67) 150 Acct-Tunnel-Connection (68) 152 3.3. Tunnel-Reject 154 Value 156 11 158 Description 160 This value MAY be used to mark the rejection of the establishment 161 of a tunnel with another node. If this value is used, the 162 following attributes SHOULD also be included in the Accounting- 163 Request packet: 165 User-Name (1) 166 NAS-IP-Address (4) 167 Acct-Delay-Time (41) 168 Acct-Terminate-Cause (49) 169 Event-Timestamp (55) 170 Tunnel-Type (64) 171 Tunnel-Medium-Type (65) 172 Tunnel-Client-Endpoint (66) 173 Tunnel-Server-Endpoint (67) 174 Acct-Tunnel-Connection (68) 176 3.4. Tunnel-Link-Start 178 Value 180 12 182 Description 184 This value MAY be used to mark the creation of a tunnel link. 185 Only some tunnel types (e.g., L2TP) support multiple links per 186 tunnel. This Attribute is intended to mark the creation of a link 187 within a tunnel that carries multiple links. For example, if a 188 mandatory tunnel were to carry M links over its lifetime, 2(M+1) 189 RADIUS Accounting messages might be sent: one each marking the 190 initiation and destruction of the tunnel itself and one each for 191 the initiation and destruction of each link within the tunnel. If 192 only a single link can be carried in a given tunnel (e.g., IPsec 193 in the tunnel mode), this Attribute need not be included in 194 accounting packets, since the presence of the Tunnel-Start 195 Attribute will imply the initiation of the (only possible) link. 197 If this value is used, the following attributes SHOULD also be 198 included in the Accounting-Request packet: 200 User-Name (1) 201 NAS-IP-Address (4) 202 NAS-Port (5) 203 Acct-Delay-Time (41) 204 Event-Timestamp (55) 205 Tunnel-Type (64) 206 Tunnel-Medium-Type (65) 207 Tunnel-Client-Endpoint (66) 208 Tunnel-Server-Endpoint (67) 209 Acct-Tunnel-Connection (68) 211 3.5. Tunnel-Link-Stop 213 Value 215 13 217 Description 219 This value MAY be used to mark the destruction of a tunnel link. 220 Only some tunnel types (e.g., L2TP) support multiple links per 221 tunnel. This Attribute is intended to mark the destruction of a 222 link within a tunnel that carries multiple links. For example, if 223 a mandatory tunnel were to carry M links over its lifetime, 2(M+1) 224 RADIUS Accounting messages might be sent: one each marking the 225 initiation and destruction of the tunnel itself and one each for 226 the initiation and destruction of each link within the tunnel. If 227 only a single link can be carried in a given tunnel (e.g., IPsec 228 in the tunnel mode), this Attribute need not be included in 229 accounting packets, since the presence of the Tunnel-Stop 230 Attribute will imply the termination of the (only possible) link. 232 If this value is used, the following attributes SHOULD also be 233 included in the Accounting-Request packet: 235 User-Name (1) 236 NAS-IP-Address (4) 237 NAS-Port (5) 238 Acct-Delay-Time (41) 239 Acct-Input-Octets (42) 240 Acct-Output-Octets (43) 241 Acct-Session-Id (44) 242 Acct-Session-Time (46) 243 Acct-Input-Packets (47) 244 Acct-Output-Packets (48) 245 Acct-Terminate-Cause (49) 246 Acct-Multi-Session-Id (51) 247 Event-Timestamp (55) 248 NAS-Port-Type (61) 249 Tunnel-Type (64) 250 Tunnel-Medium-Type (65) 251 Tunnel-Client-Endpoint (66) 252 Tunnel-Server-Endpoint (67) 253 Acct-Tunnel-Connection (68) 254 Acct-Tunnel-Packets-Lost (86) 256 3.6. Tunnel-Link-Reject 258 Value 260 14 262 Description 264 This value MAY be used to mark the rejection of the establishment 265 of a new link in an existing tunnel. Only some tunnel types 266 (e.g., L2TP) support multiple links per tunnel. If only a single 267 link can be carried in a given tunnel (e.g., IPsec in the tunnel 268 mode), this Attribute need not be included in accounting packets, 269 since in this case the Tunnel-Reject Attribute has the same 270 meaning. 272 If this value is used, the following attributes SHOULD also be 273 included in the Accounting-Request packet: 275 User-Name (1) 276 NAS-IP-Address (4) 277 Acct-Delay-Time (41) 278 Acct-Terminate-Cause (49) 279 Event-Timestamp (55) 280 Tunnel-Type (64) 281 Tunnel-Medium-Type (65) 282 Tunnel-Client-Endpoint (66) 283 Tunnel-Server-Endpoint (67) 284 Acct-Tunnel-Connection (68) 286 4. Attributes 288 4.1. Acct-Tunnel-Connection 290 Description 292 This Attribute indicates the identifier assigned to the tunnel 293 session. It SHOULD be included in Accounting-Request packets 294 which contain an Acct-Status-Type attribute having the value 295 Start, Stop or any of the values described above. This attribute, 296 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 297 attributes [3], may be used to provide a means to uniquely 298 identify a tunnel session for auditing purposes. 300 A summary of the Acct-Tunnel-Connection Attribute format is shown 301 below. The fields are transmitted from left to right. 303 0 1 2 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | String ... 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Type 311 68 for Acct-Tunnel-Connection 313 Length 315 >= 3 317 String 319 The format of the identifier represented by the String field 320 depends upon the value of the Tunnel-Type attribute [3]. For 321 example, to fully identify an L2TP tunnel connection, the L2TP 322 Tunnel ID and Call ID might be encoded in this field. The exact 323 encoding of this field is implementation dependent. 325 4.2. Acct-Tunnel-Packets-Lost 327 Description 329 This Attribute indicates the number of packets lost on a given 330 link. It SHOULD be included in Accounting-Request packets which 331 contain an Acct-Status-Type attribute having the value Tunnel- 332 Link-Stop. 334 A summary of the Acct-Tunnel-Packets-Lost Attribute format is shown 335 below. The fields are transmitted from left to right. 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | Lost 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Lost (cont) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Type 347 86 for Acct-Tunnel-Packets-Lost 349 Length 351 6 353 Lost 355 The Lost field is 4 octets in length and represents the number of 356 packets lost on the link. 358 5. Table of Attributes 360 The following table provides a guide to which attributes may be found in 361 Accounting-Request packets. No tunnel attributes should be found in 362 Accounting-Response packets. 364 Request # Attribute 365 0-1 64 Tunnel-Type 366 0-1 65 Tunnel-Medium-Type 367 0-1 66 Tunnel-Client-Endpoint 368 0-1 67 Tunnel-Server-Endpoint 369 0-1 68 Acct-Tunnel-Connection 370 0 69 Tunnel-Password 371 0-1 81 Tunnel-Private-Group-ID 372 0-1 82 Tunnel-Assignment-ID 373 0 83 Tunnel-Preference 374 0-1 86 Acct-Tunnel-Packets-Lost 376 The following table defines the meaning of the above table entries. 377 0 This attribute MUST NOT be present in packet. 378 0+ Zero or more instances of this attribute MAY be present in packet. 379 0-1 Zero or one instance of this attribute MAY be present in packet. 381 6. Security Considerations 383 By "sniffing" RADIUS Accounting packets, it might be possible for an 384 eavesdropper to perform a passive analysis of tunnel connections. 386 7. References 388 [1] Rigney, "RADIUS Accounting", RFC 2139, April 1997 390 [2] Bradner, "Key words for use in RFCs to Indicate Requirement 391 Levels", RFC 2119, March 1997 393 [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., "RADIUS Attributes 394 for Tunnel Protocol Support", draft-ietf-radius-tunnel-auth-06.txt 395 (work in progress), September 1998 397 [4] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., 398 Palter, B., "Layer Two Tunneling Protocol 'L2TP'", draft-ietf- 399 pppext-l2tp-14.txt (work in progress), February 1999 401 [5] Hamzeh, K., Pall, G. S., Verthein, W., Taarud, J., Little, W. A., 402 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", draft-ietf- 403 pppext-pptp-08.txt (work in progress), February 1999 405 8. Acknowledgments 407 Thanks to Aydin Edguer and Gurdeep Singh Pall for salient input and 408 review. 410 9. Authors' Addresses 412 Questions about this memo can also be directed to: 414 Glen Zorn 415 Microsoft Corporation 416 One Microsoft Way 417 Redmond, Washington 98052 419 Phone: +1 425 703 1559 420 FAX: +1 425 936 7329 421 E-Mail: gwz@acm.org 423 Dave Mitton 424 Nortel Networks 425 8 Federal Street, BL8-05 426 Bilerica, MA 01821 428 Phone: +1 978 916 4570 429 FAX: +1 978 916 4789 430 E-Mail: dmitton@nortelnetworks.com 432 Bernard Aboba 433 Microsoft Corporation 434 One Microsoft Way 435 Redmond, Washington 98052 437 Phone: +1 425 936 6605 438 FAX: +1 425 936 7329 439 E-Mail: aboba@internaut.com 441 10. Expiration Date 443 This memo is filed as draft-ietf-radius-tunnel-acct-03.txt and expires 444 on October 17, 1999.