idnits 2.17.1 draft-ietf-radext-radius-fragmentation-10.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 RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6929, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6158, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) -- 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 (January 9, 2015) is 3388 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1274, but not defined == Missing Reference: 'MT' is mentioned on line 1275, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-abfab-aaa-saml-09 == Outdated reference: A later version (-07) exists of draft-ietf-radext-bigger-packets-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS EXTensions Working Group A. Perez-Mendez 3 Internet-Draft R. Marin-Lopez 4 Updates: 2865, 6158, 6929 F. Pereniguez-Garcia 5 (if approved) G. Lopez-Millan 6 Intended status: Experimental University of Murcia 7 Expires: July 13, 2015 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 January 9, 2015 13 Support of fragmentation of RADIUS packets 14 draft-ietf-radext-radius-fragmentation-10 16 Abstract 18 The Remote Authentication Dial-In User Service (RADIUS) protocol is 19 limited to a total packet size of 4096 octets. Provisions exist for 20 fragmenting large amounts of authentication data across multiple 21 packets, via Access-Challenge. No similar provisions exist for 22 fragmenting large amounts of authorization data. This document 23 specifies how existing RADIUS mechanisms can be leveraged to provide 24 that functionality. These mechanisms are largely compatible with 25 existing implementations, and are designed to be invisible to 26 proxies, and "fail-safe" to legacy RADIUS Clients and Servers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 13, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 64 2. Status of this document . . . . . . . . . . . . . . . . . . . 6 65 3. Scope of this document . . . . . . . . . . . . . . . . . . . . 7 66 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 12 68 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12 69 5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17 70 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21 72 8. Handling special attributes . . . . . . . . . . . . . . . . . 22 73 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22 74 8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23 75 8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24 76 8.4. Rebuilding the original large packet . . . . . . . . . . . 24 77 9. New flag T field for the Long Extended Type attribute 78 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 10. New attribute definition . . . . . . . . . . . . . . . . . . . 25 80 10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25 81 10.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 26 82 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 83 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 84 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 85 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 86 12. General considerations . . . . . . . . . . . . . . . . . . . . 29 87 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 88 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 89 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 90 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 93 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 96 16.2. Informative References . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 100 1. Introduction 102 The RADIUS [RFC2865] protocol carries authentication, authorization, 103 and accounting information between a RADIUS Client and an RADIUS 104 Server. Information is exchanged between them through RADIUS 105 packets. Each RADIUS packet is composed of a header, and zero or 106 more attributes, up to a maximum packet size of 4096 octets. The 107 protocol is a request/response protocol, as described in the 108 operational model ([RFC6158], Section 3.1). 110 The intention of the above packet size limitation was to avoid as 111 much as possible UDP fragmentation. Back then, 4096 seemed large 112 enough for any purpose. Now, new scenarios are emerging that require 113 the exchange of authorization information exceeding this 4096 limit. 114 For instance, the Application Bridging for Federated Access Beyond 115 web (ABFAB) IETF WG defines the transport of Security Assertion 116 Markup Language (SAML) sentences from the RADIUS server to the RADIUS 117 client [I-D.ietf-abfab-aaa-saml]. This assertion is likely to be 118 larger than 4096 octets. 120 This means that peers desiring to send large amounts of data must 121 fragment it across multiple packets. For example, RADIUS-EAP 122 [RFC3579] defines how an Extensible Authentication Protocol (EAP) 123 exchange occurs across multiple Access-Request / Access-Challenge 124 sequences. No such exchange is possible for accounting or 125 authorization data. [RFC6158] Section 3.1 suggests that exchanging 126 large amounts authorization data is unnecessary in RADIUS. Instead, 127 the data should be referenced by name. This requirement allows large 128 policies to be pre-provisioned, and then referenced in an Access- 129 Accept. In some cases, however, the authorization data sent by the 130 RADIUS Server is large and highly dynamic. In other cases, the 131 RADIUS Client needs to send large amounts of authorization data to 132 the RADIUS Server. Both of these cases are un-met by the 133 requirements in [RFC6158]. As noted in that document, the practical 134 limit on RADIUS packet sizes is governed by the Path MTU (PMTU), 135 which may be significantly smaller than 4096 octets. The combination 136 of the two limitations means that there is a pressing need for a 137 method to send large amounts of authorization data between RADIUS 138 Client and Server, with no accompanying solution. 140 [RFC6158] section 3.1 recommends three approaches for the 141 transmission of large amount of data within RADIUS. However, they 142 are not applicable to the problem statement of this document for the 143 following reasons: 145 o The first approach (utilization of a sequence of packets) does not 146 talk about large amounts of data sent from the RADIUS Client to a 147 RADIUS Server. Leveraging EAP (request/challenge) to send the 148 data is not feasible, as EAP already fills packet to PMTU, and not 149 all authentications use EAP. Moreover, as noted for NAS-Filter- 150 Rule ([RFC4849]), this approach does not entirely solve the 151 problem of sending large amounts of data from a RADIUS Server to a 152 RADIUS Client, as many current RADIUS attributes are not permitted 153 in an Access-Challenge packets. 155 o The second approach (utilization of names rather than values) is 156 not usable either, as using names rather than values is difficult 157 when the nature of the data to be sent is highly dynamic (e.g. 158 SAML statement or NAS-Filter-Rule attributes). URLs could be used 159 as a pointer to the location of the actual data, but their use 160 would require them to be (a) dynamically created and modified, (b) 161 securely accessed and (c) accessible from remote systems. 162 Satisfying these constraints would require the modification of 163 several networking systems (e.g. firewalls and web servers). 164 Furthermore, the setup of an additional trust infrastructure (e.g. 165 Public Key Infrastructure - PKI) would be required to allow secure 166 retrieving of the information from the web server. 168 o PMTU discovery does not solve the problem, as it does not allow to 169 send data larger than the minimum of (PMTU or 4096) octets. 171 This document provides a mechanism to allow RADIUS peers to exchange 172 large amounts of authorization data exceeding the 4096 octet limit, 173 by fragmenting it across several exchanges. The proposed solution 174 does not impose any additional requirements to the RADIUS system 175 administrators (e.g. need to modify firewall rules, set up web 176 servers, configure routers, or modify any application server). It 177 maintains compatibility with intra-packet fragmentation mechanisms 178 (like those defined in [RFC3579] or in [RFC6929]). It is also 179 transparent to existing RADIUS proxies, which do not implement this 180 specification. The only systems needing to implement this RFC are 181 the ones which either generate, or consume the fragmented data being 182 transmitted. Intermediate proxies just pass the packets without 183 changes. Nevertheless, if a proxy supports this specification, it 184 may re-assemble the data in order to either examine and/or modify it. 186 A different approach to deal with RADIUS packets above the 4096 octet 187 limit is described in [I-D.ietf-radext-bigger-packets], which 188 proposes to extend RADIUS over TCP by allowing the length field in 189 the RADIUS header to take values up to 65535 octets. This provides a 190 simpler operation, but it has the drawback of requiring every RADIUS 191 proxy in the path between the RADIUS client and the RADIUS server to 192 implement the extension as well. 194 1.1. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 When these words appear in lower case, they have their natural 200 language meaning. 202 2. Status of this document 204 This document is an Experimental RFC. It defines a proposal to allow 205 sending and receiving data exceeding the 4096 octet limit in RADIUS 206 packets imposed by [RFC2865], without requiring the modification of 207 intermediary proxies. 209 The experiment consists in verifying whether the approach is usable 210 on a large scale environment, by observing the uptake, usability, and 211 operational behavior it shows in large-scale, real-life deployments. 212 In that sense, so far the main use case for this specification is the 213 transportation of large SAML sentences defined within the ABFAB 214 architecture [I-D.ietf-abfab-arch]. Hence, it can be tested wherever 215 an ABFAB deployment is being piloted. 217 Besides, this proposal defines some experimental features that will 218 need to be tested and verified before the document can be considered 219 for Standards Track. The first one of them is the requirement of 220 updating [RFC2865] in order to relax the sentence defined in Section 221 4.1 and stating that "An Access-Request MUST contain either a User- 222 Password or a CHAP- Password or a State". This specification might 223 generate Access-Request packets without any of these attributes. 224 Although all known implementations have chosen the philosophy of "be 225 liberal in what you accept", we need to gain more operational 226 experience to verify that unmodified proxies do not drop this kind of 227 packets. More details on this aspect can be found in Section 12.2. 229 Another experimental feature of this specification is that it 230 requires proxies to base their routing decisions on the value of the 231 RADIUS User-Name attribute. Our experience is that this is the 232 common behaviour, thus no issues are expected. However, it needs to 233 be confirmed after using different implementations of intermediate 234 proxies. More details on this aspect can be found in Section 12.3. 236 Moreover, this document requires two minor updates to Standards Track 237 documents. First, it modifies the definition of the "Reserved" field 238 of the "Long Extended Type" attribute [RFC6929], by allocating an 239 additional flag "T". No issues are expected with this update, 240 although some proxies might drop packets that does not have the 241 "Reserved" field set to 0. More details on this aspect can be found 242 in Section 12.1. 244 The other Standards Track document that requires a minor update is 245 [RFC6158]. It states that "attribute designers SHOULD NOT assume 246 that a RADIUS implementation can successfully process RADIUS packets 247 larger than 4096 octets", something no longer true if this document 248 advances. 250 3. Scope of this document 252 This specification describes how a RADIUS Client and a RADIUS Server 253 can exchange data exceeding the 4096 octet limit imposed by one 254 packet. However, the mechanism described in this specification 255 SHOULD NOT be used to exchange more than 100 kilo-octets of data. 256 Any more than this may turn RADIUS into a generic transport protocol, 257 such as TCP or SCTP, which is undesired. Experience shows that 258 attempts to transport bulk data across the Internet with UDP will 259 inevitably fail, unless they re-implement all of the behavior of TCP. 260 The underlying design of RADIUS lacks the proper retransmission 261 policies or congestion control mechanisms which would make it a 262 competitor to TCP. 264 Therefore, RADIUS/UDP transport is by design unable to transport bulk 265 data. It is both undesired and impossible to change the protocol at 266 this point in time. This specification is intended to allow the 267 transport of more than 4096 octets of data through existing RADIUS/ 268 UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a 269 "green field" deployment requires the transport of bulk data. 271 Section 7, below, describes with further details the reasoning for 272 this limitation, and recommends administrators to adjust it according 273 to the specific capabilities of their existing systems in terms of 274 memory and processing power. 276 Moreover, its scope is limited to the exchange of authorization data, 277 as other exchanges do not require of such a mechanism. In 278 particular, authentication exchanges have already been defined to 279 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 280 represent the most critical part of a RADIUS conversation, it is 281 preferable to not introduce any modification to their operation that 282 may affect existing equipment. 284 There is no need to fragment accounting packets either. While the 285 accounting process can send large amounts of data, that data is 286 typically composed of many small updates. That is, there is no 287 demonstrated need to send indivisible blocks of more than 4 kilo- 288 octets of data. The need to send large amounts of data per user 289 session often originates from the need for flow-based accounting. In 290 this use-case, the RADIUS Client may send accounting data for many 291 thousands of flows, where all those flows are tied to one user 292 session. The existing Acct-Multi-Session-Id attribute defined in 293 [RFC2866] Section 5.11 has been proven to work here. 295 Similarly, there is no need to fragment Change of Authorization (CoA) 296 [RFC5176] packets. Instead, the CoA client MUST send a CoA-Request 297 packet containing session identification attributes, along with 298 Service-Type = Additional-Authorization, and a State attribute. 299 Implementations not supporting fragmentation will respond with a CoA- 300 NAK, and an Error-Cause of Unsupported-Service. 302 The above requirement does not assume that the CoA client and the 303 RADIUS Server are co-located. They may, in fact be run on separate 304 parts of the infrastructure, or even by separate administrators. 305 There is, however, a requirement that the two communicate. We can 306 see that the CoA client needs to send session identification 307 attributes in order to send CoA packets. These attributes cannot be 308 known a priori by the CoA client, and can only come from the RADIUS 309 Server. Therefore, even when the two systems are not co-located, 310 they must be able to communicate in order to operate in unison. The 311 alternative is for the two systems to have differing views of the 312 users authorization parameters, which is a security disaster. 314 This specification does not allow for fragmentation of CoA packets. 315 Allowing for fragmented CoA packets would involve changing multiple 316 parts of the RADIUS protocol, with the corresponding possibility for 317 implementation issues, mistakes, etc. 319 Where CoA clients (i.e. RADIUS Servers) need to send large amounts 320 of authorization data to a CoA server (i.e. RADIUS Client), they 321 need only send a minimal CoA-Request packet, containing Service-Type 322 of Authorize-Only, as per RFC 5176, along with session identification 323 attributes. This CoA packet serves as a signal to the RADIUS Client 324 that the users' session requires re-authorization. When the RADIUS 325 Client re-authorizes the user via Access-Request, the RADIUS Server 326 can perform fragmentation, and send large amounts of authorization 327 data to the RADIUS Client. 329 The assumption in the above scenario is that the CoA client and 330 RADIUS Server are co-located, or at least strongly coupled. That is, 331 the path from CoA client to CoA server SHOULD be the exact reverse of 332 the path from RADIUS Client to RADIUS Server. The following diagram 333 will hopefully clarify the roles: 335 +---------------------+ 336 | RADIUS | 337 | Client CoA Server | 338 +---------------------+ 339 | ^ 340 Access-Request | | CoA-Request 341 v | 342 +---------------------+ 343 | RADIUS CoA client | 344 | Server | 345 +---------------------+ 347 Where there is a proxy involved: 349 +---------------------+ 350 | RADIUS | 351 | Client CoA Server | 352 +---------------------+ 353 | ^ 354 Access-Request | | CoA-Request 355 v | 356 +---------------------+ 357 | RADIUS CoA | 358 | Proxy Proxy | 359 +---------------------+ 360 | ^ 361 Access-Request | | CoA-Request 362 v | 363 +---------------------+ 364 | RADIUS CoA client | 365 | Server | 366 +---------------------+ 368 That is, the RADIUS and CoA subsystems at each hop are strongly 369 connected. Where they are not strongly connected, it will be 370 impossible to use CoA-Request packets to transport large amounts of 371 authorization data. 373 This design is more complicated than allowing for fragmented CoA 374 packets. However, the CoA client and the RADIUS Server must 375 communicate even when not using this specification. We believe that 376 standardizing that communication, and using one method for exchange 377 of large data is preferred to unspecified communication methods and 378 multiple ways of achieving the same result. If we were to allow 379 fragmentation of data over CoA packets, the size and complexity of 380 this specification would increase significantly. 382 The above requirement solves a number of issues. It clearly 383 separates session identification from authorization. Without this 384 separation, it is difficult to both identify a session, and change 385 its authorization using the same attribute. It also ensures that the 386 authorization process is the same for initial authentication, and for 387 CoA. 389 4. Overview 391 Authorization exchanges can occur either before or after end user 392 authentication has been completed. An authorization exchange before 393 authentication allows a RADIUS Client to provide the RADIUS Server 394 with information that MAY modify how the authentication process will 395 be performed (e.g. it may affect the selection of the EAP method). 396 An authorization exchange after authentication allows the RADIUS 397 Server to provide the RADIUS Client with information about the end 398 user, the results of the authentication process and/or obligations to 399 be enforced. In this specification we refer to the "pre- 400 authorization" as the exchange of authorization information before 401 the end user authentication has started (from the RADIUS Client to 402 the RADIUS Server), whereas the term "post-authorization" is used to 403 refer to an authorization exchange happening after this 404 authentication process (from the RADIUS Server to the RADIUS Client). 406 In this specification we refer to the "size limit" as the practical 407 limit on RADIUS packet sizes. This limit is the minimum between 4096 408 octets and the current PMTU. We define below a method which uses 409 Access-Request and Access-Accept in order to exchange fragmented 410 data. The RADIUS Client and server exchange a series of Access- 411 Request / Access-Accept packets, until such time as all of the 412 fragmented data has been transported. Each packet contains a Frag- 413 Status attribute which lets the other party know if fragmentation is 414 desired, ongoing, or finished. Each packet may also contain the 415 fragmented data, or instead be an "ACK" to a previous fragment from 416 the other party. Each Access-Request contains a User-Name attribute, 417 allowing the packet to be proxied if necessary (see Section 11.1). 418 Each Access-Request may also contain a State attribute, which serves 419 to tie it to a previous Access-Accept. Each Access-Accept contains a 420 State attribute, for use by the RADIUS Client in a later Access- 421 Request. Each Access-Accept contains a Service-Type attribute with 422 the "Additional-Authorization" value. This indicates that the 423 service being provided is part of a fragmented exchange, and that the 424 Access-Accept should not be interpreted as providing network access 425 to the end user. 427 When a RADIUS Client or RADIUS Server need to send data that exceeds 428 the size limit, the mechanism proposed in this document is used. 429 Instead of encoding one large RADIUS packet, a series of smaller 430 RADIUS packets of the same type are encoded. Each smaller packet is 431 called a "chunk" in this specification, in order to distinguish it 432 from traditional RADIUS packets. The encoding process is a simple 433 linear walk over the attributes to be encoded. This walk preserves 434 the order of the attributes of the same type, as required by 435 [RFC2865]. The number of attributes encoded in a particular chunk 436 depends on the size limit, the size of each attribute, the number of 437 proxies between the RADIUS Client and RADIUS Server, and the overhead 438 for fragmentation signalling attributes. Specific details are given 439 in Section 6. A new attribute called Frag-Status (Section 10.1) 440 signals the fragmentation status. 442 After the first chunk is encoded, it is sent to the other party. The 443 packet is identified as a chunk via the Frag-Status attribute. The 444 other party then requests additional chunks, again using the Frag- 445 Status attribute. This process is repeated until all the attributes 446 have been sent from one party to the other. When all the chunks have 447 been received, the original list of attributes is reconstructed and 448 processed as if it had been received in one packet. 450 When multiple chunks are sent, a special situation may occur for 451 Extended Type attributes as defined in [RFC6929]. The fragmentation 452 process may split a fragmented attribute across two or more chunks, 453 which is not permitted by that specification. We address this issue 454 by using the newly defined flag "T" in the Reserved field of the 455 "Long Extended Type" attribute format (see Section 9 for further 456 details on this flag). 458 This last situation is expected to be the most common occurrence in 459 chunks. Typically, packet fragmentation will occur as a consequence 460 of a desire to send one or more large (and therefore fragmented) 461 attributes. The large attribute will likely be split into two or 462 more pieces. Where chunking does not split a fragmented attribute, 463 no special treatment is necessary. 465 The setting of the "T" flag is the only case where the chunking 466 process affects the content of an attribute. Even then, the "Value" 467 fields of all attributes remain unchanged. Any per-packet security 468 attributes such as Message-Authenticator are calculated for each 469 chunk independently. There are neither integrity nor security checks 470 performed on the "original" packet. 472 Each RADIUS packet sent or received as part of the chunking process 473 MUST be a valid packet, subject to all format and security 474 requirements. This requirement ensures that a "transparent" proxy 475 not implementing this specification can receive and send compliant 476 packets. That is, a proxy which simply forwards packets without 477 detailed examination or any modification will be able to proxy 478 "chunks". 480 5. Fragmentation of packets 482 When the RADIUS Client or the RADIUS Server desires to send a packet 483 that exceeds the size limit, it is split into chunks and sent via 484 multiple client/server exchanges. The exchange is indicated via the 485 Frag-Status attribute, which has value More-Data-Pending for all but 486 the last chunk of the series. The chunks are tied together via the 487 State attribute. 489 The delivery of a large fragmented RADIUS packet with authorization 490 data can happen before or after the end user has been authenticated 491 by the RADIUS Server. We can distinguish two phases, which can be 492 omitted if there is no authorization data to be sent: 494 1. Pre-authorization. In this phase, the RADIUS Client MAY send a 495 large packet with authorization information to the RADIUS Server 496 before the end user is authenticated. Only the RADIUS Client is 497 allowed to send authorization data during this phase. 499 2. Post-authorization. In this phase, the RADIUS Server MAY send a 500 large packet with authorization data to the RADIUS Client after 501 the end user has been authenticated. Only the RADIUS Server is 502 allowed to send authorization data during this phase. 504 The following subsections describe how to perform fragmentation for 505 packets for these two phases, pre-authorization and post- 506 authorization. We give the packet type, along with a RADIUS 507 Identifier, to indicate that requests and responses are connected. 508 We then give a list of attributes. We do not give values for most 509 attributes, as we wish to concentrate on the fragmentation behaviour, 510 rather than packet contents. Attribute values are given for 511 attributes relevant to the fragmentation process. Where "long 512 extended" attributes are used, we indicate the M (More) and T 513 (Truncation) flags as optional square brackets after the attribute 514 name. As no "long extended" attributes have yet been defined, we use 515 example attributes, named as "Example-Long-1", etc. The maximum 516 chunk size is established in term of number of attributes (11), for 517 sake of simplicity. 519 5.1. Pre-authorization 521 When the RADIUS Client needs to send a large amount of data to the 522 RADIUS Server, the data to be sent is split into chunks and sent to 523 the RADIUS Server via multiple Access-Request / Access-Accept 524 exchanges. The example below shows this exchange. 526 The following is an Access-Request which the RADIUS Client intends to 527 send to a RADIUS Server. However, due to a combination of issues 528 (PMTU, large attributes, etc.), the content does not fit into one 529 Access-Request packet. 531 Access-Request 532 User-Name 533 NAS-Identifier 534 Calling-Station-Id 535 Example-Long-1 [M] 536 Example-Long-1 [M] 537 Example-Long-1 [M] 538 Example-Long-1 [M] 539 Example-Long-1 [M] 540 Example-Long-1 [M] 541 Example-Long-1 [M] 542 Example-Long-1 [M] 543 Example-Long-1 544 Example-Long-2 [M] 545 Example-Long-2 [M] 546 Example-Long-2 548 Figure 1: Desired Access-Request 550 The RADIUS Client therefore must send the attributes listed above in 551 a series of chunks. The first chunk contains eight (8) attributes 552 from the original Access-Request, and a Frag-Status attribute. Since 553 last attribute is "Example-Long-1" with the "M" flag set, the 554 chunking process also sets the "T" flag in that attribute. The 555 Access-Request is sent with a RADIUS Identifier field having value 556 23. The Frag-Status attribute has value More-Data-Pending, to 557 indicate that the RADIUS Client wishes to send more data in a 558 subsequent Access-Request. The RADIUS Client also adds a Service- 559 Type attribute, which indicates that it is part of the chunking 560 process. The packet is signed with the Message-Authenticator 561 attribute, completing the maximum number of attributes (11). 563 Access-Request (ID = 23) 564 User-Name 565 NAS-Identifier 566 Calling-Station-Id 567 Example-Long-1 [M] 568 Example-Long-1 [M] 569 Example-Long-1 [M] 570 Example-Long-1 [M] 571 Example-Long-1 [MT] 572 Frag-Status = More-Data-Pending 573 Service-Type = Additional-Authorization 574 Message-Authenticator 576 Figure 2: Access-Request (chunk 1) 578 Compliant RADIUS Servers (i.e. servers implementing fragmentation) 579 receiving this packet will see the Frag-Status attribute, and 580 postpone all authorization and authentication handling until all of 581 the chunks have been received. This postponement also affects to the 582 verification that the Access-Request packet contains some kind of 583 authentication attribute (e.g. User-Password, CHAP-Password, State 584 or other future attribute), as required by [RFC2865] (see 585 Section 12.2 for more information on this). 587 Non-compliant RADIUS Servers (i.e. servers not implementing 588 fragmentation) should also see the Service-Type requesting 589 provisioning for an unknown service, and return Access-Reject. Other 590 non-compliant RADIUS Servers may return an Access-Reject, Access- 591 Challenge, or an Access-Accept with a particular Service-Type other 592 than Additional-Authorization. Compliant RADIUS Client 593 implementations MUST treat these responses as if they had received 594 Access-Reject instead. 596 Compliant RADIUS Servers who wish to receive all of the chunks will 597 respond with the following packet. The value of the State here is 598 arbitrary, and serves only as a unique token for example purposes. 599 We only note that it MUST be temporally unique to the RADIUS Server. 601 Access-Accept (ID = 23) 602 Frag-Status = More-Data-Request 603 Service-Type = Additional-Authorization 604 State = 0xabc00001 605 Message-Authenticator 607 Figure 3: Access-Accept (chunk 1) 609 The RADIUS Client will see this response, and use the RADIUS 610 Identifier field to associate it with an ongoing chunking session. 612 Compliant NASes will then continue the chunking process. Non- 613 compliant NASes will never see a response such as this, as they will 614 never send a Frag-Status attribute. The Service-Type attribute is 615 included in the Access-Accept in order to signal that the response is 616 part of the chunking process. This packet therefore does not 617 provision any network service for the end user. 619 The RADIUS Client continues the process by sending the next chunk, 620 which includes an additional six (6) attributes from the original 621 packet. It again includes the User-Name attribute, so that non- 622 compliant proxies can process the packet (see Section 11.1). It sets 623 the Frag-Status attribute to More-Data-Pending, as more data is 624 pending. It includes a Service-Type for reasons described above. It 625 includes the State attribute from the previous Access-accept. It 626 signs the packet with Message-Authenticator, as there are no 627 authentication attributes in the packet. It uses a new RADIUS 628 Identifier field. 630 Access-Request (ID = 181) 631 User-Name 632 Example-Long-1 [M] 633 Example-Long-1 [M] 634 Example-Long-1 [M] 635 Example-Long-1 636 Example-Long-2 [M] 637 Example-Long-2 [MT] 638 Frag-Status = More-Data-Pending 639 Service-Type = Additional-Authorization 640 State = 0xabc000001 641 Message-Authenticator 643 Figure 4: Access-Request (chunk 2) 645 Compliant RADIUS Servers receiving this packet will see the Frag- 646 Status attribute, and look for a State attribute. Since one exists 647 and it matches a State sent in an Access-Accept, this packet is part 648 of a chunking process. The RADIUS Server will associate the 649 attributes with the previous chunk. Since the Frag-Status attribute 650 has value More-Data-Request, the RADIUS Server will respond with an 651 Access-Accept as before. It MUST include a State attribute, with a 652 value different from the previous Access-Accept. This State MUST 653 again be globally and temporally unique. 655 Access-Accept (ID = 181) 656 Frag-Status = More-Data-Request 657 Service-Type = Additional-Authorization 658 State = 0xdef00002 659 Message-Authenticator 661 Figure 5: Access-Accept (chunk 2) 663 The RADIUS Client will see this response, and use the RADIUS 664 Identifier field to associate it with an ongoing chunking session. 665 The RADIUS Client continues the chunking process by sending the next 666 chunk, with the final attribute(s) from the original packet, and 667 again includes the original User-Name attribute. The Frag-Status 668 attribute is not included in the next Access-Request, as no more 669 chunks are available for sending. The RADIUS Client includes the 670 State attribute from the previous Access-accept. It signs the packet 671 with Message-Authenticator, as there are no authentication attributes 672 in the packet. It again uses a new RADIUS Identifier field. 674 Access-Request (ID = 241) 675 User-Name 676 Example-Long-2 677 State = 0xdef00002 678 Message-Authenticator 680 Figure 6: Access-Request (chunk 3) 682 On reception of this last chunk, the RADIUS Server matches it with an 683 ongoing session via the State attribute, and sees that there is no 684 Frag-Status attribute present. It then processes the received 685 attributes as if they had been sent in one RADIUS packet. See 686 Section 8.4 for further details of this process. It generates the 687 appropriate response, which can be either Access-Accept or Access- 688 Reject. In this example, we show an Access-Accept. The RADIUS 689 Server MUST send a State attribute, which permits link the received 690 data with the authentication process. 692 Access-Accept (ID = 241) 693 State = 0x98700003 694 Message-Authenticator 696 Figure 7: Access-Accept (chunk 3) 698 The above example shows in practice how the chunking process works. 699 We re-iterate the implementation and security requirements here. 701 Each chunk is a valid RADIUS packet (see Section 12.2 for some 702 considerations about this), and all RADIUS format and security 703 requirements MUST be followed before any chunking process is applied. 705 Every chunk except for the last one from a RADIUS Client MUST include 706 a Frag-Status attribute, with value More-Data-Pending. The last 707 chunk MUST NOT contain a Frag-Status attribute. Each chunk except 708 for the last from a RADIUS Client MUST include a Service-Type 709 attribute, with value Additional-Authorization. Each chunk MUST 710 include a User-Name attribute, which MUST be identical in all chunks. 711 Each chunk except for the first one from a RADIUS Client MUST include 712 a State attribute, which MUST be copied from a previous Access- 713 Accept. 715 Each Access-Accept MUST include a State attribute. The value for 716 this attribute MUST change in every new Access-Accept, and MUST be 717 globally and temporally unique. 719 5.2. Post-authorization 721 When the RADIUS Server wants to send a large amount of authorization 722 data to the RADIUS Client after authentication, the operation is very 723 similar to the pre-authorization one. The presence of Service-Type = 724 Additional-Authorization attribute ensures that a RADIUS Client not 725 supporting this specification will treat that unrecognized Service- 726 Type as though an Access-Reject had been received instead ([RFC2865] 727 Section 5.6). If the original large Access-Accept packet contained a 728 Service-Type attribute, it will be included with its original value 729 in the last transmitted chunk, to avoid confusion with the one used 730 for fragmentation signalling. It is RECOMMENDED that RADIUS Servers 731 include a State attribute on their original Access-Accept packets, 732 even if fragmentation is not taking place, to allow the RADIUS Client 733 to send additional authorization data in subsequent exchanges. This 734 State attribute would be included in the last transmitted chunk, to 735 avoid confusion with the ones used for fragmentation signalling. 737 Client supporting this specification MUST include a Frag-Status = 738 Fragmentation-Supported attribute in the first Access-Request sent to 739 the RADIUS Server, in order to indicate they would accept fragmented 740 data from the sever. This is not required if pre-authorization 741 process was carried out, as it is implicit. 743 The following is an Access-Accept which the RADIUS Server intends to 744 send to a RADIUS Client. However, due to a combination of issues 745 (PMTU, large attributes, etc.), the content does not fit into one 746 Access-Accept packet. 748 Access-Accept 749 User-Name 750 EAP-Message 751 Service-Type(Login) 752 Example-Long-1 [M] 753 Example-Long-1 [M] 754 Example-Long-1 [M] 755 Example-Long-1 [M] 756 Example-Long-1 [M] 757 Example-Long-1 [M] 758 Example-Long-1 [M] 759 Example-Long-1 [M] 760 Example-Long-1 761 Example-Long-2 [M] 762 Example-Long-2 [M] 763 Example-Long-2 764 State = 0xcba00003 766 Figure 8: Desired Access-Accept 768 The RADIUS Server therefore must send the attributes listed above in 769 a series of chunks. The first chunk contains seven (7) attributes 770 from the original Access-Accept, and a Frag-Status attribute. Since 771 last attribute is "Example-Long-1" with the "M" flag set, the 772 chunking process also sets the "T" flag in that attribute. The 773 Access-Accept is sent with a RADIUS Identifier field having value 30 774 corresponding to a previous Access-Request not depicted. The Frag- 775 Status attribute has value More-Data-Pending, to indicate that the 776 RADIUS Server wishes to send more data in a subsequent Access-Accept. 777 The RADIUS Server also adds a Service-Type attribute with value 778 Additional-Authorization, which indicates that it is part of the 779 chunking process. Note that the original Service-Type is not 780 included in this chunk. Finally, a State attribute is included to 781 allow matching subsequent requests with this conversation, and the 782 packet is signed with the Message-Authenticator attribute, completing 783 the maximum number of attributes of 11. 785 Access-Accept (ID = 30) 786 User-Name 787 EAP-Message 788 Example-Long-1 [M] 789 Example-Long-1 [M] 790 Example-Long-1 [M] 791 Example-Long-1 [M] 792 Example-Long-1 [MT] 793 Frag-Status = More-Data-Pending 794 Service-Type = Additional-Authorization 795 State = 0xcba00004 796 Message-Authenticator 798 Figure 9: Access-Accept (chunk 1) 800 Compliant RADIUS Clients receiving this packet will see the Frag- 801 Status attribute, and suspend all authorization handling until all of 802 the chunks have been received. Non-compliant RADIUS Clients should 803 also see the Service-Type indicating the provisioning for an unknown 804 service, and will treat it as an Access-Reject. 806 RADIUS Clients who wish to receive all of the chunks will respond 807 with the following packet, where the value of the State attribute is 808 taken from the received Access-Accept. They also include the User- 809 Name attribute so that non-compliant proxies can process the packet 810 (Section 11.1). 812 Access-Request (ID = 131) 813 User-Name 814 Frag-Status = More-Data-Request 815 Service-Type = Additional-Authorization 816 State = 0xcba00004 817 Message-Authenticator 819 Figure 10: Access-Request (chunk 1) 821 The RADIUS Server receives this request, and uses the State attribute 822 to associate it with an ongoing chunking session. Compliant ASes 823 will then continue the chunking process. Non-compliant ASes will 824 never see a response such as this, as they will never send a Frag- 825 Status attribute. 827 The RADIUS Server continues the chunking process by sending the next 828 chunk, with the final attribute(s) from the original packet. The 829 value of the Identifier field is taken from the received Access- 830 Request. A Frag-Status attribute is not included in the next Access- 831 Accept, as no more chunks are available for sending. The RADIUS 832 Server includes the original State attribute to allow the RADIUS 833 Client to send additional authorization data. The original Service- 834 Type attribute is included as well. 836 Access-Accept (ID = 131) 837 Example-Long-1 [M] 838 Example-Long-1 [M] 839 Example-Long-1 [M] 840 Example-Long-1 841 Example-Long-2 [M] 842 Example-Long-2 [M] 843 Example-Long-2 844 Service-Type = Login 845 State = 0xfda000003 846 Message-Authenticator 848 Figure 11: Access-Accept (chunk 2) 850 On reception of this last chunk, the RADIUS Client matches it with an 851 ongoing session via the Identifier field, and sees that there is no 852 Frag-Status attribute present. It then processes the received 853 attributes as if they had been sent in one RADIUS packet. See 854 Section 8.4 for further details of this process. 856 6. Chunk size 858 In an ideal scenario, each intermediate chunk would be exactly the 859 size limit in length. In this way, the number of round trips 860 required to send a large packet would be optimal. However, this is 861 not possible for several reasons. 863 1. RADIUS attributes have a variable length, and must be included 864 completely in a chunk. Thus, it is possible that, even if there 865 is some free space in the chunk, it is not enough to include the 866 next attribute. This can generate up to 254 octets of spare 867 space on every chunk. 869 2. RADIUS fragmentation requires the introduction of some extra 870 attributes for signalling. Specifically, a Frag-Status attribute 871 (7 octets) is included on every chunk of a packet, except the 872 last one. A RADIUS State attribute (from 3 to 255 octets) is 873 also included in most chunks, to allow the RADIUS Server to bind 874 an Access-Request with a previous Access-Challenge. User-Name 875 attributes (from 3 to 255 octets) are introduced on every chunk 876 the RADIUS Client sends as they are required by the proxies to 877 route the packet to its destination. Together, these attributes 878 can generate from up to 13 to 517 octets of signalling data, 879 reducing the amount of payload information that can be sent on 880 each chunk. 882 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 883 MTU. Otherwise, IP fragmentation may occur, having undesirable 884 consequences. Hence, maximum chunk size would be decreased from 885 4096 to the actual MTU of the network. 887 4. The inclusion of Proxy-State attributes by intermediary proxies 888 can decrease the availability of usable space into the chunk. 889 This is described with further detail in Section 8.1. 891 7. Allowed large packet size 893 There are no provisions for signalling how much data is to be sent 894 via the fragmentation process as a whole. It is difficult to define 895 what is meant by the "length" of any fragmented data. That data can 896 be multiple attributes, which includes RADIUS attribute header 897 fields. Or it can be one or more "large" attributes (more than 256 898 octets in length). Proxies can also filter these attributes, to 899 modify, add, or delete them and their contents. These proxies act on 900 a "packet by packet" basis, and cannot know what kind of filtering 901 actions they take on future packets. As a result, it is impossible 902 to signal any meaningful value for the total amount of additional 903 data. 905 Unauthenticated end users are permitted to trigger the exchange of 906 large amounts of fragmented data between the RADIUS Client and the 907 RADIUS Server, having the potential to allow Denial of Service (DoS) 908 attacks. An attacker could initiate a large number of connections, 909 each of which requests the RADIUS Server to store a large amount of 910 data. This data could cause memory exhaustion on the RADIUS Server, 911 and result in authentic users being denied access. It is worth 912 noting that authentication mechanisms are already designed to avoid 913 exceeding the size limit. 915 Hence, implementations of this specification MUST limit the total 916 amount of data they send and/or receive via this specification. Its 917 default value SHOULD be 100 kilo-octets. Any more than this may turn 918 RADIUS into a generic transport protocol, which is undesired. This 919 limit SHOULD be configurable, so that it can be changed if necessary. 921 Implementations of this specification MUST limit the total number of 922 round trips used during the fragmentation process. Its default value 923 SHOULD be to 25. Any more than this may indicate an implementation 924 error, misconfiguration, or a denial of service (DoS) attack. This 925 limit SHOULD be configurable, so that it can be changed if necessary. 927 For instance, let's imagine the RADIUS Server wants to transport an 928 SAML assertion which is 15000 octets long, to the RADIUS Client. In 929 this hypothetical scenario, we assume there are 3 intermediate 930 proxies, each one inserting a Proxy-State attribute of 20 octets. 931 Also we assume the State attributes generated by the RADIUS Server 932 have a size of 6 octets, and the User-Name attribute take 50 octets. 933 Therefore, the amount of free space in a chunk for the transport of 934 the SAML assertion attributes is: Total (4096) - RADIUS header (20) - 935 User-Name (50 octets) - Frag-Status (7 octets) - Service-Type (6 936 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State 937 (20) - Proxy-State (20) - Message-Authenticator (18 octets), 938 resulting in a total of 3929 octets, that is, 15 attributes of 255 939 bytes. 941 According to [RFC6929], a Long-Extended-Type provides a payload of 942 251 octets. Therefore, the SAML assertion described above would 943 result into 60 attributes, requiring of 4 round-trips to be 944 completely transmitted. 946 8. Handling special attributes 948 8.1. Proxy-State attribute 950 RADIUS proxies may introduce Proxy-State attributes into any Access- 951 Request packet they forward. If they are unable to add this 952 information to the packet, they may silently discard forwarding it to 953 its destination, leading to DoS situations. Moreover, any Proxy- 954 State attribute received by a RADIUS Server in an Access-Request 955 packet MUST be copied into the reply packet to it. For these 956 reasons, Proxy-State attributes require a special treatment within 957 the packet fragmentation mechanism. 959 When the RADIUS Server replies to an Access-Request packet as part of 960 a conversation involving a fragmentation (either a chunk or a request 961 for chunks), it MUST include every Proxy-State attribute received 962 into the reply packet. This means that the RADIUS Server MUST take 963 into account the size of these Proxy-State attributes in order to 964 calculate the size of the next chunk to be sent. 966 However, while a RADIUS Server will always know how much space MUST 967 be left on each reply packet for Proxy-State attributes (as they are 968 directly included by the RADIUS Server), a RADIUS Client cannot know 969 this information, as Proxy-State attributes are removed from the 970 reply packet by their respective proxies before forwarding them back. 971 Hence, RADIUS Clients need a mechanism to discover the amount of 972 space required by proxies to introduce their Proxy-State attributes. 973 In the following we describe a new mechanism to perform such a 974 discovery: 976 1. When a RADIUS Client does not know how much space will be 977 required by intermediate proxies for including their Proxy-State 978 attributes, it SHOULD start using a conservative value (e.g. 1024 979 octets) as the chunk size. 981 2. When the RADIUS Server receives a chunk from the RADIUS Client, 982 it can calculate the total size of the Proxy-State attributes 983 that have been introduced by intermediary proxies along the path. 984 This information MUST be returned to the RADIUS Client in the 985 next reply packet, encoded into a new attribute called Proxy- 986 State-Len. The RADIUS Server MAY artificially increase this 987 quantity in order to handle with situations where proxies behave 988 inconsistently (e.g. they generate Proxy-State attributes with a 989 different size for each packet), or for situations where 990 intermediary proxies remove Proxy-State attributes generated by 991 other proxies. Increasing this value would make the RADIUS 992 Client to leave some free space for these situations. 994 3. The RADIUS Client SHOULD react upon the reception of this 995 attribute by adjusting the maximum size for the next chunk 996 accordingly. However, as the Proxy-State-Len offers just an 997 estimation of the space required by the proxies, the RADIUS 998 Client MAY select a smaller amount in environments known to be 999 problematic. 1001 8.2. State attribute 1003 This RADIUS fragmentation mechanism makes use of the State attribute 1004 to link all the chunks belonging to the same fragmented packet. 1005 However, some considerations are required when the RADIUS Server is 1006 fragmenting a packet that already contains a State attribute for 1007 other purposes not related with the fragmentation. If the procedure 1008 described in Section 5 is followed, two different State attributes 1009 could be included into a single chunk, incurring into two problems. 1010 First, [RFC2865] explicitly forbids that more than one State 1011 attribute appears into a single packet. 1013 A straightforward solution consists on making the RADIUS Server to 1014 send the original State attribute into the last chunk of the sequence 1015 (attributes can be re-ordered as specified in [RFC2865]). As the 1016 last chunk (when generated by the RADIUS Server) does not contain any 1017 State attribute due to the fragmentation mechanism, both situations 1018 described above are avoided. 1020 Something similar happens when the RADIUS Client has to send a 1021 fragmented packet that contains a State attribute on it. The RADIUS 1022 Client MUST assure that this original State is included into the 1023 first chunk sent to the RADIUS Server (as this one never contains any 1024 State attribute due to fragmentation). 1026 8.3. Service-Type attribute 1028 This RADIUS fragmentation mechanism makes use of the Service-Type 1029 attribute to indicate an Access-Accept packet is not granting access 1030 to the service yet, since additional authorization exchange needs to 1031 be performed. Similarly to the State attribute, the RADIUS Server 1032 has to send the original Service-Type attribute into the last Access- 1033 Accept of the RADIUS conversation to avoid ambiguity. 1035 8.4. Rebuilding the original large packet 1037 The RADIUS Client stores the RADIUS attributes received on each chunk 1038 in order to be able to rebuild the original large packet after 1039 receiving the last chunk. However, some of these received attributes 1040 MUST NOT be stored in this list, as they have been introduced as part 1041 of the fragmentation signalling and hence, they are not part of the 1042 original packet. 1044 o State (except the one in the last chunk, if present) 1046 o Service-Type = Additional-Authorization 1048 o Frag-Status 1050 o Proxy-State-Len 1052 Similarly, the RADIUS Server MUST NOT store the following attributes 1053 as part of the original large packet: 1055 o State (except the one in the first chunk, if present) 1057 o Service-Type = Additional-Authorization 1059 o Frag-Status 1061 o Proxy-State (except the ones in the last chunk) 1063 o User-Name (except the one in the first chunk) 1065 9. New flag T field for the Long Extended Type attribute definition 1067 This document defines a new field in the "Long Extended Type" 1068 attribute format. This field is one bit in size, and is called "T" 1069 for Truncation. It indicates that the attribute is intentionally 1070 truncated in this chunk, and is to be continued in the next chunk of 1071 the sequence. The combination of the flags "M" and "T" indicates 1072 that the attribute is fragmented (flag M), but that all the fragments 1073 are not available in this chunk (flag T). Proxies implementing 1074 [RFC6929] will see these attributes as invalid (they will not be able 1075 to reconstruct them), but they will still forward them as [RFC6929] 1076 section 5.2 indicates they SHOULD forward unknown attributes anyway. 1078 As a consequence of this addition, the Reserved field is now 6 bits 1079 long (see Section 12.1 for some considerations). The following 1080 figure represents the new attribute format. 1082 0 1 2 3 1083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Type | Length | Extended-Type |M|T| Reserved | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Value ... 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 12: Updated Long Extended Type attribute format 1092 10. New attribute definition 1094 This document proposes the definition of two new extended type 1095 attributes, called Frag-Status and Proxy-State-Len. The format of 1096 these attributes follows the indications for an Extended Type 1097 attribute defined in [RFC6929]. 1099 10.1. Frag-Status attribute 1101 This attribute is used for fragmentation signalling, and its meaning 1102 depends on the code value transported within it. The following 1103 figure represents the format of the Frag-Status attribute. 1105 1 2 3 1106 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Type | Length | Extended-Type | Code 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Code (cont) | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 Figure 13: Frag-Status format 1115 Type 1116 To be assigned (TBA) 1118 Length 1120 7 1122 Extended-Type 1124 To be assigned (TBA). 1126 Code 1128 4 byte. Integer indicating the code. The values defined in this 1129 specifications are: 1131 0 - Reserved 1133 1 - Fragmentation-Supported 1135 2 - More-Data-Pending 1137 3 - More-Data-Request 1139 This attribute MAY be present in Access-Request, Access-Challenge and 1140 Access-Accept packets. It MUST NOT be included in Access-Reject 1141 packets. RADIUS Clients supporting this specification MUST include a 1142 Frag-Status = Fragmentation-Supported attribute in the first Access- 1143 Request sent to the RADIUS Server, in order to indicate they would 1144 accept fragmented data from the sever. 1146 10.2. Proxy-State-Len attribute 1148 This attribute indicates to the RADIUS Client the length of the 1149 Proxy-State attributes received by the RADIUS Server. This 1150 information is useful to adjust the length of the chunks sent by the 1151 RADIUS Client. The format of this Proxy-State-Len attribute is the 1152 following: 1154 1 2 3 1155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | Type | Length | Extended-Type | Value 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Value (cont) | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Figure 14: Proxy-State-Len format 1164 Type 1166 To be assigned (TBA) 1168 Length 1170 7 1172 Extended-Type 1174 To be assigned (TBA). 1176 Value 1178 4 octets. Total length (in octets) of received Proxy-State 1179 attributes (including headers). 1181 This attribute MAY be present in Access-Challenge and Access-Accept 1182 packets. It MUST NOT be included in Access-Request or Access-Reject 1183 packets. 1185 10.3. Table of attributes 1187 The following table shows the different attributes defined in this 1188 document related with the kind of RADIUS packets where they can be 1189 present. 1191 | Kind of packet | 1192 +-----+-----+-----+-----+ 1193 Attribute Name | Req | Acc | Rej | Cha | 1194 ----------------------+-----+-----+-----+-----+ 1195 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 1196 ----------------------+-----+-----+-----+-----+ 1197 Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | 1198 ----------------------+-----+-----+-----+-----+ 1200 11. Operation with proxies 1202 The fragmentation mechanism defined above is designed to be 1203 transparent to legacy proxies, as long as they do not want to modify 1204 any fragmented attribute. Nevertheless, updated proxies supporting 1205 this specification can even modify fragmented attributes. 1207 11.1. Legacy proxies 1209 As every chunk is indeed a RADIUS packet, legacy proxies treat them 1210 as the rest of packets, routing them to their destination. Proxies 1211 can introduce Proxy-State attributes to Access-Request packets, even 1212 if they are indeed chunks. This will not affect how fragmentation is 1213 managed. The RADIUS Server will include all the received Proxy-State 1214 attributes into the generated response, as described in [RFC2865]. 1215 Hence, proxies do not distinguish between a regular RADIUS packet and 1216 a chunk. 1218 11.2. Updated proxies 1220 Updated proxies can interact with RADIUS Clients and Servers in order 1221 to obtain the complete large packet before starting forwarding it. 1222 In this way, proxies can manipulate (modify and/or remove) any 1223 attribute of the packet, or introduce new attributes, without 1224 worrying about crossing the boundaries of the chunk size. Once the 1225 manipulated packet is ready, it is sent to the original destination 1226 using the fragmentation mechanism (if required). The following 1227 example shows how an updated proxy interacts with the RADIUS Client 1228 to obtain a large Access-Request packet, modify an attribute 1229 resulting into an even more large packet, and interacts with the 1230 RADIUS Server to complete the transmission of the modified packet. 1232 +-+-+-+-+-+ +-+-+-+-+-+ 1233 | RADIUS | | RADIUS | 1234 | Client | | Proxy | 1235 +-+-+-+-+-+ +-+-+-+-+-+ 1236 | | 1237 | Access-Request(1){User-Name,Calling-Station-Id, | 1238 | Example-Long-1[M],Example-Long-1[M], | 1239 | Example-Long-1[M],Example-Long-1[M], | 1240 | Example-Long-1[MT],Frag-Status(MDP)} | 1241 |--------------------------------------------------->| 1242 | | 1243 | Access-Challenge(1){User-Name, | 1244 | Frag-Status(MDR),State1} | 1245 |<---------------------------------------------------| 1246 | | 1247 | Access-Request(2)(User-Name,State1, | 1248 | Example-Long-1[M],Example-Long-1[M], | 1249 | Example-Long-1[M],Example-Long-1} | 1250 |--------------------------------------------------->| 1252 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 1253 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 1255 Figure 15: Updated proxy interacts with RADIUS Client 1257 +-+-+-+-+-+ +-+-+-+-+-+ 1258 | RADIUS | | RADIUS | 1259 | Proxy | | Server | 1260 +-+-+-+-+-+ +-+-+-+-+-+ 1261 | | 1262 | Access-Request(3){User-Name,Calling-Station-Id, | 1263 | Example-Long-1[M],Example-Long-1[M], | 1264 | Example-Long-1[M],Example-Long-1[M], | 1265 | Example-Long-1[MT],Frag-Status(MDP)} | 1266 |--------------------------------------------------->| 1267 | | 1268 | Access-Challenge(1){User-Name, | 1269 | Frag-Status(MDR),State2} | 1270 |<---------------------------------------------------| 1271 | | 1272 | Access-Request(4){User-Name,State2, | 1273 | Example-Long-1[M],Example-Long-1[M], | 1274 | Example-Long-1[M],Example-Long-1[M], | 1275 | Example-Long-1[MT],Frag-Status(MDP)} | 1276 |--------------------------------------------------->| 1277 | | 1278 | Access-Challenge(1){User-Name, | 1279 | Frag-Status(MDR),State3} | 1280 |<---------------------------------------------------| 1281 | | 1282 | Access-Request(5){User-Name,State3,Example-Long-1} | 1283 |--------------------------------------------------->| 1285 Figure 16: Updated proxy interacts with RADIUS Server 1287 12. General considerations 1289 12.1. Flag T 1291 As described in Section 9, this document modifies the definition of 1292 the "Reserved" field of the "Long Extended Type" attribute [RFC6929], 1293 by allocating an additional flag "T". The meaning and position of 1294 this flag is defined in this document, and nowhere else. This might 1295 generate an issue if subsequent specifications want to allocate a new 1296 flag as well, as there would be no direct way for them to know which 1297 parts of the "Reserved" field have already been defined. 1299 An immediate and reasonable solution for this issue would be 1300 declaring that this RFC updates [RFC6929]. In this way, [RFC6929] 1301 would include an "Updated by" clause that will point readers to this 1302 document. Another alternative would be creating an IANA registry for 1303 the "Reserved" field. However, the working group thinks that would 1304 be overkill, as not such a great number of specifications extending 1305 that field are expected. 1307 Hence, we have decided to include the "Updates" clause in the 1308 document so far. Note that if this experiment does not succeed, the 1309 "T" flag allocation would not persist, as it is tightly associated to 1310 this document. 1312 12.2. Violation of RFC2865 1314 Section 5.1 indicates that all authorization and authentication 1315 handling will be postponed until all the chunks have been received. 1316 This postponement also affects to the verification that the Access- 1317 Request packet contains some kind of authentication attribute (e.g. 1318 User-Password, CHAP-Password, State or other future attribute), as 1319 required by [RFC2865]. This checking will therefore be delayed until 1320 the original large packet has been rebuilt, as some of the chunks may 1321 not contain any of them. 1323 The authors acknowledge that this specification violates the "MUST" 1324 requirement of [RFC2865] Section 4.1 that states that "An Access- 1325 Request MUST contain either a User-Password or a CHAP- Password or a 1326 State". We note that a proxy which enforces that requirement would 1327 be unable to support future RADIUS authentication extensions. 1328 Extensions to the protocol would therefore be impossible to deploy. 1329 All known implementations have chosen the philosophy of "be liberal 1330 in what you accept". That is, they accept traffic which violates the 1331 requirement of [RFC2865] Section 4.1. We therefore expect to see no 1332 operational issues with this specification. After we gain more 1333 operational experience with this specification, it can be re-issued 1334 as a standards track document, and update [RFC2865]. 1336 12.3. Proxying based on User-Name 1338 This proposal assumes legacy proxies to base their routing decisions 1339 on the value of the User-Name attribute. For this reason, every 1340 packet sent from the RADIUS Client to the RADIUS Server (either 1341 chunks or requests for more chunks) MUST contain a User-Name 1342 attribute. 1344 12.4. Transport behaviour 1346 This proposal does not modify the way RADIUS interacts with the 1347 underlying transport (UDP). That is, RADIUS keeps following a lock- 1348 step behaviour, that requires receiving an explicit acknowledge for 1349 each chunk sent. Hence, bursts of traffic which could congest links 1350 between peers are not an issue. 1352 13. Security Considerations 1354 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1355 RADIUS security is problematic. This specification changes nothing 1356 related to the security of the RADIUS protocol. It requires that all 1357 Access-Request packets associated with fragmentation are 1358 authenticated using the existing Message-Authenticator attribute. 1359 This signature prevents forging and replay, to the limits of the 1360 existing security. 1362 The ability to send bulk data from one party to another creates new 1363 security considerations. RADIUS Clients and Servers may have to 1364 store large amounts of data per session. The amount of this data can 1365 be significant, leading to the potential for resource exhaustion. We 1366 therefore suggest that implementations limit the amount of bulk data 1367 stored per session. The exact method for this limitation is 1368 implementation-specific. Section 7 gives some indications on what 1369 could be reasonable limits. 1371 The bulk data can often be pushed off to storage methods other than 1372 the memory of the RADIUS implementation. For example, it can be 1373 stored in an external database, or in files. This approach mitigates 1374 the resource exhaustion issue, as RADIUS Servers today already store 1375 large amounts of accounting data. 1377 14. IANA Considerations 1379 The authors request that Attribute Types and Attribute Values defined 1380 in this document be registered by the Internet Assigned Numbers 1381 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1382 Considerations" section of [RFC3575], in accordance with BCP 26 1383 [RFC5226]. For RADIUS packets, attributes and registries created by 1384 this document IANA is requested to place them at 1385 http://www.iana.org/assignments/radius-types. 1387 In particular, this document defines two new RADIUS attributes, 1388 entitled "Frag-Status" and "Proxy-State-Len" (see section 9), 1389 assigned values of TBD1 and TBD2 from the Long Extended Space of 1390 [RFC6929]: 1392 Tag Name Length Meaning 1393 ---- ---- ------ ------- 1394 TBD1 Frag-Status 7 Signals fragmentation 1395 TBD2 Proxy-State-Len 7 Indicates the length of the 1396 received Proxy-State attributes 1398 The Frag-Status attribute also defines a 8-bit "Code" field, for 1399 which the IANA is to create and maintain a new sub-registry entitled 1400 "Code values" under the RADIUS "Frag-Status" attribute. Initial 1401 values for the RADIUS Frag-Status "Code" registry are given below; 1402 future assignments are to be made through "RFC required" [RFC5226]. 1403 Assignments consist of a Frag-Status "Code" name and its associated 1404 value. 1406 Value Frag-Status Code Name Definition 1407 ---- ------------------------ ---------- 1408 0 Reserved See Section 9.1 1409 1 Fragmentation-Supported See Section 9.1 1410 2 More-Data-Pending See Section 9.1 1411 3 More-Data-Request See Section 9.1 1412 4-255 Unassigned 1414 Additionally, allocation of a new Service-Type value for "Additional- 1415 Authorization" is requested. 1417 Value Service Type Value Definition 1418 ---- ------------------------ ---------- 1419 TBA Additional-Authorization See section 4.1 1421 15. Acknowledgements 1423 The authors would like to thank the members of the RADEXT working 1424 group who have contributed to the development of this specification, 1425 either by participating on the discussions on the mailing lists or by 1426 sending comments about our RFC. 1428 The authors also thank David Cuenca (University of Murcia) for 1429 implementing a proof of concept implementation of this RFC that has 1430 been useful to improve the quality of the specification. 1432 This work has been partly funded by the GEANT GN3+ SA5 and CLASSe 1433 (http://sec.cs.kent.ac.uk/CLASSe/) projects. 1435 16. References 1437 16.1. Normative References 1439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1440 Requirement Levels", BCP 14, RFC 2119, March 1997. 1442 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1443 "Remote Authentication Dial In User Service (RADIUS)", 1444 RFC 2865, June 2000. 1446 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1447 Authentication Dial In User Service)", RFC 3575, 1448 July 2003. 1450 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1451 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1452 May 2008. 1454 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1455 BCP 158, RFC 6158, March 2011. 1457 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1458 Service (RADIUS) Protocol Extensions", RFC 6929, 1459 April 2013. 1461 16.2. Informative References 1463 [I-D.ietf-abfab-aaa-saml] 1464 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 1465 Profiles, Name Identifier Format, and Confirmation Methods 1466 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 1467 progress), February 2014. 1469 [I-D.ietf-abfab-arch] 1470 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1471 Schaad, "Application Bridging for Federated Access Beyond 1472 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1473 in progress), July 2014. 1475 [I-D.ietf-radext-bigger-packets] 1476 Hartman, S., "Larger Packets for RADIUS over TCP", 1477 draft-ietf-radext-bigger-packets-01 (work in progress), 1478 July 2014. 1480 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1482 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1483 Dial In User Service) Support For Extensible 1484 Authentication Protocol (EAP)", RFC 3579, September 2003. 1486 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1487 Rule Attribute", RFC 4849, April 2007. 1489 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1490 Dial In User Service (RADIUS) Implementation Issues and 1491 Suggested Fixes", RFC 5080, December 2007. 1493 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1495 Aboba, "Dynamic Authorization Extensions to Remote 1496 Authentication Dial In User Service (RADIUS)", RFC 5176, 1497 January 2008. 1499 Authors' Addresses 1501 Alejandro Perez-Mendez (Ed.) 1502 University of Murcia 1503 Campus de Espinardo S/N, Faculty of Computer Science 1504 Murcia, 30100 1505 Spain 1507 Phone: +34 868 88 46 44 1508 Email: alex@um.es 1510 Rafa Marin-Lopez 1511 University of Murcia 1512 Campus de Espinardo S/N, Faculty of Computer Science 1513 Murcia, 30100 1514 Spain 1516 Phone: +34 868 88 85 01 1517 Email: rafa@um.es 1519 Fernando Pereniguez-Garcia 1520 University of Murcia 1521 Campus de Espinardo S/N, Faculty of Computer Science 1522 Murcia, 30100 1523 Spain 1525 Phone: +34 868 88 78 82 1526 Email: pereniguez@um.es 1528 Gabriel Lopez-Millan 1529 University of Murcia 1530 Campus de Espinardo S/N, Faculty of Computer Science 1531 Murcia, 30100 1532 Spain 1534 Phone: +34 868 88 85 04 1535 Email: gabilm@um.es 1536 Diego R. Lopez 1537 Telefonica I+D 1538 Don Ramon de la Cruz, 84 1539 Madrid, 28006 1540 Spain 1542 Phone: +34 913 129 041 1543 Email: diego@tid.es 1545 Alan DeKok 1546 Network RADIUS 1547 15 av du Granier 1548 Meylan, 38240 1549 France 1551 Phone: +34 913 129 041 1552 Email: aland@networkradius.com 1553 URI: http://networkradius.com