RFC 7930
Larger Packets for RADIUS over TCP
Larger Packets for RADIUS over TCP 🎀
okay bestie, let's get the title block out of the way first 💅 this is RFC 7930, an IETF doc (Internet Engineering Task Force) written by S. Hartman from Painless Security and dated August 2016. It's filed as Experimental, ISSN 2070-1721, and it updates RFC 6613 🦋 it doesn't list anything it obsoletes.
Abstract ✨
okay so RADIUS over TLS (RFC 6614) is giving the protocol a whole new life 💜 it opened the door to new use cases, but the 4096-octet max packet size is now a problem. this doc extends the RADIUS-over-TCP experiment (RFC 6613) so bigger packets are allowed 🌸 it also complements other ongoing work on fragmenting RADIUS authorization info, and it registers a new RADIUS code. registering that code needed IESG approval, so it's a big deal 👑
Status of This Memo 🌈
this one is NOT an Internet Standards Track spec, it's published so people can look at it, try it out in experimental implementations, and evaluate it 🧚 it's officially an Experimental Protocol for the Internet community. it's a product of the IETF and it reflects IETF community consensus. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that. for the latest status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7930 ✨
Copyright Notice 💖
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read them carefully because they spell out your rights and restrictions for this doc 🫶 any Code Components you pull out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Changes to Packet Processing . . . . . . . . . . . . . . . . 4
2.1. Status-Server Considerations . . . . . . . . . . . . . . 4
3. Forward and Backward Compatibility . . . . . . . . . . . . . 5
3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 7
5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 101. Introduction ✨
okay so the RADIUS-over-TLS experiment (RFC 6614) gives Remote Authentication Dial-In User Service (RADIUS) strong confidentiality and integrity on top of the base RADIUS protocol (RFC 2865) 🔥 that extra security unlocked new ways to use RADIUS for passing along extra authorization info. for example, RFC 7833 describes using RADIUS to carry Security Assertion Markup Language (SAML) messages 🦋 a lot of the attributes in those SAML messages need confidentiality or integrity, which TLS provides.
these new use cases mean stuffing more into each RADIUS packet, and the 4096-octet max packet length is just not enough anymore for some SAML messages or other structures that might ride along in RADIUS 😭
one option is to fragment a RADIUS message across several packets at the RADIUS layer. RADIUS fragmentation (RFC 7499) lets you split authorization info across multiple RADIUS messages, and that's needed if you want to split it across existing unmodified proxies 🧚 but fragmentation has some real downsides. first, RADIUS is lock-step, so only one fragment of a given request can be in transit at a time. second, there's currently no way to discover the Path Maximum Transmission Unit (PMTU) across the whole path a fragment travels. so fragmentation happens at both the RADIUS layer and the transport layer, which is messy 💀 when TCP is in use, you get much better transport behavior if you only fragment at the TCP layer, and this spec gives you a way to get that better behavior 🌸 part of the deal is registering a new RADIUS code.
this spec is Experimental because the TCP extensions to RADIUS are still experimental, and it comes from real operational experience with those extensions 🎀 it doesn't add any new experimental evaluation criteria beyond the base TCP spec, so it can be evaluated together with that one for advancement on the Standards Track ✨
1.1. Requirements Notation 🫶
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
2. Changes to Packet Processing 🦋
the max length of a RADIUS message goes up from 4096 to 65535 🎉 a RADIUS Server implementing this spec MUST be able to receive a RADIUS packet of maximum length. Servers MAY have a maximum size above which they return an error (see Section 5) instead of processing the packet, and this size MUST be at least 4096 octets.
Clients implementing this spec MUST be able to receive a RADIUS packet of maximum length, which means clients MUST NOT close a TCP connection just because a large packet came in over it 😭 Clients MAY include the Response-Length attribute defined in Section 6 to say the maximum size of a packet they can successfully process. Clients MAY silently discard a packet bigger than some configured size, and that size MUST be at least 4096 octets. Clients MUST NOT retransmit an unmodified request whose response is bigger than the client can handle, since later responses will probably be too big too 💅
Proxies MUST be able to receive a RADIUS packet of maximum length without closing the TCP connection. Proxies SHOULD be able to process and forward packets of maximum length 🌈 when a proxy gets a request over a transport with a 4096-octet max length and forwards it over a transport with a bigger max length, the proxy MUST include the Response-Length attribute with a value of 4096.
2.1. Status-Server Considerations 🔥
this section extends how Status-Server messages get processed, as described in Sections 4.1 and 4.2 of [RFC5997] ✨
Clients implementing this spec SHOULD include the Response-Length attribute in Status-Server requests. Servers already have to ignore unknown attributes in this message. by including the attribute, the client tells the server how big a response it can handle for its Status-Server request. a Status-Server response is very unlikely to be over 4096 octets 🙈 but the client is also signaling support for this spec, and that's what triggers the server behavior below.
If a server implementing this spec gets a Response-Length attribute in a Status-Server request, it MUST include a Response-Length attribute in its response to the Status-Server request, indicating the maximum size request it can process 👑
3. Forward and Backward Compatibility 💜
okay so an implementation of [RFC6613] will silently discard any RADIUS packet bigger than 4096 octets AND close the TCP connection 💀 this section gives guidelines for interoperating with those implementations. these guidelines are stated at the SHOULD level. in some environments, support for large packets matters so much that roaming or other agreements will require it, and then all implementations might need to support this spec, which means no need to interoperate with RFC 6613 at all 🎀 it's likely these guidelines get relaxed to the MAY level, and support for this spec turned into a requirement, if RADIUS over TLS and TCP move to the Standards Track in the future 🦋
Clients SHOULD provide configuration for the max size of a request sent to each server. Servers SHOULD provide configuration for the max size of a response sent to each client. If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the default max size of RADIUS packets sent to clients and servers 🧚 if an implementation gives more granular configuration for some classes of dynamic resources, it SHOULD also give default packet size configuration at that same granularity. for example, an implementation with granular config for resources using a particular trust anchor, or belonging to a particular roaming consortium, SHOULD provide default packet size config at that same granularity 🌸
If a client sends a request bigger than 4096 octets and the TCP connection gets closed without a response, the client SHOULD treat it as if a "Request Too Big" error (Section 5) specifying a max size of 4096 had been received 😭 Clients or proxies that send multiple requests over one TCP connection without waiting for responses SHOULD implement capability discovery, as discussed in Section 3.2 ✨
by default, a server SHOULD NOT generate a response bigger than 4096 octets 🙅 the Response-Length attribute MAY be included in a request to say that bigger responses are okay. other attributes or configurations MAY be used as a signal that large responses are likely to be acceptable 💖
A proxy that implements both this spec and RADIUS fragmentation [RFC7499] SHOULD use RADIUS fragmentation when both of these conditions are met:
- A RADIUS packet is being forwarded towards a next hop whose configuration does not support a packet that large.
- RADIUS fragmentation can be used for the packet in question.
3.1. Rationale 💖
okay so the interop thing is kinda a big deal at first 😭 this spec proposes behavior where new implementations won't work with existing ones. ngl that's a lot.
BUT these capabilities are introduced to support new use cases ✨ If an implementation has 10000 octets of attributes to send, it can't, in general, trim the response down to something that fits. Under this spec, a large packet gets generated and an existing implementation will silently discard it 🙈 Without this spec, no packet gets generated at all, because the required attributes can't be sent.
The biggest interop risk would be if requests and responses grew to include extra info that isn't strictly necessary. So avoiding situations where big packets get sent to existing implementations is mostly an operational matter 💅 Interop is hit hardest when the size of packets in existing use cases goes way up, and hit least when big packets show up in new use cases where the deployment will probably need updated RADIUS implementations anyway. iconic behavior, honestly.
There's a special challenge for proxies or clients with a high request volume. When an implementation of RFC 6613 gets a packet that's too large, it closes the connection and doesn't respond to any requests in process 💀 So that client loses requests and might struggle to tell "Request Too Big" situations apart from other failures. In these cases, the discovery mechanism in Section 3.2 can be used 🫶
Also, RFC 6613 is an experiment, and part of running an experiment is figuring out whether RADIUS needs more changes. So a lower bar for interoperability should apply to changes to Experimental protocols than to Standard protocols 🧚
Overall this spec gives implementations good tools to understand packet size when proxying to or from Standards Track UDP RADIUS. slay 👑
3.2. Discovery 🔍
As we talked about in Section 2.1, a client MAY send a Status-Server message to find out whether an authentication or accounting server supports this spec 🦋 The client includes a Response-Length attribute, and that tells the server to include a Response-Length attribute showing the maximum packet size it can process. In this one instance, Response-Length is about the size of a request that can be processed, not a response. plot twist 😌
4. Protocol-Error Code ✨
This document defines a new RADIUS code, 52, called Protocol-Error 💌 This code may be used in response to any request packet, like Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. It's a response packet a server sends to a client, and it tells the client the server can't process the request for some reason 🥺
A Protocol-Error packet MUST contain an Original-Packet-Code attribute, along with an Error-Cause attribute. Other attributes MAY be included if desired. The Original-Packet-Code holds the code from the request that caused the protocol error, so clients can tell apart requests that have different codes but the same ID 🎀 No matter what the original packet code was, the RADIUS Server calculates the Message-Authenticator attribute as if the original packet were an Access-Request packet. The identifier gets copied from the original request.
Clients processing Protocol-Error MUST ignore unknown or unexpected attributes. bestie, don't panic over the extras 🫠
This RADIUS code is hop by hop 🍓 Proxies MUST NOT forward a Protocol-Error packet they receive. they stop here, period 🛑
5. Too Big Response 📦
When a RADIUS Server gets a request that's larger than it can process, it generates a Protocol-Error response like this:
- The code is Protocol-Error.
- The Response-Length attribute MUST be included, and its value is the maximum size of request that will be processed.
- The Error-Cause attribute is included with a value of 601.
- The Original-Packet-Code attribute is copied from the request.
Clients typically won't be able to adjust and resend requests when this error shows up 😭 In some cases, the client can fall back to RADIUS fragmentation. In other cases, this code gives better client error reporting and avoids retransmitting requests that are guaranteed to fail. so efficient, it's giving main character 🌈
6. IANA Considerations 📝
A new RADIUS Packet Type Code is registered in the "RADIUS Packet Type Codes" registry we talked about in Section 2.1 of RFC 3575 [RFC3575]. The name is "Protocol-Error" and the code is 52 ✨
The following RADIUS attribute Type values [RFC3575] are assigned, using the assignment rules in Section 10.3 of [RFC6929] 💅
+----------------------+-----------+--------------------------------+
| Name | Attribute | Description |
+----------------------+-----------+--------------------------------+
| Response-Length | 241.3 | An attribute of type "integer" |
| | | per Section 5 of RFC 2865 |
| | | containing maximum response |
| | | length. |
| | | |
| Original-Packet-Code | 241.4 | An integer attribute |
| | | containing the code from a |
| | | packet resulting in a |
| | | Protocol-Error response. |
+----------------------+-----------+--------------------------------+The Response-Length attribute MAY be included in any RADIUS request. In that context, it shows the maximum length of a response the client is ready to receive. Values are between 4096 and 65535 🧁 The attribute MAY also be included in a response to a Status-Server message, and then it shows the maximum size RADIUS request that's permitted.
A new Error-Cause value is registered in the "Values for RADIUS Attribute 101, Error-Cause Attribute" registry at <http://www.iana.org/assignments/radius-types> for "Response Too Big" with value 601 🎀 The range of valid values for Error-Cause in that registry, originally defined in RFC 5176, is getting extended. Two new ranges are defined:
6xx fatal errors committed by a RADIUS server7xx fatal errors committed by a RADIUS client
7. Security Considerations 🚨
This specification updates [RFC6613] and will be used with [RFC6614] 🔐 When used over plain TCP, this specification creates new opportunities for an on-path attacker to impact availability. Yikes, that's a real threat. These attacks can be entirely mitigated by using TLS, so please, bestie, use TLS 🛡️ If these attacks are acceptable to you, then this specification can be used over TCP without TLS. Your call, but know what you're signing up for 💀
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
DOI 10.17487/RFC3575, July 2003,
<http://www.rfc-editor.org/info/rfc3575>.
[RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
Authentication Dial In User Service (RADIUS) Protocol",
RFC 5997, DOI 10.17487/RFC5997, August 2010,
<http://www.rfc-editor.org/info/rfc5997>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<http://www.rfc-editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<http://www.rfc-editor.org/info/rfc6614>.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929,
DOI 10.17487/RFC6929, April 2013,
<http://www.rfc-editor.org/info/rfc6929>.8.2. Informative References
[RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia,
F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of
Fragmentation of RADIUS Packets", RFC 7499,
DOI 10.17487/RFC7499, April 2015,
<http://www.rfc-editor.org/info/rfc7499>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<http://www.rfc-editor.org/info/rfc7833>.Acknowledgements 🫶
Sam Hartman's time on this document was funded by JANET as part of Project Moonshot 🌸
Alan DeKok provided valuable review and text for the Protocol-Error packet code 👑
Alejandro Perez Mendez provided valuable review comments 💜
Author's Address 💖
Sam Hartman Painless Security
Email: hartmans-ietf@mit.edu
📦 where this page comes from
- ietf: rfc7930 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms