RFC 2867

RADIUS Accounting Modifications for Tunnel Protocol Support

📅 published June 2000, from ietf

RFC 2867 💖 RADIUS Accounting Modifications for Tunnel Protocol Support

okay bestie, this one is a whole vibe 🎀 It's an Informational RFC from June 2000, so it's not a standard, just useful info for the internet community 🌸 It's by G. Zorn (Cisco Systems, Inc.), B. Aboba (Microsoft Corporation), and D. Mitton (Nortel Networks), and it Updates RFC 2866 ✨

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 💅

okay so this doc adds new RADIUS accounting Attributes, plus new values for the existing Acct-Status-Type Attribute [1]. The whole point is to support compulsory tunneling in dial-up networks 🦋

Specification of Requirements 🧚

the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2] 🫶

1. Introduction 🌈

so, lots of tunneling protocols, like PPTP [5] and L2TP [4], are used for dial-up network access 📞 Some of them are voluntary tunneling, where the user asks for the tunnel to be made for a specific purpose, like getting secure access to corporate intranets over the Internet. Others are compulsory tunneling, where the tunnel gets created with zero action from the user and zero choice on their end, as a service from the Internet service provider (ISP) 👀

ISPs usually want to collect data about that service for billing, network planning, etc 💸 One way to collect usage data in dial-up networks is RADIUS Accounting [1]. With it, dial-up usage data gets collected at a central location, instead of being stored on each NAS 🧠✨

so to collect usage data about tunneling, we need new RADIUS attributes, and this document defines them 🎀 It also proposes several new values for the Acct-Status-Type attribute. For specific recommendations and examples of using this attribute with the L2TP protocol, check out RFC 2809 🍓

2. Implementation Notes 📝

compulsory tunneling can be part of a package of services one entity provides to another 🤝 For example, a corporation might contract with an ISP to give its employees remote intranet access through compulsory tunneling. In that case, linking RADIUS and tunnel protocols lets the ISP and the corporation sync up their accounting, so each side gets a record of the user's resource consumption. That gives the corporation a way to audit ISP bills 🕵️‍♀️💅

when auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes are usually used to uniquely identify the call. That way, the Accounting-Request sent by the NAS can be matched up with the matching Accounting-Request sent by the tunnel server 🔍

when you implement RADIUS accounting for L2TP/PPTP tunneling, the Call-Serial-Number SHOULD be used in the Acct-Tunnel-Connection attribute 🔥 In L2TP, the Call-Serial-Number is a 32-bit field, and in PPTP it's a 16-bit field. In PPTP, the combination of IP Address and Call-Serial-Number SHOULD be unique, but that's not required. Also, no method for determining the Call-Serial-Number is specified, so it could wrap around after a reboot 😭

⚠️ bestie, the 16-bit one is kinda risky. A 16-bit Call-Serial-Number can't tell a call apart from every other call over a long stretch of time 💀 Example: say the Call-Serial-Number gets assigned in order, the NAS has 96 ports that are always busy, and the average call lasts 20 minutes. Then the 16-bit number wraps in 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days 🙈

3. New Acct-Status-Type Values 🦋

3.1. Tunnel-Start

Value

9

Description

this value MAY be used to mark the establishment of a tunnel with another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet 💖

  • User-Name (1)
  • NAS-IP-Address (4)
  • Acct-Delay-Time (41)
  • Event-Timestamp (55)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)

3.2. Tunnel-Stop

Value

10

Description

this value MAY be used to mark the destruction of a tunnel to or from another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet 🌸

  • User-Name (1)
  • NAS-IP-Address (4)
  • Acct-Delay-Time (41)
  • Acct-Input-Octets (42)
  • Acct-Output-Octets (43)
  • Acct-Session-Id (44)
  • Acct-Session-Time (46)
  • Acct-Input-Packets (47)
  • Acct-Output-Packets (48)
  • Acct-Terminate-Cause (49)
  • Acct-Multi-Session-Id (51)
  • Event-Timestamp (55)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)
  • Acct-Tunnel-Packets-Lost (86)

3.3. Tunnel-Reject

Value

11

Description

this value MAY be used to mark the rejection of the establishment of a tunnel with another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet 🫶

  • User-Name (1)
  • NAS-IP-Address (4)
  • Acct-Delay-Time (41)
  • Acct-Terminate-Cause (49)
  • Event-Timestamp (55)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)

Value

12

Description

this value MAY be used to mark the creation of a tunnel link. Only some tunnel types (e.g., L2TP) support multiple links per tunnel 🧚 This Attribute is meant to mark the creation of a link inside a tunnel that carries multiple links. For example, if a mandatory tunnel were to carry M links over its lifetime, 2(M+1) RADIUS Accounting messages might be sent: one each marking the start and end of the tunnel itself, and one each for the start and end of each link inside the tunnel 🤯 If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since the presence of the Tunnel-Start Attribute will imply the start of the (only possible) link 💅

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet ✨

  • User-Name (1)
  • NAS-IP-Address (4)
  • NAS-Port (5)
  • Acct-Delay-Time (41)
  • Event-Timestamp (55)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)

Value

13

Description

this value MAY be used to mark the destruction of a tunnel link. Only some tunnel types (e.g., L2TP) support multiple links per tunnel 🌈 This Attribute is meant to mark the destruction of a link inside a tunnel that carries multiple links. For example, if a mandatory tunnel were to carry M links over its lifetime, 2(M+1) RADIUS Accounting messages might be sent: one each marking the start and end of the tunnel itself, and one each for the start and end of each link inside the tunnel. If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since the presence of the Tunnel-Stop Attribute will imply the end of the (only possible) link 🦋

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet 🍓

  • User-Name (1)
  • NAS-IP-Address (4)
  • NAS-Port (5)
  • Acct-Delay-Time (41)
  • Acct-Input-Octets (42)
  • Acct-Output-Octets (43)
  • Acct-Session-Id (44)
  • Acct-Session-Time (46)
  • Acct-Input-Packets (47)
  • Acct-Output-Packets (48)
  • Acct-Terminate-Cause (49)
  • Acct-Multi-Session-Id (51)
  • Event-Timestamp (55)
  • NAS-Port-Type (61)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)
  • Acct-Tunnel-Packets-Lost (86)

Value

14

Description

this value MAY be used to mark the rejection of the establishment of a new link in an existing tunnel. Only some tunnel types (e.g., L2TP) support multiple links per tunnel 💜 If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since in this case the Tunnel-Reject Attribute has the same meaning 🙈

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet 🎀

  • User-Name (1)
  • NAS-IP-Address (4)
  • Acct-Delay-Time (41)
  • Acct-Terminate-Cause (49)
  • Event-Timestamp (55)
  • Tunnel-Type (64)
  • Tunnel-Medium-Type (65)
  • Tunnel-Client-Endpoint (66)
  • Tunnel-Server-Endpoint (67)
  • Acct-Tunnel-Connection (68)

4. Attributes 👑

4.1. Acct-Tunnel-Connection ✨

Description

bestie, this attribute is the tunnel session ID 🦋 It SHOULD be included in Accounting-Request packets that carry an Acct-Status-Type with the value Start, Stop, or any of the values we covered above. Paired with Tunnel-Client-Endpoint and Tunnel-Server-Endpoint [3], it can help uniquely identify a tunnel session for auditing 💅

Here's the format. Fields go left to right, obviously 🌸

 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Length     |    String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

68 for Acct-Tunnel-Connection 🎀

Length

>= 3 🧚

String

The String field's format depends on the value of the Tunnel-Type attribute [3] 👑 For example, to fully identify an L2TP tunnel connection, you might encode the L2TP Tunnel ID and Call ID here 🫶 The exact encoding is up to the implementation, so no single correct recipe, iykyk 💀

4.2. Acct-Tunnel-Packets-Lost 🍓

Description

This one tracks how many packets got lost on a given link 😭 It SHOULD be included in Accounting-Request packets that carry an Acct-Status-Type with the value Tunnel-Link-Stop.

Format time, same left-to-right vibe 💖

 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     |               Lost
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Lost (cont)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

86 for Acct-Tunnel-Packets-Lost ✨

Length

6 🌈

Lost

The Lost field is 4 octets long and holds the number of packets lost on the link 💜

5. Table of Attributes 🦋

Okay, this table is your cheat sheet for which attributes can show up in Accounting-Request packets. Tunnel attributes should not show up in Accounting-Response packets, so don't go looking there 🙈

Request        #       Attribute
  0-1          64      Tunnel-Type
  0-1          65      Tunnel-Medium-Type
  0-1          66      Tunnel-Client-Endpoint
  0-1          67      Tunnel-Server-Endpoint
  0-1          68      Acct-Tunnel-Connection
  0            69      Tunnel-Password
  0-1          81      Tunnel-Private-Group-ID
  0-1          82      Tunnel-Assignment-ID
  0            83      Tunnel-Preference
  0-1          86      Acct-Tunnel-Packets-Lost

And here's what those entries mean 💅

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.

6. Security Considerations 💀

Okay, this one's a little spicy 🔥 By "sniffing" RADIUS Accounting packets, an eavesdropper might be able to do passive analysis of tunnel connections. So yeah, the packets themselves are a leak risk, periodt 😭

7. References 📚

[1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.

[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.

[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.

8. Acknowledgments 🫶

Huge thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall for the salient input and review 👑🌸

9. Authors' Addresses 💌

Questions about this memo can be sent to:

Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, Washington 98004
USA

Phone: +1 425 438 8218
FAX:   +1 425 438 1848
EMail: gwz@cisco.com


Dave Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: +1 978 288 4570
Fax:   +1 978 288 3030
EMail: dmitton@nortelnetworks.com


Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052

Phone: +1 425 936 6605
Fax:   +1 425 936 7329
EMail: aboba@internaut.com

The copyright text stays exactly as written, no cap:

Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the
Internet Society.
📦 where this page comes from