idnits 2.17.1 draft-ietf-radext-bigger-packets-01.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 (July 2, 2014) is 3584 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 340, but not defined == Missing Reference: 'I-D.ietf-radext-radius-fragmentation' is mentioned on line 346, 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) July 2, 2014 5 Intended status: Experimental 6 Expires: January 3, 2015 8 Larger Packets for RADIUS over TCP 9 draft-ietf-radext-bigger-packets-01.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 January 3, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . 3 59 3. Forward and backward Compatibility . . . . . . . . . . . . . 4 60 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Response Length Attribute . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614] 74 experiment provides strong confidentiality and integrity for RADIUS 75 [RFC2865]. This enhanced security has opened new opportunities for 76 using RADIUS to convey additional authorization information. As an 77 example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using 78 RADIUS to carry Security Assertion Markup Language (SAML) messages in 79 RADIUS. Many attributes carried in these SAML messages will require 80 confidentiality or integrity such as that provided by TLS. 82 These new use cases involve carrying additional information in RADIUS 83 packets. The maximum packet length of 4096 octets is proving 84 insufficient for some SAML messages and for other structures that may 85 be carried in RADIUS. 87 One approach is to fragment a RADIUS message across multiple packets 88 at the RADIUS layer.RADIUS Fragmentation 89 [I-D.ietf-radext-radius-fragmentation] provides a mechanism to split 90 authorization information across multiple RADIUS messages. That 91 mechanism is necessary in order to split authorization information 92 across existing unmodified proxies. 94 However, there are some significant disadvantages to RADIUS 95 fragmentation. First, RADIUS is a lock-step protocol, and only one 96 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 1.1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Changes to Packet Processing 115 The maximum length of a RADIUS message is increased from 4096 to 116 65535. A RADIUS Server implementing this specification MUST be able 117 to receive a packet of maximum length. Servers MAY have a maximum 118 size over which they choose to return an error as discussed in 119 Section 4 rather than processing a received packet; this size MUST be 120 at least 4096 octets. 122 Clients implementing this specification MUST be able to receive a 123 packet of maximum length; that is clients MUST NOT close a TCP 124 connection simply because a large packet is sent over it. Clients 125 MAY include the Response-Length attribute defined in Section 5 to 126 indicate the maximum size of a packet that they can successfully 127 process. Clients MAY silently discard a packet greater than some 128 configured size; this size MUST be at least 4096 octets. Clients 129 MUST NOT retransmit an unmodified request whose response is larger 130 than the client can process as subsequent responses will likely 131 continue to be too large. 133 Proxies SHOULD be able to process and forward packets of maximum 134 length. Proxies MUST include the Response-Length attribute when 135 forwarding a request received over a transport with a 4096-octet 136 maximum length over a transport with a higher maximum length. 138 2.1. Status-Server Considerations 140 This section extends processing of Status-Server messages as 141 described in section 4.1 and 4.2 of [RFC5997]. 143 Clients implementing this specification SHOULD include the Response- 144 Length attribute in Status-Request messages. Servers are already 145 required to ignore unknown attributes received in this message. by 146 including the attribute, the client indicates how large of a response 147 it can process to its Status-Server request. It is very unlikely 148 that a response to Status-Server is greater than 4096 octets. 149 However the client also indicates support for this specification 150 which triggers server behavior below. 152 If a server implementing this specification receives a Response- 153 Length attribute in a Status-Server request, it MUST include a 154 Response-Length attribute indicating the maximum size request it can 155 process in its response to the Status-Server request. 157 3. Forward and backward Compatibility 159 An implementation of [RFC6613] will silently discard any packet 160 larger than 4096 octets and will close the TCP connection. This 161 section provides guidelines for interoperability with these 162 implementations. These guidelines are stated at the SHOULD level. 163 In some environments support for large packets will be important 164 enough that roaming or other agreements will mandate their support. 165 In these environments, all implementations might be required to 166 support this specification removing the need for interoperability 167 with RFC 6613. It is likely that these guidelines will be relaxed to 168 the MAY level and support for this specification made a requirement 169 if RADIUS over TLS and TCP are moved to the standards track in the 170 future. 172 Clients SHOULD provide configuration for the maximum size of a 173 request sent to each server. Servers SHOULD provide configuration 174 for the maximum size of a response sent to each client. If dynamic 175 discovery mechanisms are supported, configuration SHOULD be provided 176 for the maximum size of clients and servers in each dynamic discovery 177 category. 179 If a client sends a request larger than 4096 octets and the TCP 180 connection is closed without a response, the client SHOULD treat the 181 request as if a request too big error (Section 4) specifying a 182 maximum size of 4096 is received. Clients or proxies sending 183 multiple requests over a single TCP connection without waiting for 184 responses SHOULD implement capability discovery as discussed in 185 Section 3.2. 187 By default, a server SHOULD not generate a response larger than 4096 188 octets. The Response-Length attribute MAY be included in a request 189 to indicate that larger responses are desirable. Other attributes or 190 configuration MAY be used as an indicator that large responses are 191 likely to be acceptable. 193 A proxy that implements both this specification and RADIUS 194 Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use 195 RADIUS fragmentation when the following conditions are met: 197 1. A packet is being forwarded towards an endpoint whose 198 configuration does not support a packet that large. 200 2. RADIUS Fragmentation can be used for the packet in question. 202 3.1. Rationale 204 The interoperability challenge appears at first significant. This 205 specification proposes to introduce behavior where new 206 implementations will fail to function with existing implementations. 208 However, these capabilities are introduced to support new use cases. 209 If an implementation has 10000 octets of attributes to send, it 210 cannot in general trim down the response to something that can be 211 sent. Under this specification a large packet would be generated 212 that will be silently discarded by an existing implementation. 213 Without this specification, no packet is generated because the 214 required attributes cannot be sent. 216 The biggest risk to interoperability would be if requests and 217 responses are expanded to include additional information that is not 218 strictly necessary. So, avoiding creating situations where large 219 packets are sent to existing implementations is mostly an operational 220 matter. Interoperability is most impacted when the size of packets 221 in existing use cases is significantly increased and least impacted 222 when large packets are used for new use cases where the deployment is 223 likely to require updated RADIUS implementations. 225 There is a special challenge for proxies or clients with high request 226 volume. When an RFc 6113 implementation receives a packet that is 227 too large, it closes the connection and does not respond to any 228 requests in process. Such a client would lose requests and might 229 find distinguishing request-too-big situations from other failures 230 difficult. In these cases, the discovery mechanism described in 231 Section 3.2 can be used. 233 Also, RFC 6613 is an experiment. Part of running that experiment is 234 to evaluate whether additional changes are required to RADIUS. A 235 lower bar for interoperability should apply to changes to 236 experimental protocols than standard protocols. 238 This specification provides good facilities to enable implementations 239 to understand packet size when proxying to/from standards-track UDP 240 RADIUS. 242 3.2. Discovery 244 As discussed in Section 2.1, a client MAY send a Status-Server 245 message to discover whether an authentication or accounting server 246 supports this specification. The client includes a Response-Length 247 attribute; this signals the server to include a Response-Length 248 attribute indicating the maximum packet size the server can process. 249 In this one instance, Response-Length indicate the size of a request 250 that can be processed rather than a response. 252 4. Too Big Response 254 When a RADIUS server receives a request that is larger than can be 255 processed, it generates a Too-Big response as follows: 257 The code is TBDCODE. 259 The identifier is the identifier from the request. 261 The Response-Length attribute MUST be included and its value is 262 the maximum size of request that will be processed. 264 No other attributes SHOULD be included. Additional attributes 265 MUST be ignored by the client. 267 Clients will not typically be able to adjust and resend requests when 268 this error is received. In some cases the client can fall back to 269 RADIUS Fragmentation. In other cases this code will provide for 270 better client error reporting and will avoid retransmitting requests 271 guaranteed to fail. 273 5. Response Length Attribute 275 The following RADIUS attribute type values [RFC3575] are assigned. 276 The assignment rules in section 10.3 of [RFC6929] are used. 278 +---------------------+---------------+-----------------------------+ 279 | Name | Attribute | Description | 280 +---------------------+---------------+-----------------------------+ 281 | Response-Length | TBD | 2-octet unsigned integer | 282 | | | maximum response length | 283 +---------------------+---------------+-----------------------------+ 284 The Response-Length attribute MAY be included in any RADIUS request. 285 In this context it indicates the maximum length of a response the 286 client is prepared to receive. Values are between 4096 and 65535. 287 The attribute MAY also be included in a response to a Status-Server 288 message. In this case the attribute indicate the maximum size RADIUS 289 request that is permitted. 291 6. IANA Considerations 293 A new RADIUS packet type code is registered in the RADIUS packet type 294 codes registry discussed in section 2.1 of RFC 3575 [RFC3575]. The 295 name is "Too-Big" and the code is TBDCODE. The IESG is requested to 296 approve this registration along with approving publication of this 297 document. 299 IANA is requested to assign the RADIUS type defined in section 300 Section 5 302 7. Security Considerations 304 This specification updates RFC 6613 and will be used with [RFC6614]. 305 When used over plain TCP, this specification creates new 306 opportunities for an on-path attacker to impact availability. these 307 attacks can be entirely mitigated by using TLS. 309 8. References 311 8.1. Normative References 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, March 1997. 316 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 317 "Remote Authentication Dial In User Service (RADIUS)", RFC 318 2865, June 2000. 320 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 321 Authentication Dial In User Service)", RFC 3575, July 322 2003. 324 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 325 Authentication Dial In User Service (RADIUS) Protocol", 326 RFC 5997, August 2010. 328 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 330 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 331 "Transport Layer Security (TLS) Encryption for RADIUS", 332 RFC 6614, May 2012. 334 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 335 Service (RADIUS) Protocol Extensions", RFC 6929, April 336 2013. 338 8.2. References 340 [I-D.ietf-abfab-aaa-saml] 341 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 342 Profiles, Name Identifier Format, and Confirmation Methods 343 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 344 progress), February 2014. 346 [I-D.ietf-radext-radius-fragmentation] 347 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 348 Millan, G., Lopez, D., and A. DeKok, "Support of 349 fragmentation of RADIUS packets", draft-ietf-radext- 350 radius-fragmentation-06 (work in progress), April 2014. 352 Author's Address 354 Sam Hartman 355 Painless Security 357 Email: hartmans-ietf@mit.edu