idnits 2.17.1 draft-ietf-radext-bigger-packets-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6613, but the abstract doesn't seem to directly say this. It does mention RFC6613 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 330 has weird spacing: '...taining maxim...' -- The document date (April 12, 2016) is 2933 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft Painless Security 4 Updates: 6613 (if approved) April 12, 2016 5 Intended status: Experimental 6 Expires: October 14, 2016 8 Larger Packets for RADIUS over TCP 9 draft-ietf-radext-bigger-packets-07.txt 11 Abstract 13 The RADIUS over TLS experiment described in RFC 6614 has opened 14 RADIUS to new use cases where the 4096-octet maximum size limit of 15 RADIUS packet proves problematic. This specification extends the 16 RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS 17 packets. This specification compliments other ongoing work to permit 18 fragmentation of RADIUS authorization information. This document 19 registers a new RADIUS code, an action which requires IESG approval. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 14, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 57 2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3 58 2.1. Status-Server Considerations . . . . . . . . . . . . . . 4 59 3. Forward and backward Compatibility . . . . . . . . . . . . . 4 60 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Protocol-Error Code . . . . . . . . . . . . . . . . . . . . . 6 63 5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Remote Authentication Dial In User Service (RADIUS) over TLS 75 [RFC6614] experiment provides strong confidentiality and integrity 76 for RADIUS [RFC2865]. This enhanced security has opened new 77 opportunities for using RADIUS to convey additional authorization 78 information. As an example, [I-D.ietf-abfab-aaa-saml] describes a 79 mechanism for using RADIUS to carry Security Assertion Markup 80 Language (SAML) messages in RADIUS. Many attributes carried in these 81 SAML messages will require confidentiality or integrity such as that 82 provided by TLS. 84 These new use cases involve carrying additional information in RADIUS 85 packets. The maximum packet length of 4096 octets is proving 86 insufficient for some SAML messages and for other structures that may 87 be carried in RADIUS. 89 One approach is to fragment a RADIUS message across multiple packets 90 at the RADIUS layer. RADIUS Fragmentation [RFC7499] provides a 91 mechanism to split authorization information across multiple RADIUS 92 messages. That mechanism is necessary in order to split 93 authorization information across existing unmodified proxies. 95 However, there are some significant disadvantages to RADIUS 96 fragmentation. First, RADIUS is a lock-step protocol, and only one 97 fragment can be in transit at a time as part of a given request. 98 Also, there is no current mechanism to discover the path Maximum 99 Transmission Unit (MTU) across the entire path that the fragment will 100 travel. As a result, fragmentation is likely both at the RADIUS 101 layer and at the transport layer. When TCP is used, much better 102 transport characteristics can be achieved by fragmentation only at 103 the TCP layer. This specification provides a mechanism to achieve 104 these better transport characteristics when TCP is used. As part of 105 this specification, a new RADIUS code is registered. 107 This specification is published as an experimental specification 108 because the TCP extensions to RADIUS are currently experimental. The 109 need for this specification arises from operational experience with 110 the TCP extensions. However, this specification introduces no new 111 experimental evaluation criteria beyond those in the base TCP 112 specification; this specification can be evaluated along with that 113 one for advancement on the standards track. 115 1.1. Requirements notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Changes to Packet Processing 123 The maximum length of a RADIUS message is increased from 4096 to 124 65535. A RADIUS Server implementing this specification MUST be able 125 to receive a RADIUS packet of maximum length. Servers MAY have a 126 maximum size over which they choose to return an error as discussed 127 in Section 5 rather than processing a received packet; this size MUST 128 be at least 4096 octets. 130 Clients implementing this specification MUST be able to receive a 131 RADIUS packet of maximum length; that is clients MUST NOT close a TCP 132 connection simply because a large packet is sent over it. Clients 133 MAY include the Response-Length attribute defined in Section 6 to 134 indicate the maximum size of a packet that they can successfully 135 process. Clients MAY silently discard a packet greater than some 136 configured size; this size MUST be at least 4096 octets. Clients 137 MUST NOT retransmit an unmodified request whose response is larger 138 than the client can process as subsequent responses will likely 139 continue to be too large. 141 Proxies MUST be able to receive a RADIUS packet of maximum length 142 without closing the TCP connection. Proxies SHOULD be able to 143 process and forward packets of maximum length. When a proxy receives 144 a request over a transport with a 4096-octet maximum length and the 145 proxy forwards that request over a transport with a larger maximum 146 length, the proxy MUST include the Response-Length attribute with a 147 value of 4096. 149 2.1. Status-Server Considerations 151 This section extends processing of Status-Server messages as 152 described in section 4.1 and 4.2 of [RFC5997]. 154 Clients implementing this specification SHOULD include the Response- 155 Length attribute in Status-Server requests. Servers are already 156 required to ignore unknown attributes received in this message. by 157 including the attribute, the client indicates how large of a response 158 it can process to its Status-Server request. It is very unlikely 159 that a response to Status-Server is greater than 4096 octets. 160 However the client also indicates support for this specification 161 which triggers server behavior below. 163 If a server implementing this specification receives a Response- 164 Length attribute in a Status-Server request, it MUST include a 165 Response-Length attribute indicating the maximum size request it can 166 process in its response to the Status-Server request. 168 3. Forward and backward Compatibility 170 An implementation of [RFC6613] will silently discard any RADIUS 171 packet larger than 4096 octets and will close the TCP connection. 172 This section provides guidelines for interoperability with these 173 implementations. These guidelines are stated at the SHOULD level. 174 In some environments support for large packets will be important 175 enough that roaming or other agreements will mandate their support. 176 In these environments, all implementations might be required to 177 support this specification removing the need for interoperability 178 with RFC 6613. It is likely that these guidelines will be relaxed to 179 the MAY level and support for this specification made a requirement 180 if RADIUS over TLS and TCP are moved to the standards track in the 181 future. 183 Clients SHOULD provide configuration for the maximum size of a 184 request sent to each server. Servers SHOULD provide configuration 185 for the maximum size of a response sent to each client. If dynamic 186 discovery mechanisms are supported, configuration SHOULD be provided 187 for the default maximum size of RADIUS packets sent to clients and 188 servers. If an implementation provides more granular configuration 189 for some classes of dynamic resources, then the implementation SHOULD 190 also provide configuration of default maximum packet sizes at the 191 same granularity. As an example, an implementation that provided 192 granular configuration for resources using a particular trust anchor 193 or belonging to a particular roaming consortium SHOULD provide 194 default packet size configuration at the same granularity. 196 If a client sends a request larger than 4096 octets and the TCP 197 connection is closed without a response, the client SHOULD treat the 198 request as if a request too big error (Section 5) specifying a 199 maximum size of 4096 is received. Clients or proxies sending 200 multiple requests over a single TCP connection without waiting for 201 responses SHOULD implement capability discovery as discussed in 202 Section 3.2. 204 By default, a server SHOULD NOT generate a response larger than 4096 205 octets. The Response-Length attribute MAY be included in a request 206 to indicate that larger responses are acceptable. Other attributes 207 or configuration MAY be used as an indicator that large responses are 208 likely to be acceptable. 210 A proxy that implements both this specification and RADIUS 211 Fragmentation [RFC7499] SHOULD use RADIUS fragmentation when the 212 following conditions are met: 214 1. A RADIUS packet is being forwarded towards a next hop whose 215 configuration does not support a packet that large. 217 2. RADIUS Fragmentation can be used for the packet in question. 219 3.1. Rationale 221 The interoperability challenge appears at first significant. This 222 specification proposes to introduce behavior where new 223 implementations will fail to function with existing implementations. 225 However, these capabilities are introduced to support new use cases. 226 If an implementation has 10000 octets of attributes to send, it 227 cannot in general trim down the response to something that can be 228 sent. Under this specification a large packet would be generated 229 that will be silently discarded by an existing implementation. 230 Without this specification, no packet is generated because the 231 required attributes cannot be sent. 233 The biggest risk to interoperability would be if requests and 234 responses are expanded to include additional information that is not 235 strictly necessary. So, avoiding creating situations where large 236 packets are sent to existing implementations is mostly an operational 237 matter. Interoperability is most impacted when the size of packets 238 in existing use cases is significantly increased and least impacted 239 when large packets are used for new use cases where the deployment is 240 likely to require updated RADIUS implementations. 242 There is a special challenge for proxies or clients with high request 243 volume. When an RFC 6613 implementation receives a packet that is 244 too large, it closes the connection and does not respond to any 245 requests in process. Such a client would lose requests and might 246 find distinguishing request-too-big situations from other failures 247 difficult. In these cases, the discovery mechanism described in 248 Section 3.2 can be used. 250 Also, RFC 6613 is an experiment. Part of running that experiment is 251 to evaluate whether additional changes are required to RADIUS. A 252 lower bar for interoperability should apply to changes to 253 experimental protocols than standard protocols. 255 This specification provides good facilities to enable implementations 256 to understand packet size when proxying to/from standards-track UDP 257 RADIUS. 259 3.2. Discovery 261 As discussed in Section 2.1, a client MAY send a Status-Server 262 message to discover whether an authentication or accounting server 263 supports this specification. The client includes a Response-Length 264 attribute; this signals the server to include a Response-Length 265 attribute indicating the maximum packet size the server can process. 266 In this one instance, Response-Length indicate the size of a request 267 that can be processed rather than a response. 269 4. Protocol-Error Code 271 This document defines a new RADIUS code, TBDCODE (IANA), called 272 Protocol-Error. This packet code may be used in response to any 273 request packet, such as Access-Request, Accounting-Request, CoA- 274 Request, or Disconnect-Request. It is a response packet sent by a 275 server to a client. The packet indicates to the client that the 276 server is unable to process the request for some reason. 278 A Protocol-Error packet MUST contain a Original-Packet-Code 279 attribute, along with an Error-Cause attribute. Other attributes MAY 280 be included if desired. The Original-Packet-Code contains the code 281 from the request that generated the protocol error so that clients 282 can disambiguate requests with different codes and the same ID. 283 Regardless of the original packet code, the RADIUS server calculates 284 the Message-Authenticator attribute as if the original packet were an 285 Access-Request packet. The identifier is copied from the original 286 request. 288 Clients processing Protocol-Error MUST ignore unknown or unexpected 289 attributes. 291 This RADIUS code is hop-by-hop. Proxies MUST NOT forward a Protocol- 292 Error packet they receive. 294 5. Too Big Response 296 When a RADIUS server receives a request that is larger than can be 297 processed, it generates a Protocol-Error response as follows: 299 The code is Protocol-Error. 301 The Response-Length attribute MUST be included and its value is 302 the maximum size of request that will be processed. 304 The Error-Cause attribute is included with a value of TOOBIGTBD. 306 The Original-Packet-Code attribute is copied from the request. 308 Clients will not typically be able to adjust and resend requests when 309 this error is received. In some cases the client can fall back to 310 RADIUS Fragmentation. In other cases this code will provide for 311 better client error reporting and will avoid retransmitting requests 312 guaranteed to fail. 314 6. IANA Considerations 316 A new RADIUS packet type code is registered in the RADIUS packet type 317 codes registry discussed in section 2.1 of RFC 3575 [RFC3575]. The 318 name is "Protocol-Error" and the code is TBDCODE. The IESG is 319 requested to approve this registration along with approving 320 publication of this document. 322 The following RADIUS attribute type values [RFC3575] are assigned. 323 The assignment rules in section 10.3 of [RFC6929] are used. 325 +----------------------+-----------+--------------------------------+ 326 | Name | Attribute | Description | 327 +----------------------+-----------+--------------------------------+ 328 | Response-Length | TBD | attribute of type "integer" | 329 | | | per Section 5 of RFC 2865 | 330 | | | containing maximum response | 331 | | | length | 332 | | | | 333 | Original-Packet-Code | TBD2 | An integer attribute | 334 | | | containing the code from a | 335 | | | packet resulting in a | 336 | | | Protocol-Error response. | 337 +----------------------+-----------+--------------------------------+ 338 The Response-Length attribute MAY be included in any RADIUS request. 339 In this context it indicates the maximum length of a response the 340 client is prepared to receive. Values are between 4096 and 65535. 341 The attribute MAY also be included in a response to a Status-Server 342 message. In this case the attribute indicates the maximum size 343 RADIUS request that is permitted. 345 A new Error-Cause value is registered in the registry at 346 http://www.iana.org/assignments/radius-types/radius- 347 types.xhtml#radius-types-18 for "Response Too Big" with value 348 TOOBIGTBD. 350 7. Security Considerations 352 This specification updates [RFC6613] and will be used with [RFC6614]. 353 When used over plain TCP, this specification creates new 354 opportunities for an on-path attacker to impact availability. These 355 attacks can be entirely mitigated by using TLS. If these attacks are 356 acceptable, then this specification can be used over TCP without TLS. 358 8. Acknowledgements 360 Sam Hartman's time on this draft was funded by JANET as part of 361 Project Moonshot. 363 Alan DeKok provided valuable review and text for the Protocol-Error 364 packet code. 366 Alejandro Perez Mendez provided valuable review comments. 368 9. References 370 9.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 376 "Remote Authentication Dial In User Service (RADIUS)", RFC 377 2865, June 2000. 379 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 380 Authentication Dial In User Service)", RFC 3575, July 381 2003. 383 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 384 Authentication Dial In User Service (RADIUS) Protocol", 385 RFC 5997, August 2010. 387 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 389 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 390 "Transport Layer Security (TLS) Encryption for RADIUS", 391 RFC 6614, May 2012. 393 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 394 Service (RADIUS) Protocol Extensions", RFC 6929, April 395 2013. 397 9.2. Informative References 399 [I-D.ietf-abfab-aaa-saml] 400 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 401 Profiles, Name Identifier Format, and Confirmation Methods 402 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 403 progress), February 2014. 405 [RFC7499] Perez-Mendez, A., Ed., Marin-Lopez, R., Pereniguez-Garcia, 406 F., Lopez-Millan, G., Lopez, D., and A. DeKok, "Support of 407 Fragmentation of RADIUS Packets", RFC 7499, DOI 10.17487/ 408 RFC7499, April 2015, 409 . 411 Author's Address 413 Sam Hartman 414 Painless Security 416 Email: hartmans-ietf@mit.edu