idnits 2.17.1 draft-ietf-radext-bigger-packets-00.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 (April 25, 2014) is 3653 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 326, but not defined == Missing Reference: 'I-D.ietf-radext-radius-fragmentation' is mentioned on line 332, 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) April 25, 2014 5 Intended status: Experimental 6 Expires: October 27, 2014 8 Larger Packets for RADIUS over TCP 9 draft-ietf-radext-bigger-packets-00.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. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 27, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 56 2. Changes to Packet Processing . . . . . . . . . . . . . . . . 3 57 2.1. Status-Server Considerations . . . . . . . . . . . . . . 3 58 3. Forward and backward Compatibility . . . . . . . . . . . . . 4 59 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Too Big Response . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Response Length Attribute . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. References . . . . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 The Remote Access Dial-In User Server (RADIUS) over TLS [RFC6614] 73 experiment provides strong confidentiality and integrity for RADIUS 74 [RFC2865]. This enhanced security has opened new opportunities for 75 using RADIUS to convey additional authorization information. As an 76 example, [I-D.ietf-abfab-aaa-saml] describes a mechanism for using 77 RADIUS to carry Security Assertion Markup Language (SAML) messages in 78 RADIUS. Many attributes carried in these SAML messages will require 79 confidentiality or integrity such as that provided by TLS. 81 These new use cases involve carrying additional information in RADIUS 82 packets. The maximum packet length of 4096 octets is proving 83 insufficient for some SAML messages and for other structures that may 84 be carried in RADIUS. 86 One approach is to fragment a RADIUS message across multiple packets 87 at the RADIUS layer.RADIUS Fragmentation 88 [I-D.ietf-radext-radius-fragmentation] provides a mechanism to split 89 authorization information across multiple RADIUS messages. That 90 mechanism is necessary in order to split authorization information 91 across existing unmodified proxies. 93 However, there are some significant disadvantages to RADIUS 94 fragmentation. First, RADIUS is a lock-step protocol, and only one 95 fragment can be in transit at a time as part of a given request. 96 Also, there is no current mechanism to discover the path Maximum 97 Transmission Unit (MTU) across the entire path that the fragment will 98 travel. As a result, fragmentation is likely both at the RADIUS 99 layer and at the transport layer. When TCP is used, much better 100 transport characteristics can be achieved by fragmentation only at 101 the TCP layer. 103 1.1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Changes to Packet Processing 111 The maximum length of a RADIUS message is increased from 4096 to 112 65535. A RADIUS Server implementing this specification MUST be able 113 to receive a packet of maximum length. Servers MAY have a maximum 114 size over which they choose to return an error as discussed in 115 Section 4 rather than processing a received packet; this size MUST be 116 at least 4096 octets. 118 Clients implementing this specification MUST be able to receive a 119 packet of maximum length; that is clients MUST NOT close a TCP 120 connection simply because a large packet is sent over it. Clients 121 MAY include the Response-Length attribute defined in Section 5 to 122 indicate the maximum size of a packet that they can successfully 123 process. Clients MAY silently discard a packet greater than some 124 configured size; this size MUST be at least 4096 octets. Clients 125 MUST NOT retransmit an unmodified request whose response is larger 126 than the client can process as subsequent responses will likely 127 continue to be too large. 129 Proxies SHOULD be able to process and forward packets of maximum 130 length. Proxies MUST include the Response-Length attribute when 131 forwarding a request received over a transport with a 4096-octet 132 maximum length over a transport with a higher maximum length. 134 2.1. Status-Server Considerations 136 This section extends processing of Status-Server messages as 137 described in section 4.1 and 4.2 of [RFC5997]. 139 Clients implementing this specification SHOULD include the Response- 140 Length attribute in Status-Request messages. Servers are already 141 required to ignore unknown attributes received in this message. by 142 including the attribute, the client indicates how large of a response 143 it can process to its Status-Server request. It is very unlikely 144 that a response to Status-Server is greater than 4096 octets. 146 However the client also indicates support for this specification 147 which triggers server behavior below. 149 If a server implementing this specification receives a Response- 150 Length attribute in a Status-Server request, it MUST include a 151 Response-Length attribute indicating the maximum size request it can 152 process in its response to the Status-Server request. 154 3. Forward and backward Compatibility 156 An implementation of [RFC6613] will silently discard any packet 157 larger than 4096 octets and will close the TCP connection. This 158 section provides guidelines for interoperability with these 159 implementations. These guidelines are stated at the SHOULD level. 160 In some environments support for large packets will be important 161 enough that roaming or other agreements will mandate their support. 162 In these environments, all implementations might be required to 163 support this specification removing the need for interoperability 164 with RFC 6613. It is likely that these guidelines will be relaxed to 165 the MAY level and support for this specification made a requirement 166 if RADIUS over TLS and TCP are moved to the standards track in the 167 future. 169 Clients SHOULD provide configuration for the maximum size of a 170 request sent to each server. Servers SHOULD provide configuration 171 for the maximum size of a response sent to each client. If dynamic 172 discovery mechanisms are supported, configuration SHOULD be provided 173 for the maximum size of clients and servers in each dynamic discovery 174 category. 176 If a client sends a request larger than 4096 octets and the TCP 177 connection is closed without a response, the client SHOULD treat the 178 request as if a request too big error (Section 4) specifying a 179 maximum size of 4096 is received. Clients or proxies sending 180 multiple requests over a single TCP connection without waiting for 181 responses SHOULD implement capability discovery as discussed in 182 Section 3.2. 184 By default, a server SHOULD not generate a response larger than 4096 185 octets. The Response-Length attribute MAY be included in a request 186 to indicate that larger responses are desirable. Other attributes or 187 configuration MAY be used as an indicator that large responses are 188 likely to be acceptable. 190 A proxy that implements both this specification and RADIUS 191 Fragmentation [I-D.ietf-radext-radius-fragmentation] SHOULD use 192 RADIUS fragmentation when the following conditions are met: 194 1. A packet is being forwarded towards an endpoint whose 195 configuration does not support a packet that large. 197 2. RADIUS Fragmentation can be used for the packet in question. 199 3.1. Rationale 201 The interoperability challenge appears at first significant. This 202 specification proposes to introduce behavior where new 203 implementations will fail to function with existing implementations. 205 However, these capabilities are introduced to support new use cases. 206 If an implementation has 10000 octets of attributes to send, it 207 cannot in general trim down the response to something that can be 208 sent. Under this specification a large packet would be generated 209 that will be silently discarded by an existing implementation. 210 Without this specification, no packet is generated because the 211 required attributes cannot be sent. 213 The biggest risk to interoperability would be if requests and 214 responses are expanded to include additional information that is not 215 strictly necessary. So, avoiding creating situations where large 216 packets are sent to existing implementations is mostly an operational 217 matter. Interoperability is most impacted when the size of packets 218 in existing use cases is significantly increased and least impacted 219 when large packets are used for new use cases where the deployment is 220 likely to require updated RADIUS implementations. 222 There is a special challenge for proxies or clients with high request 223 volume. When an RFc 6113 implementation receives a packet that is 224 too large, it closes the connection and does not respond to any 225 requests in process. Such a client would lose requests and might 226 find distinguishing request-too-big situations from other failures 227 difficult. In these cases, the discovery mechanism described in 228 Section 3.2 can be used. 230 Also, RFC 6613 is an experiment. Part of running that experiment is 231 to evaluate whether additional changes are required to RADIUS. A 232 lower bar for interoperability should apply to changes to 233 experimental protocols than standard protocols. 235 This specification provides good facilities to enable implementations 236 to understand packet size when proxying to/from standards-track UDP 237 RADIUS. 239 3.2. Discovery 240 As discussed in Section 2.1, a client MAY send a Status-Server 241 message to discover whether an authentication or accounting server 242 supports this specification. The client includes a Response-Length 243 attribute; this signals the server to include a Response-Length 244 attribute indicating the maximum packet size the server can process. 245 In this one instance, Response-Length indicate the size of a request 246 that can be processed rather than a response. 248 4. Too Big Response 250 Define a new RADIUS code indicating that a server has received a 251 request that is larger than can be processed. Include mandatory 252 attribute indicating the maximum size that is permitted. 254 Clients will not typically be able to adjust and resend requests when 255 this error is received. In some cases the client can fall back to 256 RADIUS Fragmentation. In other cases this code will provide for 257 better client error reporting and will avoid retransmitting requests 258 guaranteed to fail. 260 5. Response Length Attribute 262 The following RADIUS attribute type values [RFC3575] are assigned. 263 The assignment rules in section 10.3 of [RFC6929] are used. 265 +---------------------+---------------+-----------------------------+ 266 | Name | Attribute | Description | 267 +---------------------+---------------+-----------------------------+ 268 | Response-Length | TBD | 2-octet unsigned integer | 269 | | | maximum response length | 270 +---------------------+---------------+-----------------------------+ 272 The Response-Length attribute MAY be included in any RADIUS request. 273 In this context it indicates the maximum length of a response the 274 client is prepared to receive. Values are between 4096 and 65535. 275 The attribute MAY also be included in a response to a Status-Server 276 message. In this case the attribute indicate the maximum size RADIUS 277 request that is permitted. 279 6. IANA Considerations 281 Once this document is more complete it will define a new RADIUS code 282 and attribute. Figure out if we have IANA policy lossage defining a 283 code in an experimental document. 285 IANA is requested to assign the RADIUS type defined in section 286 Section 5 288 7. Security Considerations 290 This specification updates RFC 6613 and will be used with [RFC6614]. 291 When used over plain TCP, this specification creates new 292 opportunities for an on-path attacker to impact availability. these 293 attacks can be entirely mitigated by using TLS. 295 8. References 297 8.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 303 "Remote Authentication Dial In User Service (RADIUS)", RFC 304 2865, June 2000. 306 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 307 Authentication Dial In User Service)", RFC 3575, July 308 2003. 310 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 311 Authentication Dial In User Service (RADIUS) Protocol", 312 RFC 5997, August 2010. 314 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 316 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 317 "Transport Layer Security (TLS) Encryption for RADIUS", 318 RFC 6614, May 2012. 320 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 321 Service (RADIUS) Protocol Extensions", RFC 6929, April 322 2013. 324 8.2. References 326 [I-D.ietf-abfab-aaa-saml] 327 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 328 Profiles, Name Identifier Format, and Confirmation Methods 329 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 330 progress), February 2014. 332 [I-D.ietf-radext-radius-fragmentation] 333 Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- 334 Millan, G., Lopez, D., and A. DeKok, "Support of 335 fragmentation of RADIUS packets", draft-ietf-radext- 336 radius-fragmentation-06 (work in progress), April 2014. 338 Author's Address 340 Sam Hartman 341 Painless Security 343 Email: hartmans-ietf@mit.edu