idnits 2.17.1 draft-ietf-radext-bigger-packets-03.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 mention this, which it should. -- The draft header indicates that this document updates RFC6614, but the abstract doesn't seem to directly say this. It does mention RFC6614 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: By default, a server SHOULD not generate a response larger than 4096 octets. The Response-Length attribute MAY be included in a request to indicate that larger responses are acceptable. Other attributes or configuration MAY be used as an indicator that large responses are likely to be acceptable. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This RADIUS code is hop-by-hop. Proxies MUST not forward a Protocol-Error packet they receive. (Using the creation date from RFC6614, updated by this document, for RFC5378 checks: 2008-06-17) -- 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 (March 6, 2015) is 3333 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-abfab-aaa-saml' is mentioned on line 392, but not defined == Missing Reference: 'I-D.ietf-radext-radius-fragmentation' is mentioned on line 398, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 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, 6614 (if approved) March 6, 2015 5 Intended status: Experimental 6 Expires: September 7, 2015 8 Larger Packets for RADIUS over TCP 9 draft-ietf-radext-bigger-packets-03.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 RADIUS packet 15 proves problematic. This specification extends the RADIUS over TCP 16 experiment (RFC 6113) to permit larger RADIUS packets. This 17 specification compliments other ongoing work to permit fragmentation 18 of RADIUS authorization information. This document registers a new 19 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 September 7, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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. References . . . . . . . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614] 75 experiment provides strong confidentiality and integrity for RADIUS 76 [RFC2865]. This enhanced security has opened new opportunities for 77 using RADIUS to convey additional authorization information. As an 78 example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using 79 RADIUS to carry Security Assertion Markup Language (SAML) messages in 80 RADIUS. Many attributes carried in these SAML messages will require 81 confidentiality or integrity such as that provided by TLS. 83 These new use cases involve carrying additional information in RADIUS 84 packets. The maximum packet length of 4096 octets is proving 85 insufficient for some SAML messages and for other structures that may 86 be carried in RADIUS. 88 One approach is to fragment a RADIUS message across multiple packets 89 at the RADIUS layer. RADIUS Fragmentation 90 [I-D.ietf-radext-radius-fragmentation] provides a mechanism to split 91 authorization information across multiple RADIUS messages. That 92 mechanism is necessary in order to split authorization information 93 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 packet of maximum length. Servers MAY have a maximum 126 size over which they choose to return an error as discussed in 127 Section 5 rather than processing a received packet; this size MUST be 128 at least 4096 octets. 130 Clients implementing this specification MUST be able to receive a 131 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 packet of maximum length without 142 cloing the TCP connection. Proxies SHOULD be able to process and 143 forward packets of maximum length. When a proxy receives a request 144 over a transport with a 4096-octet maximum length and the proxy 145 forwards that request over a transport with a larger maximum length, 146 the proxy MUST include the Response-Length attribute with a value of 147 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 packet 171 larger than 4096 octets and will close the TCP connection. This 172 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 maximum size of clients and servers in each dynamic discovery 188 category. 190 If a client sends a request larger than 4096 octets and the TCP 191 connection is closed without a response, the client SHOULD treat the 192 request as if a request too big error (Section 5) specifying a 193 maximum size of 4096 is received. Clients or proxies sending 194 multiple requests over a single TCP connection without waiting for 195 responses SHOULD implement capability discovery as discussed in 196 Section 3.2. 198 By default, a server SHOULD not generate a response larger than 4096 199 octets. The Response-Length attribute MAY be included in a request 200 to indicate that larger responses are acceptable. Other attributes 201 or configuration MAY be used as an indicator that large responses are 202 likely to be acceptable. 204 A proxy that implements both this specification and RADIUS 205 Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use 206 RADIUS fragmentation when the following conditions are met: 208 1. A packet is being forwarded towards an endpoint whose 209 configuration does not support a packet that large. 211 2. RADIUS Fragmentation can be used for the packet in question. 213 3.1. Rationale 215 The interoperability challenge appears at first significant. This 216 specification proposes to introduce behavior where new 217 implementations will fail to function with existing implementations. 219 However, these capabilities are introduced to support new use cases. 220 If an implementation has 10000 octets of attributes to send, it 221 cannot in general trim down the response to something that can be 222 sent. Under this specification a large packet would be generated 223 that will be silently discarded by an existing implementation. 224 Without this specification, no packet is generated because the 225 required attributes cannot be sent. 227 The biggest risk to interoperability would be if requests and 228 responses are expanded to include additional information that is not 229 strictly necessary. So, avoiding creating situations where large 230 packets are sent to existing implementations is mostly an operational 231 matter. Interoperability is most impacted when the size of packets 232 in existing use cases is significantly increased and least impacted 233 when large packets are used for new use cases where the deployment is 234 likely to require updated RADIUS implementations. 236 There is a special challenge for proxies or clients with high request 237 volume. When an RFC 6113 implementation receives a packet that is 238 too large, it closes the connection and does not respond to any 239 requests in process. Such a client would lose requests and might 240 find distinguishing request-too-big situations from other failures 241 difficult. In these cases, the discovery mechanism described in 242 Section 3.2 can be used. 244 Also, RFC 6613 is an experiment. Part of running that experiment is 245 to evaluate whether additional changes are required to RADIUS. A 246 lower bar for interoperability should apply to changes to 247 experimental protocols than standard protocols. 249 This specification provides good facilities to enable implementations 250 to understand packet size when proxying to/from standards-track UDP 251 RADIUS. 253 3.2. Discovery 255 As discussed in Section 2.1, a client MAY send a Status-Server 256 message to discover whether an authentication or accounting server 257 supports this specification. The client includes a Response-Length 258 attribute; this signals the server to include a Response-Length 259 attribute indicating the maximum packet size the server can process. 260 In this one instance, Response-Length indicate the size of a request 261 that can be processed rather than a response. 263 4. Protocol-Error Code 265 This document defines a new RADIUS code, TBDCODE (IANA), called 266 Protocol-Error. This packet code may be used in response to any 267 request packet, such as Access-Request, Accounting-Request, CoA- 268 Request, or Disconnect-Request. It is a response packet sent by a 269 server to a client. The packet indicates to the client that the 270 server is unable to process the request for some reason. 272 A Protocol-Error packet MUST contain a Original-Packet-Code 273 attribute, along with an Error-Cause attribute. Other attributes MAY 274 be included if desired. The Original-Packet-Code contains the code 275 from the request that generated the protocol error so that clients 276 can disambiguate requests with different codes and the same ID. 277 Regardless of the original packet code, the RADIUS server calculates 278 the Message-Authenticator attribute as if the original packet were an 279 Access-Request packet. The identifier is copied from the original 280 request. 282 Clients processing Protocol-Error MUST ignore unknown or unexpected 283 attributes. 285 This RADIUS code is hop-by-hop. Proxies MUST not forward a Protocol- 286 Error packet they receive. 288 5. Too Big Response 290 When a RADIUS server receives a request that is larger than can be 291 processed, it generates a Protocol-Error response as follows: 293 The code is Protocol-Error. 295 The Response-Length attribute MUST be included and its value is 296 the maximum size of request that will be processed. 298 The Error-Cause attribute is included with a value of TOOBIGTBD. 300 The Original-Packet-Code attribute is copied from the request. 302 Clients will not typically be able to adjust and resend requests when 303 this error is received. In some cases the client can fall back to 304 RADIUS Fragmentation. In other cases this code will provide for 305 better client error reporting and will avoid retransmitting requests 306 guaranteed to fail. 308 6. IANA Considerations 310 A new RADIUS packet type code is registered in the RADIUS packet type 311 codes registry discussed in section 2.1 of RFC 3575 [RFC3575]. The 312 name is "Protocol-Error" and the code is TBDCODE. The IESG is 313 requested to approve this registration along with approving 314 publication of this document. 316 The following RADIUS attribute type values [RFC3575] are assigned. 317 The assignment rules in section 10.3 of [RFC6929] are used. 319 +----------------------+-----------+--------------------------------+ 320 | Name | Attribute | Description | 321 +----------------------+-----------+--------------------------------+ 322 | Response-Length | TBD | 2-octet unsigned integer | 323 | | | maximum response length | 324 | | | | 325 | Original-Packet-Code | TBD2 | An integer attribute | 326 | | | containing the code from a | 327 | | | packet resulting in a | 328 | | | Protocol-Error response. | 329 +----------------------+-----------+--------------------------------+ 331 The Response-Length attribute MAY be included in any RADIUS request. 332 In this context it indicates the maximum length of a response the 333 client is prepared to receive. Values are between 4096 and 65535. 334 The attribute MAY also be included in a response to a Status-Server 335 message. In this case the attribute indicate the maximum size RADIUS 336 request that is permitted. 338 A new Error-Cause value is registered in the registry at 339 http://www.iana.org/assignments/radius-types/radius- 340 types.xhtml#radius-types-18 for "Response Too Big" with value 341 TOOBIGTBD. 343 7. Security Considerations 345 This specification updates RFC 6613 and will be used with [RFC6614]. 346 When used over plain TCP, this specification creates new 347 opportunities for an on-path attacker to impact availability. These 348 attacks can be entirely mitigated by using TLS. If these attacks ar 349 acceptable, then this specification can be used over TCP. 351 8. Acknowledgements 353 Sam Hartman's time on this draft was funded by JANET as part of 354 Project Moonshot. 356 Alan DeKok provided valuable review and text for the Protocol-Error 357 packet code. 359 Alejandro Perez Mendez provided valuable review comments. 361 9. References 363 9.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 369 "Remote Authentication Dial In User Service (RADIUS)", RFC 370 2865, June 2000. 372 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 373 Authentication Dial In User Service)", RFC 3575, July 374 2003. 376 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 377 Authentication Dial In User Service (RADIUS) Protocol", 378 RFC 5997, August 2010. 380 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 382 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 383 "Transport Layer Security (TLS) Encryption for RADIUS", 384 RFC 6614, May 2012. 386 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 387 Service (RADIUS) Protocol Extensions", RFC 6929, April 388 2013. 390 9.2. References 392 [I-D.ietf-abfab-aaa-saml] 393 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 394 Profiles, Name Identifier Format, and Confirmation Methods 395 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 396 progress), February 2014. 398 [I-D.ietf-radext-radius-fragmentation] 399 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 400 Millan, G., Lopez, D., and A. DeKok, "Support of 401 fragmentation of RADIUS packets", draft-ietf-radext- 402 radius-fragmentation-06 (work in progress), April 2014. 404 Author's Address 406 Sam Hartman 407 Painless Security 409 Email: hartmans-ietf@mit.edu