idnits 2.17.1 draft-ietf-radext-radius-fragmentation-12.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2015) is 3376 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1287, but not defined == Missing Reference: 'MT' is mentioned on line 1288, 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 (==), 1 comment (--). 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 Intended status: Experimental F. Pereniguez-Garcia 5 Expires: July 30, 2015 G. Lopez-Millan 6 University of Murcia 7 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 January 26, 2015 13 Support of fragmentation of RADIUS packets 14 draft-ietf-radext-radius-fragmentation-12 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 30, 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 . . . . . . . . . . . . . . . . . . . . 13 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-Length attribute . . . . . . . . . . . . . . . 26 82 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 83 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 84 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 28 85 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 86 12. General considerations . . . . . . . . . . . . . . . . . . . . 30 87 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 31 89 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 31 90 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 31 91 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 92 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 93 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 96 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 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 A proper "Updates" clause will be included for these modifications 251 when/if the experiment is successful and this document is re-issued 252 as a Standards Track document. 254 3. Scope of this document 256 This specification describes how a RADIUS Client and a RADIUS Server 257 can exchange data exceeding the 4096 octet limit imposed by one 258 packet. However, the mechanism described in this specification 259 SHOULD NOT be used to exchange more than 100 kilo-octets of data. 260 Any more than this may turn RADIUS into a generic transport protocol, 261 such as TCP or SCTP, which is undesired. Experience shows that 262 attempts to transport bulk data across the Internet with UDP will 263 inevitably fail, unless they re-implement all of the behavior of TCP. 264 The underlying design of RADIUS lacks the proper retransmission 265 policies or congestion control mechanisms which would make it a 266 competitor to TCP. 268 Therefore, RADIUS/UDP transport is by design unable to transport bulk 269 data. It is both undesired and impossible to change the protocol at 270 this point in time. This specification is intended to allow the 271 transport of more than 4096 octets of data through existing RADIUS/ 272 UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a 273 "green field" deployment requires the transport of bulk data. 275 Section 7, below, describes with further details the reasoning for 276 this limitation, and recommends administrators to adjust it according 277 to the specific capabilities of their existing systems in terms of 278 memory and processing power. 280 Moreover, its scope is limited to the exchange of authorization data, 281 as other exchanges do not require of such a mechanism. In 282 particular, authentication exchanges have already been defined to 283 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 284 represent the most critical part of a RADIUS conversation, it is 285 preferable to not introduce any modification to their operation that 286 may affect existing equipment. 288 There is no need to fragment accounting packets either. While the 289 accounting process can send large amounts of data, that data is 290 typically composed of many small updates. That is, there is no 291 demonstrated need to send indivisible blocks of more than 4 kilo- 292 octets of data. The need to send large amounts of data per user 293 session often originates from the need for flow-based accounting. In 294 this use-case, the RADIUS Client may send accounting data for many 295 thousands of flows, where all those flows are tied to one user 296 session. The existing Acct-Multi-Session-Id attribute defined in 297 [RFC2866] Section 5.11 has been proven to work here. 299 Similarly, there is no need to fragment Change of Authorization (CoA) 300 [RFC5176] packets. Instead, according to [RFC5176] the CoA client 301 will send a CoA-Request packet containing session identification 302 attributes, along with Service-Type = Additional-Authorization, and a 303 State attribute. Implementations not supporting fragmentation will 304 respond with a CoA-NAK, and an Error-Cause of Unsupported-Service. 306 The above requirement does not assume that the CoA client and the 307 RADIUS Server are co-located. They may, in fact be run on separate 308 parts of the infrastructure, or even by separate administrators. 309 There is, however, a requirement that the two communicate. We can 310 see that the CoA client needs to send session identification 311 attributes in order to send CoA packets. These attributes cannot be 312 known a priori by the CoA client, and can only come from the RADIUS 313 Server. Therefore, even when the two systems are not co-located, 314 they must be able to communicate in order to operate in unison. The 315 alternative is for the two systems to have differing views of the 316 users authorization parameters, which is a security disaster. 318 This specification does not allow for fragmentation of CoA packets. 319 Allowing for fragmented CoA packets would involve changing multiple 320 parts of the RADIUS protocol, with the corresponding possibility for 321 implementation issues, mistakes, etc. 323 Where CoA clients (i.e. RADIUS Servers) need to send large amounts 324 of authorization data to a CoA server (i.e. RADIUS Client), they 325 need only send a minimal CoA-Request packet, containing Service-Type 326 of Authorize-Only, as per [RFC5176], along with session 327 identification attributes. This CoA packet serves as a signal to the 328 RADIUS Client that the users' session requires re-authorization. 329 When the RADIUS Client re-authorizes the user via Access-Request, the 330 RADIUS Server can perform fragmentation, and send large amounts of 331 authorization data to the RADIUS Client. 333 The assumption in the above scenario is that the CoA client and 334 RADIUS Server are co-located, or at least strongly coupled. That is, 335 the path from CoA client to CoA server SHOULD be the exact reverse of 336 the path from RADIUS Client to RADIUS Server. The following diagram 337 will hopefully clarify the roles: 339 +----------------+ 340 | RADIUS CoA | 341 | Client Server | 342 +----------------+ 343 | ^ 344 Access-Request | | CoA-Request 345 v | 346 +----------------+ 347 | RADIUS CoA | 348 | Server Client | 349 +----------------+ 351 Where there is a proxy involved: 353 +----------------+ 354 | RADIUS CoA | 355 | Client Server | 356 +----------------+ 357 | ^ 358 Access-Request | | CoA-Request 359 v | 360 +----------------+ 361 | RADIUS CoA | 362 | Proxy Proxy | 363 +----------------+ 364 | ^ 365 Access-Request | | CoA-Request 366 v | 367 +----------------+ 368 | RADIUS CoA | 369 | Server Client | 370 +----------------+ 372 That is, the RADIUS and CoA subsystems at each hop are strongly 373 connected. Where they are not strongly connected, it will be 374 impossible to use CoA-Request packets to transport large amounts of 375 authorization data. 377 This design is more complicated than allowing for fragmented CoA 378 packets. However, the CoA client and the RADIUS Server must 379 communicate even when not using this specification. We believe that 380 standardizing that communication, and using one method for exchange 381 of large data is preferred to unspecified communication methods and 382 multiple ways of achieving the same result. If we were to allow 383 fragmentation of data over CoA packets, the size and complexity of 384 this specification would increase significantly. 386 The above requirement solves a number of issues. It clearly 387 separates session identification from authorization. Without this 388 separation, it is difficult to both identify a session, and change 389 its authorization using the same attribute. It also ensures that the 390 authorization process is the same for initial authentication, and for 391 CoA. 393 4. Overview 395 Authorization exchanges can occur either before or after end user 396 authentication has been completed. An authorization exchange before 397 authentication allows a RADIUS Client to provide the RADIUS Server 398 with information that MAY modify how the authentication process will 399 be performed (e.g. it may affect the selection of the EAP method). 400 An authorization exchange after authentication allows the RADIUS 401 Server to provide the RADIUS Client with information about the end 402 user, the results of the authentication process and/or obligations to 403 be enforced. In this specification we refer to the "pre- 404 authorization" as the exchange of authorization information before 405 the end user authentication has started (from the RADIUS Client to 406 the RADIUS Server), whereas the term "post-authorization" is used to 407 refer to an authorization exchange happening after this 408 authentication process (from the RADIUS Server to the RADIUS Client). 410 In this specification we refer to the "size limit" as the practical 411 limit on RADIUS packet sizes. This limit is the minimum between 4096 412 octets and the current PMTU. We define below a method which uses 413 Access-Request and Access-Accept in order to exchange fragmented 414 data. The RADIUS Client and server exchange a series of Access- 415 Request / Access-Accept packets, until such time as all of the 416 fragmented data has been transported. Each packet contains a Frag- 417 Status attribute which lets the other party know if fragmentation is 418 desired, ongoing, or finished. Each packet may also contain the 419 fragmented data, or instead be an "ACK" to a previous fragment from 420 the other party. Each Access-Request contains a User-Name attribute, 421 allowing the packet to be proxied if necessary (see Section 11.1). 422 Each Access-Request may also contain a State attribute, which serves 423 to tie it to a previous Access-Accept. Each Access-Accept contains a 424 State attribute, for use by the RADIUS Client in a later Access- 425 Request. Each Access-Accept contains a Service-Type attribute with 426 the "Additional-Authorization" value. This indicates that the 427 service being provided is part of a fragmented exchange, and that the 428 Access-Accept should not be interpreted as providing network access 429 to the end user. 431 When a RADIUS Client or RADIUS Server need to send data that exceeds 432 the size limit, the mechanism proposed in this document is used. 433 Instead of encoding one large RADIUS packet, a series of smaller 434 RADIUS packets of the same type are encoded. Each smaller packet is 435 called a "chunk" in this specification, in order to distinguish it 436 from traditional RADIUS packets. The encoding process is a simple 437 linear walk over the attributes to be encoded. This walk preserves 438 the order of the attributes of the same type, as required by 439 [RFC2865]. The number of attributes encoded in a particular chunk 440 depends on the size limit, the size of each attribute, the number of 441 proxies between the RADIUS Client and RADIUS Server, and the overhead 442 for fragmentation signalling attributes. Specific details are given 443 in Section 6. A new attribute called Frag-Status (Section 10.1) 444 signals the fragmentation status. 446 After the first chunk is encoded, it is sent to the other party. The 447 packet is identified as a chunk via the Frag-Status attribute. The 448 other party then requests additional chunks, again using the Frag- 449 Status attribute. This process is repeated until all the attributes 450 have been sent from one party to the other. When all the chunks have 451 been received, the original list of attributes is reconstructed and 452 processed as if it had been received in one packet. 454 The reconstruction process is performed by simply appending all of 455 the chunks together. Unlike IPv4 fragmentation, there is no 456 "fragment offset" field. The chunks in this specification are 457 explicitly ordered, as RADIUS is a lock-step protocol, as noted in 458 Section Section 12.4. That is, chunk N+1 cannot be sent until all of 459 the chunks up to and including N have been received and acknowledged. 461 When multiple chunks are sent, a special situation may occur for 462 Extended Type attributes as defined in [RFC6929]. The fragmentation 463 process may split a fragmented attribute across two or more chunks, 464 which is not permitted by that specification. We address this issue 465 by using the newly defined flag "T" in the Reserved field of the 466 "Long Extended Type" attribute format (see Section 9 for further 467 details on this flag). 469 This last situation is expected to be the most common occurrence in 470 chunks. Typically, packet fragmentation will occur as a consequence 471 of a desire to send one or more large (and therefore fragmented) 472 attributes. The large attribute will likely be split into two or 473 more pieces. Where chunking does not split a fragmented attribute, 474 no special treatment is necessary. 476 The setting of the "T" flag is the only case where the chunking 477 process affects the content of an attribute. Even then, the "Value" 478 fields of all attributes remain unchanged. Any per-packet security 479 attributes such as Message-Authenticator are calculated for each 480 chunk independently. There are neither integrity nor security checks 481 performed on the "original" packet. 483 Each RADIUS packet sent or received as part of the chunking process 484 MUST be a valid packet, subject to all format and security 485 requirements. This requirement ensures that a "transparent" proxy 486 not implementing this specification can receive and send compliant 487 packets. That is, a proxy which simply forwards packets without 488 detailed examination or any modification will be able to proxy 489 "chunks". 491 5. Fragmentation of packets 493 When the RADIUS Client or the RADIUS Server desires to send a packet 494 that exceeds the size limit, it is split into chunks and sent via 495 multiple client/server exchanges. The exchange is indicated via the 496 Frag-Status attribute, which has value More-Data-Pending for all but 497 the last chunk of the series. The chunks are tied together via the 498 State attribute. 500 The delivery of a large fragmented RADIUS packet with authorization 501 data can happen before or after the end user has been authenticated 502 by the RADIUS Server. We can distinguish two phases, which can be 503 omitted if there is no authorization data to be sent: 505 1. Pre-authorization. In this phase, the RADIUS Client MAY send a 506 large packet with authorization information to the RADIUS Server 507 before the end user is authenticated. Only the RADIUS Client is 508 allowed to send authorization data during this phase. 510 2. Post-authorization. In this phase, the RADIUS Server MAY send a 511 large packet with authorization data to the RADIUS Client after 512 the end user has been authenticated. Only the RADIUS Server is 513 allowed to send authorization data during this phase. 515 The following subsections describe how to perform fragmentation for 516 packets for these two phases, pre-authorization and post- 517 authorization. We give the packet type, along with a RADIUS 518 Identifier, to indicate that requests and responses are connected. 519 We then give a list of attributes. We do not give values for most 520 attributes, as we wish to concentrate on the fragmentation behaviour, 521 rather than packet contents. Attribute values are given for 522 attributes relevant to the fragmentation process. Where "long 523 extended" attributes are used, we indicate the M (More) and T 524 (Truncation) flags as optional square brackets after the attribute 525 name. As no "long extended" attributes have yet been defined, we use 526 example attributes, named as "Example-Long-1", etc. The maximum 527 chunk size is established in term of number of attributes (11), for 528 sake of simplicity. 530 5.1. Pre-authorization 532 When the RADIUS Client needs to send a large amount of data to the 533 RADIUS Server, the data to be sent is split into chunks and sent to 534 the RADIUS Server via multiple Access-Request / Access-Accept 535 exchanges. The example below shows this exchange. 537 The following is an Access-Request which the RADIUS Client intends to 538 send to a RADIUS Server. However, due to a combination of issues 539 (PMTU, large attributes, etc.), the content does not fit into one 540 Access-Request packet. 542 Access-Request 543 User-Name 544 NAS-Identifier 545 Calling-Station-Id 546 Example-Long-1 [M] 547 Example-Long-1 [M] 548 Example-Long-1 [M] 549 Example-Long-1 [M] 550 Example-Long-1 [M] 551 Example-Long-1 [M] 552 Example-Long-1 [M] 553 Example-Long-1 [M] 554 Example-Long-1 555 Example-Long-2 [M] 556 Example-Long-2 [M] 557 Example-Long-2 559 Figure 1: Desired Access-Request 561 The RADIUS Client therefore must send the attributes listed above in 562 a series of chunks. The first chunk contains eight (8) attributes 563 from the original Access-Request, and a Frag-Status attribute. Since 564 last attribute is "Example-Long-1" with the "M" flag set, the 565 chunking process also sets the "T" flag in that attribute. The 566 Access-Request is sent with a RADIUS Identifier field having value 567 23. The Frag-Status attribute has value More-Data-Pending, to 568 indicate that the RADIUS Client wishes to send more data in a 569 subsequent Access-Request. The RADIUS Client also adds a Service- 570 Type attribute, which indicates that it is part of the chunking 571 process. The packet is signed with the Message-Authenticator 572 attribute, completing the maximum number of attributes (11). 574 Access-Request (ID = 23) 575 User-Name 576 NAS-Identifier 577 Calling-Station-Id 578 Example-Long-1 [M] 579 Example-Long-1 [M] 580 Example-Long-1 [M] 581 Example-Long-1 [M] 582 Example-Long-1 [MT] 583 Frag-Status = More-Data-Pending 584 Service-Type = Additional-Authorization 585 Message-Authenticator 587 Figure 2: Access-Request (chunk 1) 589 Compliant RADIUS Servers (i.e. servers implementing fragmentation) 590 receiving this packet will see the Frag-Status attribute, and 591 postpone all authorization and authentication handling until all of 592 the chunks have been received. This postponement also affects to the 593 verification that the Access-Request packet contains some kind of 594 authentication attribute (e.g. User-Password, CHAP-Password, State 595 or other future attribute), as required by [RFC2865] (see 596 Section 12.2 for more information on this). 598 Non-compliant RADIUS Servers (i.e. servers not implementing 599 fragmentation) should also see the Service-Type requesting 600 provisioning for an unknown service, and return Access-Reject. Other 601 non-compliant RADIUS Servers may return an Access-Reject, Access- 602 Challenge, or an Access-Accept with a particular Service-Type other 603 than Additional-Authorization. Compliant RADIUS Client 604 implementations MUST treat these responses as if they had received 605 Access-Reject instead. 607 Compliant RADIUS Servers who wish to receive all of the chunks will 608 respond with the following packet. The value of the State here is 609 arbitrary, and serves only as a unique token for example purposes. 610 We only note that it MUST be temporally unique to the RADIUS Server. 612 Access-Accept (ID = 23) 613 Frag-Status = More-Data-Request 614 Service-Type = Additional-Authorization 615 State = 0xabc00001 616 Message-Authenticator 618 Figure 3: Access-Accept (chunk 1) 620 The RADIUS Client will see this response, and use the RADIUS 621 Identifier field to associate it with an ongoing chunking session. 623 Compliant NASes will then continue the chunking process. Non- 624 compliant NASes will never see a response such as this, as they will 625 never send a Frag-Status attribute. The Service-Type attribute is 626 included in the Access-Accept in order to signal that the response is 627 part of the chunking process. This packet therefore does not 628 provision any network service for the end user. 630 The RADIUS Client continues the process by sending the next chunk, 631 which includes an additional six (6) attributes from the original 632 packet. It again includes the User-Name attribute, so that non- 633 compliant proxies can process the packet (see Section 11.1). It sets 634 the Frag-Status attribute to More-Data-Pending, as more data is 635 pending. It includes a Service-Type for reasons described above. It 636 includes the State attribute from the previous Access-accept. It 637 signs the packet with Message-Authenticator, as there are no 638 authentication attributes in the packet. It uses a new RADIUS 639 Identifier field. 641 Access-Request (ID = 181) 642 User-Name 643 Example-Long-1 [M] 644 Example-Long-1 [M] 645 Example-Long-1 [M] 646 Example-Long-1 647 Example-Long-2 [M] 648 Example-Long-2 [MT] 649 Frag-Status = More-Data-Pending 650 Service-Type = Additional-Authorization 651 State = 0xabc000001 652 Message-Authenticator 654 Figure 4: Access-Request (chunk 2) 656 Compliant RADIUS Servers receiving this packet will see the Frag- 657 Status attribute, and look for a State attribute. Since one exists 658 and it matches a State sent in an Access-Accept, this packet is part 659 of a chunking process. The RADIUS Server will associate the 660 attributes with the previous chunk. Since the Frag-Status attribute 661 has value More-Data-Request, the RADIUS Server will respond with an 662 Access-Accept as before. It MUST include a State attribute, with a 663 value different from the previous Access-Accept. This State MUST 664 again be globally and temporally unique. 666 Access-Accept (ID = 181) 667 Frag-Status = More-Data-Request 668 Service-Type = Additional-Authorization 669 State = 0xdef00002 670 Message-Authenticator 672 Figure 5: Access-Accept (chunk 2) 674 The RADIUS Client will see this response, and use the RADIUS 675 Identifier field to associate it with an ongoing chunking session. 676 The RADIUS Client continues the chunking process by sending the next 677 chunk, with the final attribute(s) from the original packet, and 678 again includes the original User-Name attribute. The Frag-Status 679 attribute is not included in the next Access-Request, as no more 680 chunks are available for sending. The RADIUS Client includes the 681 State attribute from the previous Access-accept. It signs the packet 682 with Message-Authenticator, as there are no authentication attributes 683 in the packet. It again uses a new RADIUS Identifier field. 685 Access-Request (ID = 241) 686 User-Name 687 Example-Long-2 688 State = 0xdef00002 689 Message-Authenticator 691 Figure 6: Access-Request (chunk 3) 693 On reception of this last chunk, the RADIUS Server matches it with an 694 ongoing session via the State attribute, and sees that there is no 695 Frag-Status attribute present. It then processes the received 696 attributes as if they had been sent in one RADIUS packet. See 697 Section 8.4 for further details of this process. It generates the 698 appropriate response, which can be either Access-Accept or Access- 699 Reject. In this example, we show an Access-Accept. The RADIUS 700 Server MUST send a State attribute, which permits link the received 701 data with the authentication process. 703 Access-Accept (ID = 241) 704 State = 0x98700003 705 Message-Authenticator 707 Figure 7: Access-Accept (chunk 3) 709 The above example shows in practice how the chunking process works. 710 We re-iterate the implementation and security requirements here. 712 Each chunk is a valid RADIUS packet (see Section 12.2 for some 713 considerations about this), and all RADIUS format and security 714 requirements MUST be followed before any chunking process is applied. 716 Every chunk except for the last one from a RADIUS Client MUST include 717 a Frag-Status attribute, with value More-Data-Pending. The last 718 chunk MUST NOT contain a Frag-Status attribute. Each chunk except 719 for the last from a RADIUS Client MUST include a Service-Type 720 attribute, with value Additional-Authorization. Each chunk MUST 721 include a User-Name attribute, which MUST be identical in all chunks. 722 Each chunk except for the first one from a RADIUS Client MUST include 723 a State attribute, which MUST be copied from a previous Access- 724 Accept. 726 Each Access-Accept MUST include a State attribute. The value for 727 this attribute MUST change in every new Access-Accept, and MUST be 728 globally and temporally unique. 730 5.2. Post-authorization 732 When the RADIUS Server wants to send a large amount of authorization 733 data to the RADIUS Client after authentication, the operation is very 734 similar to the pre-authorization one. The presence of Service-Type = 735 Additional-Authorization attribute ensures that a RADIUS Client not 736 supporting this specification will treat that unrecognized Service- 737 Type as though an Access-Reject had been received instead ([RFC2865] 738 Section 5.6). If the original large Access-Accept packet contained a 739 Service-Type attribute, it will be included with its original value 740 in the last transmitted chunk, to avoid confusion with the one used 741 for fragmentation signalling. It is RECOMMENDED that RADIUS Servers 742 include a State attribute on their original Access-Accept packets, 743 even if fragmentation is not taking place, to allow the RADIUS Client 744 to send additional authorization data in subsequent exchanges. This 745 State attribute would be included in the last transmitted chunk, to 746 avoid confusion with the ones used for fragmentation signalling. 748 Client supporting this specification MUST include a Frag-Status = 749 Fragmentation-Supported attribute in the first Access-Request sent to 750 the RADIUS Server, in order to indicate they would accept fragmented 751 data from the sever. This is not required if pre-authorization 752 process was carried out, as it is implicit. 754 The following is an Access-Accept which the RADIUS Server intends to 755 send to a RADIUS Client. However, due to a combination of issues 756 (PMTU, large attributes, etc.), the content does not fit into one 757 Access-Accept packet. 759 Access-Accept 760 User-Name 761 EAP-Message 762 Service-Type(Login) 763 Example-Long-1 [M] 764 Example-Long-1 [M] 765 Example-Long-1 [M] 766 Example-Long-1 [M] 767 Example-Long-1 [M] 768 Example-Long-1 [M] 769 Example-Long-1 [M] 770 Example-Long-1 [M] 771 Example-Long-1 772 Example-Long-2 [M] 773 Example-Long-2 [M] 774 Example-Long-2 775 State = 0xcba00003 777 Figure 8: Desired Access-Accept 779 The RADIUS Server therefore must send the attributes listed above in 780 a series of chunks. The first chunk contains seven (7) attributes 781 from the original Access-Accept, and a Frag-Status attribute. Since 782 last attribute is "Example-Long-1" with the "M" flag set, the 783 chunking process also sets the "T" flag in that attribute. The 784 Access-Accept is sent with a RADIUS Identifier field having value 30 785 corresponding to a previous Access-Request not depicted. The Frag- 786 Status attribute has value More-Data-Pending, to indicate that the 787 RADIUS Server wishes to send more data in a subsequent Access-Accept. 788 The RADIUS Server also adds a Service-Type attribute with value 789 Additional-Authorization, which indicates that it is part of the 790 chunking process. Note that the original Service-Type is not 791 included in this chunk. Finally, a State attribute is included to 792 allow matching subsequent requests with this conversation, and the 793 packet is signed with the Message-Authenticator attribute, completing 794 the maximum number of attributes of 11. 796 Access-Accept (ID = 30) 797 User-Name 798 EAP-Message 799 Example-Long-1 [M] 800 Example-Long-1 [M] 801 Example-Long-1 [M] 802 Example-Long-1 [M] 803 Example-Long-1 [MT] 804 Frag-Status = More-Data-Pending 805 Service-Type = Additional-Authorization 806 State = 0xcba00004 807 Message-Authenticator 809 Figure 9: Access-Accept (chunk 1) 811 Compliant RADIUS Clients receiving this packet will see the Frag- 812 Status attribute, and suspend all authorization handling until all of 813 the chunks have been received. Non-compliant RADIUS Clients should 814 also see the Service-Type indicating the provisioning for an unknown 815 service, and will treat it as an Access-Reject. 817 RADIUS Clients who wish to receive all of the chunks will respond 818 with the following packet, where the value of the State attribute is 819 taken from the received Access-Accept. They also include the User- 820 Name attribute so that non-compliant proxies can process the packet 821 (Section 11.1). 823 Access-Request (ID = 131) 824 User-Name 825 Frag-Status = More-Data-Request 826 Service-Type = Additional-Authorization 827 State = 0xcba00004 828 Message-Authenticator 830 Figure 10: Access-Request (chunk 1) 832 The RADIUS Server receives this request, and uses the State attribute 833 to associate it with an ongoing chunking session. Compliant ASes 834 will then continue the chunking process. Non-compliant ASes will 835 never see a response such as this, as they will never send a Frag- 836 Status attribute. 838 The RADIUS Server continues the chunking process by sending the next 839 chunk, with the final attribute(s) from the original packet. The 840 value of the Identifier field is taken from the received Access- 841 Request. A Frag-Status attribute is not included in the next Access- 842 Accept, as no more chunks are available for sending. The RADIUS 843 Server includes the original State attribute to allow the RADIUS 844 Client to send additional authorization data. The original Service- 845 Type attribute is included as well. 847 Access-Accept (ID = 131) 848 Example-Long-1 [M] 849 Example-Long-1 [M] 850 Example-Long-1 [M] 851 Example-Long-1 852 Example-Long-2 [M] 853 Example-Long-2 [M] 854 Example-Long-2 855 Service-Type = Login 856 State = 0xfda000003 857 Message-Authenticator 859 Figure 11: Access-Accept (chunk 2) 861 On reception of this last chunk, the RADIUS Client matches it with an 862 ongoing session via the Identifier field, and sees that there is no 863 Frag-Status attribute present. It then processes the received 864 attributes as if they had been sent in one RADIUS packet. See 865 Section 8.4 for further details of this process. 867 6. Chunk size 869 In an ideal scenario, each intermediate chunk would be exactly the 870 size limit in length. In this way, the number of round trips 871 required to send a large packet would be optimal. However, this is 872 not possible for several reasons. 874 1. RADIUS attributes have a variable length, and must be included 875 completely in a chunk. Thus, it is possible that, even if there 876 is some free space in the chunk, it is not enough to include the 877 next attribute. This can generate up to 254 octets of spare 878 space on every chunk. 880 2. RADIUS fragmentation requires the introduction of some extra 881 attributes for signalling. Specifically, a Frag-Status attribute 882 (7 octets) is included on every chunk of a packet, except the 883 last one. A RADIUS State attribute (from 3 to 255 octets) is 884 also included in most chunks, to allow the RADIUS Server to bind 885 an Access-Request with a previous Access-Challenge. User-Name 886 attributes (from 3 to 255 octets) are introduced on every chunk 887 the RADIUS Client sends as they are required by the proxies to 888 route the packet to its destination. Together, these attributes 889 can generate from up to 13 to 517 octets of signalling data, 890 reducing the amount of payload information that can be sent on 891 each chunk. 893 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 894 MTU. Otherwise, IP fragmentation may occur, having undesirable 895 consequences. Hence, maximum chunk size would be decreased from 896 4096 to the actual MTU of the network. 898 4. The inclusion of Proxy-State attributes by intermediary proxies 899 can decrease the availability of usable space into the chunk. 900 This is described with further detail in Section 8.1. 902 7. Allowed large packet size 904 There are no provisions for signalling how much data is to be sent 905 via the fragmentation process as a whole. It is difficult to define 906 what is meant by the "length" of any fragmented data. That data can 907 be multiple attributes, which includes RADIUS attribute header 908 fields. Or it can be one or more "large" attributes (more than 256 909 octets in length). Proxies can also filter these attributes, to 910 modify, add, or delete them and their contents. These proxies act on 911 a "packet by packet" basis, and cannot know what kind of filtering 912 actions they take on future packets. As a result, it is impossible 913 to signal any meaningful value for the total amount of additional 914 data. 916 Unauthenticated end users are permitted to trigger the exchange of 917 large amounts of fragmented data between the RADIUS Client and the 918 RADIUS Server, having the potential to allow Denial of Service (DoS) 919 attacks. An attacker could initiate a large number of connections, 920 each of which requests the RADIUS Server to store a large amount of 921 data. This data could cause memory exhaustion on the RADIUS Server, 922 and result in authentic users being denied access. It is worth 923 noting that authentication mechanisms are already designed to avoid 924 exceeding the size limit. 926 Hence, implementations of this specification MUST limit the total 927 amount of data they send and/or receive via this specification. Its 928 default value SHOULD be 100 kilo-octets. Any more than this may turn 929 RADIUS into a generic transport protocol, which is undesired. This 930 limit SHOULD be configurable, so that it can be changed if necessary. 932 Implementations of this specification MUST limit the total number of 933 round trips used during the fragmentation process. Its default value 934 SHOULD be to 25. Any more than this may indicate an implementation 935 error, misconfiguration, or a denial of service (DoS) attack. This 936 limit SHOULD be configurable, so that it can be changed if necessary. 938 For instance, let's imagine the RADIUS Server wants to transport an 939 SAML assertion which is 15000 octets long, to the RADIUS Client. In 940 this hypothetical scenario, we assume there are 3 intermediate 941 proxies, each one inserting a Proxy-State attribute of 20 octets. 942 Also we assume the State attributes generated by the RADIUS Server 943 have a size of 6 octets, and the User-Name attribute take 50 octets. 944 Therefore, the amount of free space in a chunk for the transport of 945 the SAML assertion attributes is: Total (4096) - RADIUS header (20) - 946 User-Name (50 octets) - Frag-Status (7 octets) - Service-Type (6 947 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State 948 (20) - Proxy-State (20) - Message-Authenticator (18 octets), 949 resulting in a total of 3929 octets, that is, 15 attributes of 255 950 bytes. 952 According to [RFC6929], a Long-Extended-Type provides a payload of 953 251 octets. Therefore, the SAML assertion described above would 954 result into 60 attributes, requiring of 4 round-trips to be 955 completely transmitted. 957 8. Handling special attributes 959 8.1. Proxy-State attribute 961 RADIUS proxies may introduce Proxy-State attributes into any Access- 962 Request packet they forward. If they are unable to add this 963 information to the packet, they may silently discard forwarding it to 964 its destination, leading to DoS situations. Moreover, any Proxy- 965 State attribute received by a RADIUS Server in an Access-Request 966 packet MUST be copied into the reply packet to it. For these 967 reasons, Proxy-State attributes require a special treatment within 968 the packet fragmentation mechanism. 970 When the RADIUS Server replies to an Access-Request packet as part of 971 a conversation involving a fragmentation (either a chunk or a request 972 for chunks), it MUST include every Proxy-State attribute received 973 into the reply packet. This means that the RADIUS Server MUST take 974 into account the size of these Proxy-State attributes in order to 975 calculate the size of the next chunk to be sent. 977 However, while a RADIUS Server will always know how much space MUST 978 be left on each reply packet for Proxy-State attributes (as they are 979 directly included by the RADIUS Server), a RADIUS Client cannot know 980 this information, as Proxy-State attributes are removed from the 981 reply packet by their respective proxies before forwarding them back. 982 Hence, RADIUS Clients need a mechanism to discover the amount of 983 space required by proxies to introduce their Proxy-State attributes. 984 In the following we describe a new mechanism to perform such a 985 discovery: 987 1. When a RADIUS Client does not know how much space will be 988 required by intermediate proxies for including their Proxy-State 989 attributes, it SHOULD start using a conservative value (e.g. 1024 990 octets) as the chunk size. 992 2. When the RADIUS Server receives a chunk from the RADIUS Client, 993 it can calculate the total size of the Proxy-State attributes 994 that have been introduced by intermediary proxies along the path. 995 This information MUST be returned to the RADIUS Client in the 996 next reply packet, encoded into a new attribute called Proxy- 997 State-Length. The RADIUS Server MAY artificially increase this 998 quantity in order to handle with situations where proxies behave 999 inconsistently (e.g. they generate Proxy-State attributes with a 1000 different size for each packet), or for situations where 1001 intermediary proxies remove Proxy-State attributes generated by 1002 other proxies. Increasing this value would make the RADIUS 1003 Client to leave some free space for these situations. 1005 3. The RADIUS Client SHOULD react upon the reception of this 1006 attribute by adjusting the maximum size for the next chunk 1007 accordingly. However, as the Proxy-State-Length offers just an 1008 estimation of the space required by the proxies, the RADIUS 1009 Client MAY select a smaller amount in environments known to be 1010 problematic. 1012 8.2. State attribute 1014 This RADIUS fragmentation mechanism makes use of the State attribute 1015 to link all the chunks belonging to the same fragmented packet. 1016 However, some considerations are required when the RADIUS Server is 1017 fragmenting a packet that already contains a State attribute for 1018 other purposes not related with the fragmentation. If the procedure 1019 described in Section 5 is followed, two different State attributes 1020 could be included into a single chunk, incurring into two problems. 1021 First, [RFC2865] explicitly forbids that more than one State 1022 attribute appears into a single packet. 1024 A straightforward solution consists on making the RADIUS Server to 1025 send the original State attribute into the last chunk of the sequence 1026 (attributes can be re-ordered as specified in [RFC2865]). As the 1027 last chunk (when generated by the RADIUS Server) does not contain any 1028 State attribute due to the fragmentation mechanism, both situations 1029 described above are avoided. 1031 Something similar happens when the RADIUS Client has to send a 1032 fragmented packet that contains a State attribute on it. The RADIUS 1033 Client MUST assure that this original State is included into the 1034 first chunk sent to the RADIUS Server (as this one never contains any 1035 State attribute due to fragmentation). 1037 8.3. Service-Type attribute 1039 This RADIUS fragmentation mechanism makes use of the Service-Type 1040 attribute to indicate an Access-Accept packet is not granting access 1041 to the service yet, since additional authorization exchange needs to 1042 be performed. Similarly to the State attribute, the RADIUS Server 1043 has to send the original Service-Type attribute into the last Access- 1044 Accept of the RADIUS conversation to avoid ambiguity. 1046 8.4. Rebuilding the original large packet 1048 The RADIUS Client stores the RADIUS attributes received on each chunk 1049 in order to be able to rebuild the original large packet after 1050 receiving the last chunk. However, some of these received attributes 1051 MUST NOT be stored in this list, as they have been introduced as part 1052 of the fragmentation signalling and hence, they are not part of the 1053 original packet. 1055 o State (except the one in the last chunk, if present) 1057 o Service-Type = Additional-Authorization 1059 o Frag-Status 1061 o Proxy-State-Length 1063 Similarly, the RADIUS Server MUST NOT store the following attributes 1064 as part of the original large packet: 1066 o State (except the one in the first chunk, if present) 1068 o Service-Type = Additional-Authorization 1070 o Frag-Status 1072 o Proxy-State (except the ones in the last chunk) 1074 o User-Name (except the one in the first chunk) 1076 9. New flag T field for the Long Extended Type attribute definition 1078 This document defines a new field in the "Long Extended Type" 1079 attribute format. This field is one bit in size, and is called "T" 1080 for Truncation. It indicates that the attribute is intentionally 1081 truncated in this chunk, and is to be continued in the next chunk of 1082 the sequence. The combination of the flags "M" and "T" indicates 1083 that the attribute is fragmented (flag M), but that all the fragments 1084 are not available in this chunk (flag T). Proxies implementing 1085 [RFC6929] will see these attributes as invalid (they will not be able 1086 to reconstruct them), but they will still forward them as [RFC6929] 1087 section 5.2 indicates they SHOULD forward unknown attributes anyway. 1089 As a consequence of this addition, the Reserved field is now 6 bits 1090 long (see Section 12.1 for some considerations). The following 1091 figure represents the new attribute format. 1093 0 1 2 3 1094 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 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Type | Length | Extended-Type |M|T| Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Value ... 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Figure 12: Updated Long Extended Type attribute format 1103 10. New attribute definition 1105 This document proposes the definition of two new extended type 1106 attributes, called Frag-Status and Proxy-State-Length. The format of 1107 these attributes follows the indications for an Extended Type 1108 attribute defined in [RFC6929]. 1110 10.1. Frag-Status attribute 1112 This attribute is used for fragmentation signalling, and its meaning 1113 depends on the code value transported within it. The following 1114 figure represents the format of the Frag-Status attribute. 1116 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Type | Length | Extended-Type | Code 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 Code (cont) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Figure 13: Frag-Status format 1126 Type 1127 241 (To be confirmed by IANA) 1129 Length 1131 7 1133 Extended-Type 1135 TBD1 1137 Code 1139 4 byte. Integer indicating the code. The values defined in this 1140 specifications are: 1142 0 - Reserved 1144 1 - Fragmentation-Supported 1146 2 - More-Data-Pending 1148 3 - More-Data-Request 1150 This attribute MAY be present in Access-Request, Access-Challenge and 1151 Access-Accept packets. It MUST NOT be included in Access-Reject 1152 packets. RADIUS Clients supporting this specification MUST include a 1153 Frag-Status = Fragmentation-Supported attribute in the first Access- 1154 Request sent to the RADIUS Server, in order to indicate they would 1155 accept fragmented data from the sever. 1157 10.2. Proxy-State-Length attribute 1159 This attribute indicates to the RADIUS Client the length of the 1160 Proxy-State attributes received by the RADIUS Server. This 1161 information is useful to adjust the length of the chunks sent by the 1162 RADIUS Client. The format of this Proxy-State-Length attribute is 1163 the following: 1165 1 2 3 1166 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 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | Type | Length | Extended-Type | Value 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 Value (cont) | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Figure 14: Proxy-State-Length format 1175 Type 1177 241 (To be confirmed by IANA) 1179 Length 1181 7 1183 Extended-Type 1185 TBD2 1187 Value 1189 4 octets. Total length (in octets) of received Proxy-State 1190 attributes (including headers). As the RADIUS "length" field 1191 cannot take values over 4096 octets, values of Proxy-State-Length 1192 MUST be less than that maximum length. 1194 This attribute MAY be present in Access-Challenge and Access-Accept 1195 packets. It MUST NOT be included in Access-Request or Access-Reject 1196 packets. 1198 10.3. Table of attributes 1200 The following table shows the different attributes defined in this 1201 document related with the kind of RADIUS packets where they can be 1202 present. 1204 | Kind of packet | 1205 +-----+-----+-----+-----+ 1206 Attribute Name | Req | Acc | Rej | Cha | 1207 ----------------------+-----+-----+-----+-----+ 1208 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 1209 ----------------------+-----+-----+-----+-----+ 1210 Proxy-State-Length | 0 | 0-1 | 0 | 0-1 | 1211 ----------------------+-----+-----+-----+-----+ 1213 11. Operation with proxies 1215 The fragmentation mechanism defined above is designed to be 1216 transparent to legacy proxies, as long as they do not want to modify 1217 any fragmented attribute. Nevertheless, updated proxies supporting 1218 this specification can even modify fragmented attributes. 1220 11.1. Legacy proxies 1222 As every chunk is indeed a RADIUS packet, legacy proxies treat them 1223 as the rest of packets, routing them to their destination. Proxies 1224 can introduce Proxy-State attributes to Access-Request packets, even 1225 if they are indeed chunks. This will not affect how fragmentation is 1226 managed. The RADIUS Server will include all the received Proxy-State 1227 attributes into the generated response, as described in [RFC2865]. 1228 Hence, proxies do not distinguish between a regular RADIUS packet and 1229 a chunk. 1231 11.2. Updated proxies 1233 Updated proxies can interact with RADIUS Clients and Servers in order 1234 to obtain the complete large packet before starting forwarding it. 1235 In this way, proxies can manipulate (modify and/or remove) any 1236 attribute of the packet, or introduce new attributes, without 1237 worrying about crossing the boundaries of the chunk size. Once the 1238 manipulated packet is ready, it is sent to the original destination 1239 using the fragmentation mechanism (if required). The following 1240 example shows how an updated proxy interacts with the RADIUS Client 1241 to obtain a large Access-Request packet, modify an attribute 1242 resulting into an even more large packet, and interacts with the 1243 RADIUS Server to complete the transmission of the modified packet. 1245 +-+-+-+-+-+ +-+-+-+-+-+ 1246 | RADIUS | | RADIUS | 1247 | Client | | Proxy | 1248 +-+-+-+-+-+ +-+-+-+-+-+ 1249 | | 1250 | Access-Request(1){User-Name,Calling-Station-Id, | 1251 | Example-Long-1[M],Example-Long-1[M], | 1252 | Example-Long-1[M],Example-Long-1[M], | 1253 | Example-Long-1[MT],Frag-Status(MDP)} | 1254 |--------------------------------------------------->| 1255 | | 1256 | Access-Challenge(1){User-Name, | 1257 | Frag-Status(MDR),State1} | 1258 |<---------------------------------------------------| 1259 | | 1260 | Access-Request(2)(User-Name,State1, | 1261 | Example-Long-1[M],Example-Long-1[M], | 1262 | Example-Long-1[M],Example-Long-1} | 1263 |--------------------------------------------------->| 1265 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 1266 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 1268 Figure 15: Updated proxy interacts with RADIUS Client 1270 +-+-+-+-+-+ +-+-+-+-+-+ 1271 | RADIUS | | RADIUS | 1272 | Proxy | | Server | 1273 +-+-+-+-+-+ +-+-+-+-+-+ 1274 | | 1275 | Access-Request(3){User-Name,Calling-Station-Id, | 1276 | Example-Long-1[M],Example-Long-1[M], | 1277 | Example-Long-1[M],Example-Long-1[M], | 1278 | Example-Long-1[MT],Frag-Status(MDP)} | 1279 |--------------------------------------------------->| 1280 | | 1281 | Access-Challenge(1){User-Name, | 1282 | Frag-Status(MDR),State2} | 1283 |<---------------------------------------------------| 1284 | | 1285 | Access-Request(4){User-Name,State2, | 1286 | Example-Long-1[M],Example-Long-1[M], | 1287 | Example-Long-1[M],Example-Long-1[M], | 1288 | Example-Long-1[MT],Frag-Status(MDP)} | 1289 |--------------------------------------------------->| 1290 | | 1291 | Access-Challenge(1){User-Name, | 1292 | Frag-Status(MDR),State3} | 1293 |<---------------------------------------------------| 1294 | | 1295 | Access-Request(5){User-Name,State3,Example-Long-1} | 1296 |--------------------------------------------------->| 1298 Figure 16: Updated proxy interacts with RADIUS Server 1300 12. General considerations 1302 12.1. Flag T 1304 As described in Section 9, this document modifies the definition of 1305 the "Reserved" field of the "Long Extended Type" attribute [RFC6929], 1306 by allocating an additional flag "T". The meaning and position of 1307 this flag is defined in this document, and nowhere else. This might 1308 generate an issue if subsequent specifications want to allocate a new 1309 flag as well, as there would be no direct way for them to know which 1310 parts of the "Reserved" field have already been defined. 1312 An immediate and reasonable solution for this issue would be 1313 declaring that this RFC updates [RFC6929]. In this way, [RFC6929] 1314 would include an "Updated by" clause that will point readers to this 1315 document. Another alternative would be creating an IANA registry for 1316 the "Reserved" field. However, the working group thinks that would 1317 be overkill, as not such a great number of specifications extending 1318 that field are expected. 1320 In the end, the proposed solution is that this experimental RFC 1321 should not update RFC 6929. Instead, we rely on the collective mind 1322 of the WG to recall that this T flag is used. When/if the experiment 1323 will be successful, the T flag will be properly assigned. 1325 12.2. Violation of RFC2865 1327 Section 5.1 indicates that all authorization and authentication 1328 handling will be postponed until all the chunks have been received. 1329 This postponement also affects to the verification that the Access- 1330 Request packet contains some kind of authentication attribute (e.g. 1331 User-Password, CHAP-Password, State or other future attribute), as 1332 required by [RFC2865]. This checking will therefore be delayed until 1333 the original large packet has been rebuilt, as some of the chunks may 1334 not contain any of them. 1336 The authors acknowledge that this specification violates the "MUST" 1337 requirement of [RFC2865] Section 4.1 that states that "An Access- 1338 Request MUST contain either a User-Password or a CHAP- Password or a 1339 State". We note that a proxy which enforces that requirement would 1340 be unable to support future RADIUS authentication extensions. 1341 Extensions to the protocol would therefore be impossible to deploy. 1342 All known implementations have chosen the philosophy of "be liberal 1343 in what you accept". That is, they accept traffic which violates the 1344 requirement of [RFC2865] Section 4.1. We therefore expect to see no 1345 operational issues with this specification. After we gain more 1346 operational experience with this specification, it can be re-issued 1347 as a standards track document, and update [RFC2865]. 1349 12.3. Proxying based on User-Name 1351 This proposal assumes legacy proxies to base their routing decisions 1352 on the value of the User-Name attribute. For this reason, every 1353 packet sent from the RADIUS Client to the RADIUS Server (either 1354 chunks or requests for more chunks) MUST contain a User-Name 1355 attribute. 1357 12.4. Transport behaviour 1359 This proposal does not modify the way RADIUS interacts with the 1360 underlying transport (UDP). That is, RADIUS keeps following a lock- 1361 step behaviour, that requires receiving an explicit acknowledge for 1362 each chunk sent. Hence, bursts of traffic which could congest links 1363 between peers are not an issue. 1365 Another benefit of the lock-step nature of RADIUS, is that there are 1366 no security issues with overlapping fragments. Each chunk simply has 1367 a length, with no "fragment offset" field as with IPv4. The order of 1368 the fragments is determined by the order in which they are received. 1369 There is no ambiguity about the size or placement of each chunk, and 1370 therefore no security issues associated with overlapping chunks. 1372 13. Security Considerations 1374 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1375 RADIUS security is problematic. This specification changes nothing 1376 related to the security of the RADIUS protocol. It requires that all 1377 Access-Request packets associated with fragmentation are 1378 authenticated using the existing Message-Authenticator attribute. 1379 This signature prevents forging and replay, to the limits of the 1380 existing security. 1382 The ability to send bulk data from one party to another creates new 1383 security considerations. RADIUS Clients and Servers may have to 1384 store large amounts of data per session. The amount of this data can 1385 be significant, leading to the potential for resource exhaustion. We 1386 therefore suggest that implementations limit the amount of bulk data 1387 stored per session. The exact method for this limitation is 1388 implementation-specific. Section 7 gives some indications on what 1389 could be reasonable limits. 1391 The bulk data can often be pushed off to storage methods other than 1392 the memory of the RADIUS implementation. For example, it can be 1393 stored in an external database, or in files. This approach mitigates 1394 the resource exhaustion issue, as RADIUS Servers today already store 1395 large amounts of accounting data. 1397 14. IANA Considerations 1399 The authors request that Attribute Types and Attribute Values defined 1400 in this document be registered by the Internet Assigned Numbers 1401 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1402 Considerations" section of [RFC3575], in accordance with BCP 26 1403 [RFC5226]. For RADIUS packets, attributes and registries created by 1404 this document IANA is requested to place them at 1405 http://www.iana.org/assignments/radius-types. 1407 In particular, this document defines two new RADIUS attributes, 1408 entitled "Frag-Status" and "Proxy-State-Length" (see Section 10), 1409 with assigned values of 241.TBD1 and 241.TBD2 from the Short Extended 1410 Space of [RFC6929]: 1412 Type Name Length Meaning 1413 ---- ---- ------ ------- 1414 241.TBD1 Frag-Status 7 Signals fragmentation 1415 241.TBD2 Proxy-State-Length 7 Indicates the length of the 1416 received Proxy-State attributes 1418 The Frag-Status attribute also defines a 8-bit "Code" field, for 1419 which the IANA is to create and maintain a new sub-registry entitled 1420 "Code values" under the RADIUS "Frag-Status" attribute. Initial 1421 values for the RADIUS Frag-Status "Code" registry are given below; 1422 future assignments are to be made through "RFC required" [RFC5226]. 1423 Assignments consist of a Frag-Status "Code" name and its associated 1424 value. 1426 Value Frag-Status Code Name Definition 1427 ---- ------------------------ ---------- 1428 0 Reserved See Section 10.1 1429 1 Fragmentation-Supported See Section 10.1 1430 2 More-Data-Pending See Section 10.1 1431 3 More-Data-Request See Section 10.1 1432 4-255 Unassigned 1434 Additionally, allocation of a new Service-Type value for "Additional- 1435 Authorization" is requested. 1437 Value Service Type Value Definition 1438 ---- ------------------------ ---------- 1439 TBA Additional-Authorization See Section 5.1 1441 15. Acknowledgements 1443 The authors would like to thank the members of the RADEXT working 1444 group who have contributed to the development of this specification, 1445 either by participating on the discussions on the mailing lists or by 1446 sending comments about our RFC. 1448 The authors also thank David Cuenca (University of Murcia) for 1449 implementing a proof of concept implementation of this RFC that has 1450 been useful to improve the quality of the specification. 1452 This work has been partly funded by the GEANT GN3+ SA5 and CLASSe 1453 (http://sec.cs.kent.ac.uk/CLASSe/) projects. 1455 16. References 1456 16.1. Normative References 1458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1459 Requirement Levels", BCP 14, RFC 2119, March 1997. 1461 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1462 "Remote Authentication Dial In User Service (RADIUS)", 1463 RFC 2865, June 2000. 1465 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1466 Authentication Dial In User Service)", RFC 3575, 1467 July 2003. 1469 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1470 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1471 May 2008. 1473 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1474 BCP 158, RFC 6158, March 2011. 1476 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1477 Service (RADIUS) Protocol Extensions", RFC 6929, 1478 April 2013. 1480 16.2. Informative References 1482 [I-D.ietf-abfab-aaa-saml] 1483 Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, 1484 Profiles, Name Identifier Format, and Confirmation Methods 1485 for SAML", draft-ietf-abfab-aaa-saml-09 (work in 1486 progress), February 2014. 1488 [I-D.ietf-abfab-arch] 1489 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. 1490 Schaad, "Application Bridging for Federated Access Beyond 1491 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work 1492 in progress), July 2014. 1494 [I-D.ietf-radext-bigger-packets] 1495 Hartman, S., "Larger Packets for RADIUS over TCP", 1496 draft-ietf-radext-bigger-packets-01 (work in progress), 1497 July 2014. 1499 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1501 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1502 Dial In User Service) Support For Extensible 1503 Authentication Protocol (EAP)", RFC 3579, September 2003. 1505 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1506 Rule Attribute", RFC 4849, April 2007. 1508 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1509 Dial In User Service (RADIUS) Implementation Issues and 1510 Suggested Fixes", RFC 5080, December 2007. 1512 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1513 Aboba, "Dynamic Authorization Extensions to Remote 1514 Authentication Dial In User Service (RADIUS)", RFC 5176, 1515 January 2008. 1517 Authors' Addresses 1519 Alejandro Perez-Mendez (Ed.) 1520 University of Murcia 1521 Campus de Espinardo S/N, Faculty of Computer Science 1522 Murcia, 30100 1523 Spain 1525 Phone: +34 868 88 46 44 1526 Email: alex@um.es 1528 Rafa Marin-Lopez 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 01 1535 Email: rafa@um.es 1537 Fernando Pereniguez-Garcia 1538 University of Murcia 1539 Campus de Espinardo S/N, Faculty of Computer Science 1540 Murcia, 30100 1541 Spain 1543 Phone: +34 868 88 78 82 1544 Email: pereniguez@um.es 1545 Gabriel Lopez-Millan 1546 University of Murcia 1547 Campus de Espinardo S/N, Faculty of Computer Science 1548 Murcia, 30100 1549 Spain 1551 Phone: +34 868 88 85 04 1552 Email: gabilm@um.es 1554 Diego R. Lopez 1555 Telefonica I+D 1556 Don Ramon de la Cruz, 84 1557 Madrid, 28006 1558 Spain 1560 Phone: +34 913 129 041 1561 Email: diego@tid.es 1563 Alan DeKok 1564 Network RADIUS 1565 15 av du Granier 1566 Meylan, 38240 1567 France 1569 Phone: +34 913 129 041 1570 Email: aland@networkradius.com 1571 URI: http://networkradius.com