idnits 2.17.1 draft-ietf-radext-bigger-packets-02.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 desirable. Other attributes or configuration MAY be used as an indicator that large responses are likely to be acceptable. (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 (February 12, 2015) is 3354 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 381, but not defined == Missing Reference: 'I-D.ietf-radext-radius-fragmentation' is mentioned on line 387, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 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) February 12, 2015 5 Intended status: Experimental 6 Expires: August 16, 2015 8 Larger Packets for RADIUS over TCP 9 draft-ietf-radext-bigger-packets-02.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 to permit larger RADIUS packets. This specification 17 compliments other ongoing work to permit fragmentation of RADIUS 18 authorization information. This document registers a new RADIUS 19 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 August 16, 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 Type . . . . . . . . . . . . . . . . . . . . . 6 63 5. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. References . . . . . . . . . . . . . . . . . . . . . . . 8 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 arrises 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 SHOULD be able to process and forward packets of maximum 142 length. Proxies MUST include the Response-Length attribute when 143 forwarding a request received over a transport with a 4096-octet 144 maximum length over a transport with a higher maximum length. 146 2.1. Status-Server Considerations 148 This section extends processing of Status-Server messages as 149 described in section 4.1 and 4.2 of [RFC5997]. 151 Clients implementing this specification SHOULD include the Response- 152 Length attribute in Status-Request messages. Servers are already 153 required to ignore unknown attributes received in this message. by 154 including the attribute, the client indicates how large of a response 155 it can process to its Status-Server request. It is very unlikely 156 that a response to Status-Server is greater than 4096 octets. 157 However the client also indicates support for this specification 158 which triggers server behavior below. 160 If a server implementing this specification receives a Response- 161 Length attribute in a Status-Server request, it MUST include a 162 Response-Length attribute indicating the maximum size request it can 163 process in its response to the Status-Server request. 165 3. Forward and backward Compatibility 167 An implementation of [RFC6613] will silently discard any packet 168 larger than 4096 octets and will close the TCP connection. This 169 section provides guidelines for interoperability with these 170 implementations. These guidelines are stated at the SHOULD level. 171 In some environments support for large packets will be important 172 enough that roaming or other agreements will mandate their support. 173 In these environments, all implementations might be required to 174 support this specification removing the need for interoperability 175 with RFC 6613. It is likely that these guidelines will be relaxed to 176 the MAY level and support for this specification made a requirement 177 if RADIUS over TLS and TCP are moved to the standards track in the 178 future. 180 Clients SHOULD provide configuration for the maximum size of a 181 request sent to each server. Servers SHOULD provide configuration 182 for the maximum size of a response sent to each client. If dynamic 183 discovery mechanisms are supported, configuration SHOULD be provided 184 for the maximum size of clients and servers in each dynamic discovery 185 category. 187 If a client sends a request larger than 4096 octets and the TCP 188 connection is closed without a response, the client SHOULD treat the 189 request as if a request too big error (Section 5) specifying a 190 maximum size of 4096 is received. Clients or proxies sending 191 multiple requests over a single TCP connection without waiting for 192 responses SHOULD implement capability discovery as discussed in 193 Section 3.2. 195 By default, a server SHOULD not generate a response larger than 4096 196 octets. The Response-Length attribute MAY be included in a request 197 to indicate that larger responses are desirable. Other attributes or 198 configuration MAY be used as an indicator that large responses are 199 likely to be acceptable. 201 A proxy that implements both this specification and RADIUS 202 Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use 203 RADIUS fragmentation when the following conditions are met: 205 1. A packet is being forwarded towards an endpoint whose 206 configuration does not support a packet that large. 208 2. RADIUS Fragmentation can be used for the packet in question. 210 3.1. Rationale 212 The interoperability challenge appears at first significant. This 213 specification proposes to introduce behavior where new 214 implementations will fail to function with existing implementations. 216 However, these capabilities are introduced to support new use cases. 217 If an implementation has 10000 octets of attributes to send, it 218 cannot in general trim down the response to something that can be 219 sent. Under this specification a large packet would be generated 220 that will be silently discarded by an existing implementation. 221 Without this specification, no packet is generated because the 222 required attributes cannot be sent. 224 The biggest risk to interoperability would be if requests and 225 responses are expanded to include additional information that is not 226 strictly necessary. So, avoiding creating situations where large 227 packets are sent to existing implementations is mostly an operational 228 matter. Interoperability is most impacted when the size of packets 229 in existing use cases is significantly increased and least impacted 230 when large packets are used for new use cases where the deployment is 231 likely to require updated RADIUS implementations. 233 There is a special challenge for proxies or clients with high request 234 volume. When an RFc 6113 implementation receives a packet that is 235 too large, it closes the connection and does not respond to any 236 requests in process. Such a client would lose requests and might 237 find distinguishing request-too-big situations from other failures 238 difficult. In these cases, the discovery mechanism described in 239 Section 3.2 can be used. 241 Also, RFC 6613 is an experiment. Part of running that experiment is 242 to evaluate whether additional changes are required to RADIUS. A 243 lower bar for interoperability should apply to changes to 244 experimental protocols than standard protocols. 246 This specification provides good facilities to enable implementations 247 to understand packet size when proxying to/from standards-track UDP 248 RADIUS. 250 3.2. Discovery 252 As discussed in Section 2.1, a client MAY send a Status-Server 253 message to discover whether an authentication or accounting server 254 supports this specification. The client includes a Response-Length 255 attribute; this signals the server to include a Response-Length 256 attribute indicating the maximum packet size the server can process. 257 In this one instance, Response-Length indicate the size of a request 258 that can be processed rather than a response. 260 4. Protocol Error Type 262 This document defines a new RADIUS code, TBD (IANA), called Protocol- 263 Error. This packet code may be used in response to any request 264 packet, such as Access-Request, Accounting-Request, CoA-Request, or 265 Disconnect-Request. It is a response packet sent by a server to a 266 client. The packet indicates to the client that the server is unable 267 to process the request for some reason. 269 A Protocol-Error packet MUST contain a Original-Packet-Code 270 attribute, along with an Error-Cause attribute. Other attributes MAY 271 be included if desired. The Original-Packet-Code contains the code 272 from the request that generated the protocol error. Regardless of 273 the original packet code, the RADIUS server calculates the Message- 274 Authenticator attribute as if the original packet were an Access- 275 Request packet. The identifier is copied from the original request. 277 Clients processing Protocol-Error MUST ignore unknown or unexpected 278 attributes. 280 5. Too Big Response 282 When a RADIUS server receives a request that is larger than can be 283 processed, it generates a Protocol-Error response as follows: 285 The code is Protocol-Error. 287 The Response-Length attribute MUST be included and its value is 288 the maximum size of request that will be processed. 290 The Error-Cause attribute is included with a value of TOOBIGTBD. 292 The Original-Packet-Code attribute is copied from the request. 294 Clients will not typically be able to adjust and resend requests when 295 this error is received. In some cases the client can fall back to 296 RADIUS Fragmentation. In other cases this code will provide for 297 better client error reporting and will avoid retransmitting requests 298 guaranteed to fail. 300 6. IANA Considerations 302 A new RADIUS packet type code is registered in the RADIUS packet type 303 codes registry discussed in section 2.1 of RFC 3575 [RFC3575]. The 304 name is "Protocol-Error" and the code is TBDCODE. The IESG is 305 requested to approve this registration along with approving 306 publication of this document. 308 The following RADIUS attribute type values [RFC3575] are assigned. 309 The assignment rules in section 10.3 of [RFC6929] are used. 311 +----------------------+-----------+--------------------------------+ 312 | Name | Attribute | Description | 313 +----------------------+-----------+--------------------------------+ 314 | Response-Length | TBD | 2-octet unsigned integer | 315 | | | maximum response length | 316 | | | | 317 | Original-Packet-Code | TBD2 | An integer attribute | 318 | | | containing the code from a | 319 | | | packet resulting in a | 320 | | | Protocol-Error response. | 321 +----------------------+-----------+--------------------------------+ 323 The Response-Length attribute MAY be included in any RADIUS request. 324 In this context it indicates the maximum length of a response the 325 client is prepared to receive. Values are between 4096 and 65535. 326 The attribute MAY also be included in a response to a Status-Server 327 message. In this case the attribute indicate the maximum size RADIUS 328 request that is permitted. 330 A new Error-Cause value is registered in the registry at 331 http://www.iana.org/assignments/radius-types/radius- 332 types.xhtml#radius-types-18 for "Response Too Big" with value 333 TOOBIGTBD. 335 7. Security Considerations 337 This specification updates RFC 6613 and will be used with [RFC6614]. 338 When used over plain TCP, this specification creates new 339 opportunities for an on-path attacker to impact availability. these 340 attacks can be entirely mitigated by using TLS. 342 8. Acknowledgements 344 Sam Hartman's time on this draft was funded by JANET as part of 345 Project Moonshot. 347 Alan DeKok provided valuable review and text for the Protocol-Error 348 packet code. 350 9. References 352 9.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 358 "Remote Authentication Dial In User Service (RADIUS)", RFC 359 2865, June 2000. 361 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 362 Authentication Dial In User Service)", RFC 3575, July 363 2003. 365 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 366 Authentication Dial In User Service (RADIUS) Protocol", 367 RFC 5997, August 2010. 369 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 371 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 372 "Transport Layer Security (TLS) Encryption for RADIUS", 373 RFC 6614, May 2012. 375 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 376 Service (RADIUS) Protocol Extensions", RFC 6929, April 377 2013. 379 9.2. References 381 [I-D.ietf-abfab-aaa-saml] 382 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 383 Profiles, Name Identifier Format, and Confirmation Methods 384 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 385 progress), February 2014. 387 [I-D.ietf-radext-radius-fragmentation] 388 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 389 Millan, G., Lopez, D., and A. DeKok, "Support of 390 fragmentation of RADIUS packets", draft-ietf-radext- 391 radius-fragmentation-06 (work in progress), April 2014. 393 Author's Address 395 Sam Hartman 396 Painless Security 398 Email: hartmans-ietf@mit.edu