idnits 2.17.1 draft-ietf-radext-radius-fragmentation-07.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1183, but not defined == Missing Reference: 'MT' is mentioned on line 1184, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 1311, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) 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 Updates: RFC6929 (if approved) F. Pereniguez-Garcia 5 Intended status: Experimental G. Lopez-Millan 6 Expires: January 5, 2015 University of Murcia 7 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 July 4, 2014 13 Support of fragmentation of RADIUS packets 14 draft-ietf-radext-radius-fragmentation-07 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 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 January 5, 2015. 45 Copyright Notice 47 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Scope of this document . . . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 9 67 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 10 68 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 14 69 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 18 71 7. Handling special attributes . . . . . . . . . . . . . . . . . 19 72 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 19 73 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 20 74 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 21 75 7.4. Rebuilding the original large packet . . . . . . . . . . . 21 76 8. New flag T field for the Long Extended Type attribute 77 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 9. New attribute definition . . . . . . . . . . . . . . . . . . . 22 79 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 22 80 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 23 81 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 24 82 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 25 83 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 25 84 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 25 85 11. Operational considerations . . . . . . . . . . . . . . . . . . 27 86 11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 28 88 11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 28 89 11.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 28 90 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 91 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 94 15.1. Normative References . . . . . . . . . . . . . . . . . . . 30 95 15.2. Informative References . . . . . . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 98 1. Introduction 100 The RADIUS [RFC2865] protocol carries authentication, authorization, 101 and accounting information between a Network Access Server (NAS) and 102 an Authentication Server (AS). Information is exchanged between the 103 NAS and the AS through RADIUS packets. Each RADIUS packet is 104 composed of a header, and zero or more attributes, up to a maximum 105 packet size of 4096 octets. The protocol is a request/response 106 protocol, as described in the operational model ( [RFC6158], Section 107 3.1). 109 The above packet size limitation mean that peers desiring to send 110 large amounts of data must fragment it across multiple packets. For 111 example, RADIUS-EAP [RFC3579] defines how an EAP exchange occurs 112 across multiple Access-Request / Access-Challenge sequences. No such 113 exchange is possible for accounting or authorization data. [RFC6158] 114 Section 3.1 suggests that exchanging large amounts authorization data 115 is unnecessary in RADIUS. Instead, the data should be referenced by 116 name. This requirement allows large policies to be pre-provisioned, 117 and then referenced in an Access-Accept. In some cases, however, the 118 authorization data sent by the server is large and highly dynamic. 119 In other cases, the NAS needs to send large amounts of authorization 120 data to the server. Both of these cases are un-met by the 121 requirements in [RFC6158]. As noted in that document, the practical 122 limit on RADIUS packet sizes is governed by the Path MTU (PMTU), 123 which may be significantly smaller than 4096 octets. The combination 124 of the two limitations means that there is a pressing need for a 125 method to send large amounts of authorization data between NAS and 126 AS, with no accompanying solution. 128 [RFC6158] recommends three approaches for the transmission of large 129 amount of data within RADIUS. However, they are not applicable to 130 the problem statement of this document for the following reasons: 132 o The first approach does not talk about large amounts of data sent 133 from the NAS to a server. Leveraging EAP (request/challenge) to 134 send the data is not feasible, as EAP already fills packet to 135 PMTU, and not all authentications use EAP. Moreover, as noted for 136 NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the 137 problem of sending large amounts of data from a server to a NAS. 139 o The second approach is not usable either, as using names rather 140 than values is difficult when the nature of the data to be sent is 141 highly dynamic (e.g. SAML sentences or NAS-Filter-Rule 142 attributes). URLs could be used as a pointer to the location of 143 the actual data, but their use would require them to be (a) 144 dynamically created and modified, (b) securely accessed and (c) 145 accessible from remote systems. Satisfying these constraints 146 would require the modification of several networking systems (e.g. 147 firewalls and web servers). Furthermore, the set up of an 148 additional trust infrastructure (e.g. PKI) would be required to 149 allow secure retrieving of the information from the web server. 151 o PMTU discovery does not solve the problem, as it does not allow to 152 send data larger than the minimum of (PMTU or 4096) octets. 154 This document provides a mechanism to allow RADIUS peers to exchange 155 large amounts of authorization data exceeding the 4096 octet limit, 156 by fragmenting it across several client/server exchanges. The 157 proposed solution does not impose any additional requirements to the 158 RADIUS system administrators (e.g. need to modify firewall rules, set 159 up web servers, configure routers, or modify any application server). 160 It maintains compatibility with intra-packet fragmentation mechanisms 161 (like those defined in [RFC3579] or in [RFC6929]). It is also 162 transparent to existing RADIUS proxies, which do not implement this 163 specification. The only systems needing to implement the draft are 164 the ones which either generate, or consume the fragmented data being 165 transmitted. Intermediate proxies just pass the packets without 166 changes. Nevertheless, if a proxy supports this specification, it 167 may re-assemble the data in order to either examine and/or modify it. 169 1.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 When these words appear in lower case, they have their natural 175 language meaning. 177 2. Scope of this document 179 This specification describes how a RADIUS client and a RADIUS server 180 can exchange data exceeding the 4096 octet limit imposed by one 181 packet. However, the mechanism described in this specification MUST 182 NOT be used to exchange more than 100K of data. It has not been 183 designed to substitute for stream-oriented transport protocols, such 184 as TCP or SCTP. Experience shows that attempts to transport bulk 185 data across the Internet with UDP will inevitably fail, unless they 186 re-implement all of the behavior of TCP. The underlying design of 187 RADIUS lacks the proper retransmission policies or congestion control 188 mechanisms which would make it a competitor to TCP. 190 Therefore, RADIUS/UDP transport is by design unable to transport bulk 191 data. It is both undesired and impossible to change the protocol at 192 this point in time. This specification is intended to allow the 193 transport of more than 4096 octets of data through existing RADIUS/ 194 UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a 195 "green field" deployment requires the transport of bulk data. 197 Section 6, below, describes with further details the reasoning for 198 this limitation, and recommends administrators to adjust it according 199 to the specific capabilities of their existing systems in terms of 200 memory and processing power. 202 Moreover, its scope is limited to the exchange of authorization data, 203 as other exchanges do not require of such a mechanism. In 204 particular, authentication exchanges have already been defined to 205 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 206 represent the most critical part of a RADIUS conversation, it is 207 preferable to not introduce any modification to their operation that 208 may affect existing equipment. 210 There is no need to fragment accounting packets either. While the 211 accounting process can send large amounts of data, that data is 212 typically composed of many small updates. That is, there is no 213 demonstrated need to send indivisible blocks of more than 4K of data. 214 The need to send large amounts of data per user session often 215 originates from the need for flow-based accounting. In this use- 216 case, the client may send accounting data for many thousands of 217 flows, where all those flows are tied to one user session. The 218 existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 219 5.11 has been proven to work here. 221 Similarly, there is no need to fragment CoA packets. Instead, the 222 CoA client MUST send a CoA-Request packet containing session 223 identification attributes, along with Service-Type = Additional- 224 Authorization, and a State attribute. Implementations not supporting 225 fragmentation will respond with a CoA-NAK, and an Error-Cause of 226 Unsupported-Service. 228 The above requirement does not assume that the CoA client and the 229 RADIUS server are co-located. They may, in fact be run on separate 230 parts of the infrastructure, or even by separate administrators. 231 There is, however, a requirement that the two communicate. We can 232 see that the CoA client needs to send session identification 233 attributes in order to send CoA packets. These attributes cannot be 234 known a priori by the CoA client, and can only come from the RADIUS 235 server. Therefore, even when the two systems are not co-located, 236 they must be able to communicate in order to operate in unison. The 237 alternative is for the two systems to have differing views of the 238 users authorization parameters, which is a security disaster. 240 This specification does not allow for fragmentation of CoA packets. 242 Allowing for fragmented CoA packets would involve changing multiple 243 parts of the RADIUS protocol, with the corresponding possibility for 244 implementation issues, mistakes, etc. 246 Where CoA clients (i.e. RADIUS servers) need to send large amounts 247 of authorization data to a CoA server (i.e. NAS), they need only 248 send a minimal CoA-Request packet, containing Service-Type of 249 Authorize-Only, as per RFC 5176, along with session identification 250 attributes. This CoA packet serves as a signal to the NAS that the 251 users' session requires re-authorization. When the NAS re-authorizes 252 the user via Access-Request, the RADIUS server can perform 253 fragmentation, and send large amounts of authorization data to the 254 NAS. 256 The assumption in the above scenario is that the CoA client and 257 RADIUS server are co-located, or at least strongly coupled. That is, 258 the path from CoA client to CoA server SHOULD be the exact reverse of 259 the path from NAS to RADIUS server. The following diagram will 260 hopefully clarify the roles: 262 +---------------------+ 263 | NAS CoA Server | 264 +---------------------+ 265 | ^ 266 Access-Request | | CoA-Request 267 v | 268 +---------------------+ 269 | RADIUS CoA client | 270 | Server | 271 +---------------------+ 273 Where there is a proxy involved: 275 +---------------------+ 276 | NAS CoA Server | 277 +---------------------+ 278 | ^ 279 Access-Request | | CoA-Request 280 v | 281 +---------------------+ 282 | RADIUS CoA | 283 | Proxy Proxy | 284 +---------------------+ 285 | ^ 286 Access-Request | | CoA-Request 287 v | 288 +---------------------+ 289 | RADIUS CoA client | 290 | Server | 291 +---------------------+ 293 That is, the RADIUS and COA subsystems at each hop are strongly 294 connected. Where they are not strongly connected, it will be 295 impossible to use CoA-Request packets to transport large amounts of 296 authorization data. 298 This design is more complicated than allowing for fragmented CoA 299 packets. However, the CoA client and the RADIUS server must 300 communicate even when not using this specification. We believe that 301 standardizing that communication, and using one method for exchange 302 of large data is preferred to unspecified communication methods and 303 multiple ways of achieving the same result. If we were to allow 304 fragmentation of data over CoA packets, the size and complexity of 305 this specification would increase significantly. 307 The above requirement solves a number of issues. It clearly 308 separates session identification from authorization. Without this 309 separation, it is difficult to both identify a session, and change 310 its authorization using the same attribute. It also ensures that the 311 authorization process is the same for initial authentication, and for 312 CoA. 314 3. Overview 316 Authorization exchanges can occur either before or after end user 317 authentication has been completed. An authorization exchange before 318 authentication allows a RADIUS client to provide the RADIUS server 319 with information that MAY modify how the authentication process will 320 be performed (e.g. it may affect the selection of the EAP method). 321 An authorization exchange after authentication allows the RADIUS 322 server to provide the RADIUS client with information about the end 323 user, the results of the authentication process and/or obligations to 324 be enforced. In this specification we refer to the "pre- 325 authorization" as the exchange of authorization information before 326 the end user authentication has started (from the NAS to the AS), 327 whereas the term "post-authorization" is used to refer to an 328 authorization exchange happening after this authentication process 329 (from the AS to the NAS). 331 In this specification we refer to the "size limit" as the practical 332 limit on RADIUS packet sizes. This limit is the minimum of 4096 333 octets, and the current PMTU. We define below a method which uses 334 Access-Request and Access-Accept in order to exchange fragmented 335 data. The NAS and server exchange a series of Access-Request / 336 Access-Accept packets, until such time as all of the fragmented data 337 has been transported. Each packet contains a Frag-Status attribute 338 which lets the other party know if fragmentation is desired, ongoing, 339 or finished. Each packet may also contain the fragmented data, or 340 instead be an "ACK" to a previous fragment from the other party. 341 Each Access-Request contains a User-Name attribute, allowing the 342 packet to be proxied if necessary (see Section 10.1). Each Access- 343 Request may also contain a State attribute, which serves to tie it to 344 a previous Access-Accept. Each Access-Accept contains a State 345 attribute, for use by the NAS in a later Access-Request. Each 346 Access-Accept contains a Service-Type attribute with the "Additional- 347 Authorization" value. This indicates that the service being provided 348 is part of a fragmented exchange, and that the Access-Accept should 349 not be interpreted as providing network access to the end user. 351 When a RADIUS client or server need to send data that exceeds the 352 size limit, the mechanism proposed in this document is used. Instead 353 of encoding one large RADIUS packet, a series of smaller RADIUS 354 packets of the same type are encoded. Each smaller packet is called 355 a "chunk" in this specification, in order to distinguish it from 356 traditional RADIUS packets. The encoding process is a simple linear 357 walk over the attributes to be encoded. This walk preserves the 358 order of the attributes of the same type, as required by [RFC2865]. 359 The number of attributes encoded in a particular chunk depends on the 360 size limit, the size of each attribute, the number of proxies between 361 client and server, and the overhead for fragmentation signalling 362 attributes. Specific details are given in Section 5. A new 363 attribute called Frag-Status (Section 9.1) signals the fragmentation 364 status. 366 After the first chunk is encoded, it is sent to the other party. The 367 packet is identified as a chunk via the Frag-Status attribute. The 368 other party then requests additional chunks, again using the Frag- 369 Status attribute. This process is repeated until all the attributes 370 have been sent from one party to the other. When all the chunks have 371 been received, the original list of attributes is reconstructed and 372 processed as if it had been received in one packet. 374 When multiple chunks are sent, a special situation may occur for 375 Extended Type attributes as defined in [RFC6929]. The fragmentation 376 process may split a fragmented attribute across two or more chunks, 377 which is not permitted by that specification. We address this issue 378 by using the newly defined flag "T" in the Reserved field of the 379 "Long Extended Type" attribute format (see Section 8 for further 380 details on this flag). 382 This last situation is expected to be the most common occurrence in 383 chunks. Typically, packet fragmentation will occur as a consequence 384 of a desire to send one or more large (and therefore fragmented) 385 attributes. The large attribute will likely be split into two or 386 more pieces. Where chunking does not split a fragmented attribute, 387 no special treatment is necessary. 389 The setting of the "T" flag is the only case where the chunking 390 process affects the content of an attribute. Even then, the "Value" 391 fields of all attributes remain unchanged. Any per-packet security 392 attributes such as Message-Authenticator are calculated for each 393 chunk independently. There are neither integrity nor security checks 394 performed on the "original" packet. 396 Each RADIUS packet sent or received as part of the chunking process 397 MUST be a valid packet, subject to all format and security 398 requirements. This requirement ensures that a "transparent" proxy 399 not implementing this specification can receive and send compliant 400 packets. That is, a proxy which simply forwards packets without 401 detailed examination or any modification will be able to proxy 402 "chunks". 404 4. Fragmentation of packets 406 When the NAS or the AS desires to send a packet that exceeds the size 407 limit, it is split into chunks and sent via multiple client/server 408 exchanges. The exchange is indicated via the Frag-Status attribute, 409 which has value More-Data-Pending for all but the last chunk of the 410 series. The chunks are tied together via the State attribute. 412 The delivery of a large fragmented RADIUS packet with authorization 413 data can happen before or after the end user has been authenticated 414 by the AS. We can distinguish two phases: 416 1. Pre-authorization. In this phase, the NAS can send a large 417 packet with authorization information to the AS before the end 418 user is authenticated. 420 2. Post-authorization. In this phase, the AS can send a large 421 packet with authorization data to the NAS after the end user has 422 been authenticated. 424 The following subsections describe how to perform fragmentation for 425 packets for these two phases, pre-authorization and post- 426 authorization. We give the packet type, along with a RADIUS 427 Identifier, to indicate that requests and responses are connected. 428 We then give a list of attributes. We do not give values for most 429 attributes, as we wish to concentrate on the fragmentation behaviour, 430 rather than packet contents. Attribute values are given for 431 attributes relevant to the fragmentation process. Where "long 432 extended" attributes are used, we indicate the M (More) and T 433 (Truncation) flags as optional square brackets after the attribute 434 name. As no "long extended" attributes have yet been defined, we use 435 example attributes, named as "Example-Long-1", etc. The maximum 436 chunk size is established in term of number of attributes (11), for 437 sake of simplicity. 439 4.1. Pre-authorization 441 When the client needs to send a large amount of data to the server, 442 the data to be sent is split into chunks and sent to the server via 443 multiple Access-Request / Access-Accept exchanges. The example below 444 shows this exchange. 446 The following is an Access-Request which the NAS intends to send to a 447 server. However, due to a combination of issues (PMTU, large 448 attributes, etc.), the content does not fit into one Access-Request 449 packet. 451 Access-Request 452 User-Name 453 NAS-Identifier 454 Calling-Station-Id 455 Example-Long-1 [M] 456 Example-Long-1 [M] 457 Example-Long-1 [M] 458 Example-Long-1 [M] 459 Example-Long-1 [M] 460 Example-Long-1 [M] 461 Example-Long-1 [M] 462 Example-Long-1 [M] 463 Example-Long-1 464 Example-Long-2 [M] 465 Example-Long-2 [M] 466 Example-Long-2 468 Figure 1: Desired Access-Request 470 The NAS therefore must send the attributes listed above in a series 471 of chunks. The first chunk contains eight (8) attributes from the 472 original Access-Request, and a Frag-Status attribute. Since last 473 attribute is "Example-Long-1" with the "M" flag set, the chunking 474 process also sets the "T" flag in that attribute. The Access-Request 475 is sent with a RADIUS Identifier field having value 23. The Frag- 476 Status attribute has value More-Data-Pending, to indicate that the 477 NAS wishes to send more data in a subsequent Access-Request. The NAS 478 also adds a Service-Type attribute, which indicates that it is part 479 of the chunking process. The packet is signed with the Message- 480 Authenticator attribute, completing the maximum number of attributes 481 (11). 483 Access-Request (ID = 23) 484 User-Name 485 NAS-Identifier 486 Calling-Station-Id 487 Example-Long-1 [M] 488 Example-Long-1 [M] 489 Example-Long-1 [M] 490 Example-Long-1 [M] 491 Example-Long-1 [MT] 492 Frag-Status = More-Data-Pending 493 Service-Type = Additional-Authorization 494 Message-Authenticator 496 Figure 2: Access-Request (chunk 1) 498 Compliant servers (i.e. servers implementing fragmentation) receiving 499 this packet will see the Frag-Status attribute, and postpone all 500 authorization and authentication handling until all of the chunks 501 have been received. This postponement also affects to the 502 verification that the Access-Request packet contains some kind of 503 authentication attribute (e.g. User-Password, CHAP-Password, State 504 or other future attribute), as required by [RFC2865] (see 505 Section 11.2 for more information on this). 507 Non-compliant servers (i.e. servers not implementing fragmentation) 508 should also see the Service-Type requesting provisioning for an 509 unknown service, and return Access-Reject. Other non-compliant 510 servers may return an Access-Reject, Access-Challenge, or an Access- 511 Accept with a particular Service-Type other then Additional- 512 Authorization. Compliant NAS implementations MUST treat these 513 responses as if they had received Access-Reject instead. 515 Compliant servers who wish to receive all of the chunks will respond 516 with the following packet. The value of the State here is arbitrary, 517 and serves only as a unique token for example purposes. We only note 518 that it MUST be temporally unique to the server. 520 Access-Accept (ID = 23) 521 Frag-Status = More-Data-Request 522 Service-Type = Additional-Authorization 523 State = 0xabc00001 524 Message-Authenticator 526 Figure 3: Access-Accept (chunk 1) 528 The NAS will see this response, and use the RADIUS Identifier field 529 to associate it with an ongoing chunking session. Compliant NASes 530 will then continue the chunking process. Non-compliant NASes will 531 never see a response such as this, as they will never send a Frag- 532 Status attribute. The Service-Type attribute is included in the 533 Access-Accept in order to signal that the response is part of the 534 chunking process. This packet therefore does not provision any 535 network service for the end user. 537 The NAS continues the process by sending the next chunk, which 538 includes an additional six (6) attributes from the original packet. 539 It again includes the User-Name attribute, so that non-compliant 540 proxies can process the packet (see Section 10.1). It sets the Frag- 541 Status attribute to More-Data-Pending, as more data is pending. It 542 includes a Service-Type for reasons described above. It includes the 543 State attribute from the previous Access-accept. It signs the packet 544 with Message-Authenticator, as there are no authentication attributes 545 in the packet. It uses a new RADIUS Identifier field. 547 Access-Request (ID = 181) 548 User-Name 549 Example-Long-1 [M] 550 Example-Long-1 [M] 551 Example-Long-1 [M] 552 Example-Long-1 553 Example-Long-2 [M] 554 Example-Long-2 [MT] 555 Frag-Status = More-Data-Pending 556 Service-Type = Additional-Authorization 557 State = 0xabc000001 558 Message-Authenticator 560 Figure 4: Access-Request (chunk 2) 562 Compliant servers receiving this packet will see the Frag-Status 563 attribute, and look for a State attribute. Since one exists and it 564 matches a State sent in an Access-Accept, this packet is part of a 565 chunking process. The server will associate the attributes with the 566 previous chunk. Since the Frag-Status attribute has value More-Data- 567 Request, the server will respond with an Access-Accept as before. It 568 MUST include a State attribute, with a value different from the 569 previous Access-Accept. This State MUST again be globally and 570 temporally unique. 572 Access-Accept (ID = 181) 573 Frag-Status = More-Data-Request 574 Service-Type = Additional-Authorization 575 State = 0xdef00002 576 Message-Authenticator 578 Figure 5: Access-Accept (chunk 2) 580 The NAS will see this response, and use the RADIUS Identifier field 581 to associate it with an ongoing chunking session. The NAS continues 582 the chunking process by sending the next chunk, with the final 583 attribute(s) from the original packet, and again includes the 584 original User-Name attribute. The Frag-Status attribute is not 585 included in the next Access-Request, as no more chunks are available 586 for sending. The NAS includes the State attribute from the previous 587 Access-accept. It signs the packet with Message-Authenticator, as 588 there are no authentication attributes in the packet. It again uses 589 a new RADIUS Identifier field. 591 Access-Request (ID = 241) 592 User-Name 593 Example-Long-2 594 State = 0xdef00002 595 Message-Authenticator 597 Figure 6: Access-Request (chunk 3) 599 On reception of this last chunk, the server matches it with an 600 ongoing session via the State attribute, and sees that there is no 601 Frag-Status attribute present. It then processes the received 602 attributes as if they had been sent in one RADIUS packet. See 603 Section 7.4 for further details of this process. It generates the 604 appropriate response, which can be either Access-Accept or Access- 605 Reject. In this example, we show an Access-Accept. The server MUST 606 send a State attribute, which permits link the received data with the 607 authentication process. 609 Access-Accept (ID = 241) 610 State = 0x98700003 611 Message-Authenticator 613 Figure 7: Access-Accept (chunk 3) 615 The above example shows in practice how the chunking process works. 616 We re-iterate the implementation and security requirements here. 618 Each chunk is a valid RADIUS packet (see Section 11.2 for some 619 considerations about this), and all RADIUS format and security 620 requirements MUST be followed before any chunking process is applied. 622 Every chunk except for the last one from a NAS MUST include a Frag- 623 Status attribute, with value More-Data-Pending. The last chunk MUST 624 NOT contain a Frag-Status attribute. Each chunk except for the last 625 from a NAS MUST include a Service-Type attribute, with value 626 Additional-Authorization. Each chunk MUST include a User-Name 627 attribute, which MUST be identical in all chunks. Each chunk except 628 for the first one from a NAS MUST include a State attribute, which 629 MUST be copied from a previous Access-Accept. 631 Each Access-Accept MUST include a State attribute. The value for 632 this attribute MUST change in every new Access-Accept, and MUST be 633 globally and temporally unique. 635 4.2. Post-authorization 637 When the AS wants to send a large amount of authorization data to the 638 NAS after authentication, the operation is very similar to the pre- 639 authorization one. The presence of Service-Type = Additional- 640 Authorization attribute ensures that a NAS not supporting this 641 specification will treat that unrecognized Service-Type as though an 642 Access-Reject had been received instead ([RFC2865] Section 5.6). If 643 the original large Access-Accept packet contained a Service-Type 644 attribute, it will be included with its original value in the last 645 transmitted chunk, to avoid confusion with the one used for 646 fragmentation signalling. It is strongly RECOMMENDED that servers 647 include a State attribute on their original Access-Accept packets, 648 even if fragmentation is not taking place, to allow the client to 649 send additional authorization data in subsequent exchanges. This 650 State attribute would be included in the last transmitted chunk, to 651 avoid confusion with the ones used for fragmentation signalling. 653 Client supporting this specification MUST include a Frag-Status = 654 Fragmentation-Supported attribute in the first Access-Request sent to 655 the server, in order to indicate they would accept fragmented data 656 from the sever. This is not required if pre-authorization process 657 was carried out, as it is implicit. 659 The following is an Access-Accept which the AS intends to send to a 660 client. However, due to a combination of issues (PMTU, large 661 attributes, etc.), the content does not fit into one Access-Accept 662 packet. 664 Access-Accept 665 User-Name 666 EAP-Message 667 Service-Type(Login) 668 Example-Long-1 [M] 669 Example-Long-1 [M] 670 Example-Long-1 [M] 671 Example-Long-1 [M] 672 Example-Long-1 [M] 673 Example-Long-1 [M] 674 Example-Long-1 [M] 675 Example-Long-1 [M] 676 Example-Long-1 677 Example-Long-2 [M] 678 Example-Long-2 [M] 679 Example-Long-2 680 State = 0xcba00003 682 Figure 8: Desired Access-Accept 684 The AS therefore must send the attributes listed above in a series of 685 chunks. The first chunk contains seven (7) attributes from the 686 original Access-Accept, and a Frag-Status attribute. Since last 687 attribute is "Example-Long-1" with the "M" flag set, the chunking 688 process also sets the "T" flag in that attribute. The Access-Accept 689 is sent with a RADIUS Identifier field having value 30 corresponding 690 to a previous Access-Request not depicted. The Frag-Status attribute 691 has value More-Data-Pending, to indicate that the AS wishes to send 692 more data in a subsequent Access-Accept. The AS also adds a Service- 693 Type attribute with value Additional-Authorization, which indicates 694 that it is part of the chunking process. Note that the original 695 Service-Type is not included in this chunk. Finally, a State 696 attribute is included to allow matching subsequent requests with this 697 conversation, and the packet is signed with the Message-Authenticator 698 attribute, completing the maximum number of attributes of 11. 700 Access-Accept (ID = 30) 701 User-Name 702 EAP-Message 703 Example-Long-1 [M] 704 Example-Long-1 [M] 705 Example-Long-1 [M] 706 Example-Long-1 [M] 707 Example-Long-1 [MT] 708 Frag-Status = More-Data-Pending 709 Service-Type = Additional-Authorization 710 State = 0xcba00004 711 Message-Authenticator 713 Figure 9: Access-Accept (chunk 1) 715 Compliant clients receiving this packet will see the Frag-Status 716 attribute, wand suspend all authorization and authentication handling 717 until all of the chunks have been received. Non-compliant clients 718 should also see the Service-Type indicating the provisioning for an 719 unknown service, and will treat it as an Access-Reject. 721 Clients who wish to receive all of the chunks will respond with the 722 following packet, where the value of the State attribute is taken 723 from the received Access-Accept. They also include the User-Name 724 attribute so that non-compliant proxies can process the packet 725 (Section 10.1). 727 Access-Request (ID = 131) 728 User-Name 729 Frag-Status = More-Data-Request 730 Service-Type = Additional-Authorization 731 State = 0xcba00004 732 Message-Authenticator 734 Figure 10: Access-Request (chunk 1) 736 The AS receives this request, and uses the State attribute to 737 associate it with an ongoing chunking session. Compliant ASes will 738 then continue the chunking process. Non-compliant ASes will never 739 see a response such as this, as they will never send a Frag-Status 740 attribute. 742 The AS continues the chunking process by sending the next chunk, with 743 the final attribute(s) from the original packet. The value of the 744 Identifier field is taken from the received Access-Request. A Frag- 745 Status attribute is not included in the next Access-Accept, as no 746 more chunks are available for sending. The AS includes the original 747 State attribute to allow the client to send additional authorization 748 data. The original Service-Type attribute is included as well. 750 Access-Accept (ID = 131) 751 Example-Long-1 [M] 752 Example-Long-1 [M] 753 Example-Long-1 [M] 754 Example-Long-1 755 Example-Long-2 [M] 756 Example-Long-2 [M] 757 Example-Long-2 758 Service-Type = Login 759 State = 0xfda000003 760 Message-Authenticator 762 Figure 11: Access-Accept (chunk 2) 764 On reception of this last chunk, the client matches it with an 765 ongoing session via the Identifier field, and sees that there is no 766 Frag-Status attribute present. It then processes the received 767 attributes as if they had been sent in one RADIUS packet. See 768 Section 7.4 for further details of this process. 770 5. Chunk size 772 In an ideal scenario, each intermediate chunk would be exactly the 773 size limit in length. In this way, the number of round trips 774 required to send a large packet would be optimal. However, this is 775 not possible for several reasons. 777 1. RADIUS attributes have a variable length, and must be included 778 completely in a chunk. Thus, it is possible that, even if there 779 is some free space in the chunk, it is not enough to include the 780 next attribute. This can generate up to 254 octets of spare 781 space on every chunk. 783 2. RADIUS fragmentation requires the introduction of some extra 784 attributes for signalling. Specifically, a Frag-Status attribute 785 (7 octets) is included on every chunk of a packet, except the 786 last one. A RADIUS State attribute (from 3 to 255 octets) is 787 also included in most chunks, to allow the server to bind an 788 Access-Request with a previous Access-Challenge. User-Name 789 attributes (from 3 to 255 octets) are introduced on every chunk 790 the client sends as they are required by the proxies to route the 791 packet to its destination. Together, these attributes can 792 generate from up to 13 to 517 octets of signalling data, reducing 793 the amount of payload information that can be sent on each chunk. 795 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 796 MTU. Otherwise, IP fragmentation may occur, having undesirable 797 consequences. Hence, maximum chunk size would be decreased from 798 4096 to the actual MTU of the network. 800 4. The inclusion of Proxy-State attributes by intermediary proxies 801 can decrease the availability of usable space into the chunk. 802 This is described with further detail in Section 7.1. 804 6. Allowed large packet size 806 There are no provisions for signalling how much data is to be sent 807 via the fragmentation process as a whole. It is difficult to define 808 what is meant by the "length" of any fragmented data. That data can 809 be multiple attributes, which includes RADIUS attribute header 810 fields. Or it can be one or more "large" attributes (more than 256 811 octets in length). Proxies can also filter these attributes, to 812 modify, add, or delete them and their contents. These proxies act on 813 a "packet by packet" basis, and cannot know what kind of filtering 814 actions they take on future packets. As a result, it is impossible 815 to signal any meaningful value for the total amount of additional 816 data. 818 Unauthenticated clients are permitted to trigger the exchange of 819 large amounts of fragmented data between the NAS and the AS, having 820 the potential to allow Denial of Service (DoS) attacks. An attacker 821 could initiate a large number of connections, each of which requests 822 the server to store a large amount of data. This data could cause 823 memory exhaustion on the server, and result in authentic users being 824 denied access. It is worth noting that authentication mechanisms are 825 already designed to avoid exceeding the size limit. 827 Hence, implementations of this specification MUST limit the total 828 amount of data they send and/or receive via this specification. Its 829 default value SHOULD be 100K. Any more than this may turn RADIUS into 830 a generic transport protocol, which is undesired. This limit SHOULD 831 be configurable, so that it can be changed if necessary. 833 Implementations of this specification MUST limit the total number of 834 round trips used during the fragmentation process. Its default value 835 SHOULD be to 25. Any more than this may indicate an implementation 836 error, misconfiguration, or a denial of service (DoS) attack. This 837 limit SHOULD be configurable, so that it can be changed if necessary. 839 For instance, let's imagine the RADIUS server wants to transport an 840 SAML assertion which is 15000 octets long, to the RADIUS client. In 841 this hypothetical scenario, we assume there are 3 intermediate 842 proxies, each one inserting a Proxy-State attribute of 20 octets. 843 Also we assume the State attributes generated by the RADIUS server 844 have a size of 6 octets, and the User-Name attribute take 50 octets. 845 Therefore, the amount of free space in a chunk for the transport of 846 the SAML assertion attributes is: Total (4096) - RADIUS header (20) - 847 User-Name (50 octets) - Frag-Status (7 octets) - Service-Type (6 848 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State 849 (20) - Proxy-State (20) - Message-Authenticator (18 octets), 850 resulting in a total of 3929 octets, that is, 15 attributes of 255 851 bytes. 853 According to [RFC6929], a Long-Extended-Type provides a payload of 854 251 octets. Therefore, the SAML assertion described above would 855 result into 60 attributes, requiring of 4 round-trips to be 856 completely transmitted. 858 7. Handling special attributes 860 7.1. Proxy-State attribute 862 RADIUS proxies may introduce Proxy-State attributes into any Access- 863 Request packet they forward. Should they are unable to add this 864 information to the packet, they may silently discard forwarding it to 865 its destination, leading to DoS situations. Moreover, any Proxy- 866 State attribute received by a RADIUS server in an Access-Request 867 packet MUST be copied into the reply packet to it. For these 868 reasons, Proxy-State attributes require a special treatment within 869 the packet fragmentation mechanism. 871 When the RADIUS server replies to an Access-Request packet as part of 872 a conversation involving a fragmentation (either a chunk or a request 873 for chunks), it MUST include every Proxy-State attribute received 874 into the reply packet. This means that the server MUST take into 875 account the size of these Proxy-State attributes in order to 876 calculate the size of the next chunk to be sent. 878 However, while a RADIUS server will always know how much space MUST 879 be left on each reply packet for Proxy-State attributes (as they are 880 directly included by the RADIUS server), a RADIUS client cannot know 881 this information, as Proxy-State attributes are removed from the 882 reply packet by their respective proxies before forwarding them back. 883 Hence, clients need a mechanism to discover the amount of space 884 required by proxies to introduce their Proxy-State attributes. In 885 the following we describe a new mechanism to perform such a 886 discovery: 888 1. When a RADIUS client does not know how much space will be 889 required by intermediate proxies for including their Proxy-State 890 attributes, it SHOULD start using a conservative value (e.g. 1024 891 octets) as the chunk size. 893 2. When the RADIUS server receives a chunk from the client, it can 894 calculate the total size of the Proxy-State attributes that have 895 been introduced by intermediary proxies along the path. This 896 information MUST be returned to the client in the next reply 897 packet, encoded into a new attribute called Proxy-State-Len. The 898 server MAY artificially increase this quantity in order to handle 899 with situations where proxies behave inconsistently (e.g. they 900 generate Proxy-State attributes with a different size for each 901 packet), or for situations where intermediary proxies remove 902 Proxy-State attributes generated by other proxies. Increasing 903 this value would make the client to leave some free space for 904 these situations. 906 3. The RADIUS client SHOULD react upon the reception of this 907 attribute by adjusting the maximum size for the next chunk 908 accordingly. However, as the Proxy-State-Len offers just an 909 estimation of the space required by the proxies, the client MAY 910 select a smaller amount in environments known to be problematic. 912 7.2. State attribute 914 This RADIUS fragmentation mechanism makes use of the State attribute 915 to link all the chunks belonging to the same fragmented packet. 916 However, some considerations are required when the RADIUS server is 917 fragmenting a packet that already contains a State attribute for 918 other purposes not related with the fragmentation. If the procedure 919 described in Section 4 is followed, two different State attributes 920 could be included into a single chunk, incurring into two problems. 921 First, [RFC2865] explicitly forbids that more than one State 922 attribute appears into a single packet. 924 A straightforward solution consists on making the RADIUS server to 925 send the original State attribute into the last chunk of the sequence 926 (attributes can be re-ordered as specified in [RFC2865]). As the 927 last chunk (when generated by the RADIUS server) does not contain any 928 State attribute due to the fragmentation mechanism, both situations 929 described above are avoided. 931 Something similar happens when the RADIUS client has to send a 932 fragmented packet that contains a State attribute on it. The client 933 MUST assure that this original State is included into the first chunk 934 sent to the server (as this one never contains any State attribute 935 due to fragmentation). 937 7.3. Service-Type attribute 939 This RADIUS fragmentation mechanism makes use of the Service-Type 940 attribute to indicate an Access-Accept packet is not granting access 941 to the service yet, since additional authorization exchange needs to 942 be performed. Similarly to the State attribute, the RADIUS server 943 has to send the original Service-Type attribute into the last Access- 944 Accept of the RADIUS conversation to avoid ambiguity. 946 7.4. Rebuilding the original large packet 948 The RADIUS client stores the RADIUS attributes received on each chunk 949 in order to be able to rebuild the original large packet after 950 receiving the last chunk. However, some of these received attributes 951 MUST NOT be stored in this list, as they have been introduced as part 952 of the fragmentation signalling and hence, they are not part of the 953 original packet. 955 o State (except the one in the last chunk, if present) 957 o Service-Type = Additional-Authorization 959 o Frag-Status 961 o Proxy-State-Len 963 Similarly, the RADIUS server MUST NOT store the following attributes 964 as part of the original large packet: 966 o State (except the one in the first chunk, if present) 968 o Service-Type = Additional-Authorization 970 o Frag-Status 972 o Proxy-State (except the ones in the last chunk) 973 o User-Name (except the one in the first chunk) 975 8. New flag T field for the Long Extended Type attribute definition 977 This document defines a new field in the "Long Extended Type" 978 attribute format. This field is one bit in size, and is called "T" 979 for Truncation. It indicates that the attribute is intentionally 980 truncated in this chunk, and is to be continued in the next chunk of 981 the sequence. The combination of the flags "M" and "T" indicates 982 that the attribute is fragmented (flag M), but that all the fragments 983 are not available in this chunk (flag T). Proxies implementing 984 [RFC6929] will see these attributes as invalid (they will not be able 985 to reconstruct them), but they will still forward them as [RFC6929] 986 section 5.2 indicates they SHOULD forward unknown attributes anyway. 988 As a consequence of this addition, the Reserved field is now 6 bits 989 long (see Section 11.1 for some considerations). The following 990 figure represents the new attribute format. 992 0 1 2 3 993 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 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Type | Length | Extended-Type |M|T| Reserved | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Value ... 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 Figure 12: Updated Long Extended Type attribute format 1002 9. New attribute definition 1004 This document proposes the definition of two new extended type 1005 attributes, called Frag-Status and Proxy-State-Len. The format of 1006 these attributes follows the indications for an Extended Type 1007 attribute defined in [RFC6929]. 1009 9.1. Frag-Status attribute 1011 This attribute is used for fragmentation signalling, and its meaning 1012 depends on the code value transported within it. The following 1013 figure represents the format of the Frag-Status attribute. 1015 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type | Length | Extended-Type | Code 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 Code (cont) | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 13: Frag-Status format 1025 Type 1027 To be assigned (TBA) 1029 Length 1031 7 1033 Extended-Type 1035 To be assigned (TBA). 1037 Code 1039 4 byte. Integer indicating the code. The values defined in this 1040 specifications are: 1042 0 - Reserved 1044 1 - Fragmentation-Supported 1046 2 - More-Data-Pending 1048 3 - More-Data-Request 1050 This attribute MAY be present in Access-Request, Access-Challenge and 1051 Access-Accept packets. It MUST NOT be included in Access-Reject 1052 packets. Clients supporting this specification MUST include a Frag- 1053 Status = Fragmentation-Supported attribute in the first Access- 1054 Request sent to the server, in order to indicate they would accept 1055 fragmented data from the sever. 1057 9.2. Proxy-State-Len attribute 1059 This attribute indicates to the RADIUS client the length of the 1060 Proxy-State attributes received by the RADIUS server. This 1061 information is useful to adjust the length of the chunks sent by the 1062 RADIUS client. The format of this Proxy-State-Len attribute is the 1063 following: 1065 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Type | Length | Extended-Type | Value 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Value (cont) | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Figure 14: Proxy-State-Len format 1075 Type 1077 To be assigned (TBA) 1079 Length 1081 7 1083 Extended-Type 1085 To be assigned (TBA). 1087 Value 1089 4 octets. Total length (in octets) of received Proxy-State 1090 attributes (including headers). 1092 This attribute MAY be present in Access-Challenge and Access-Accept 1093 packets. It MUST NOT be included in Access-Request or Access-Reject 1094 packets. 1096 9.3. Table of attributes 1098 The following table shows the different attributes defined in this 1099 document related with the kind of RADIUS packets where they can be 1100 present. 1102 | Kind of packet | 1103 +-----+-----+-----+-----+ 1104 Attribute Name | Req | Acc | Rej | Cha | 1105 ----------------------+-----+-----+-----+-----+ 1106 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 1107 ----------------------+-----+-----+-----+-----+ 1108 Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | 1109 ----------------------+-----+-----+-----+-----+ 1111 10. Operation with proxies 1113 The fragmentation mechanism defined above is designed to be 1114 transparent to legacy proxies, as long as they do not want to modify 1115 any fragmented attribute. Nevertheless, updated proxies supporting 1116 this specification can even modify fragmented attributes. 1118 10.1. Legacy proxies 1120 As every chunk is indeed a RADIUS packet, legacy proxies treat them 1121 as the rest of packets, routing them to their destination. Proxies 1122 can introduce Proxy-State attributes to Access-Request packets, even 1123 if they are indeed chunks. This will not affect how fragmentation is 1124 managed. The server will include all the received Proxy-State 1125 attributes into the generated response, as described in [RFC2865]. 1126 Hence, proxies do not distinguish between a regular RADIUS packet and 1127 a chunk. 1129 10.2. Updated proxies 1131 Updated proxies can interact with clients and servers in order to 1132 obtain the complete large packet before starting forwarding it. In 1133 this way, proxies can manipulate (modify and/or remove) any attribute 1134 of the packet, or introduce new attributes, without worrying about 1135 crossing the boundaries of the chunk size. Once the manipulated 1136 packet is ready, it is sent to the original destination using the 1137 fragmentation mechanism (if required). The following example shows 1138 how an updated proxy interacts with the NAS to obtain a large Access- 1139 Request packet, modify an attribute resulting into a even more large 1140 packet, and interacts with the AS to complete the transmission of the 1141 modified packet. 1143 +-+-+-+-+ +-+-+-+-+ 1144 | NAS | | Proxy | 1145 +-+-+-+-+ +-+-+-+-+ 1146 | | 1147 | Access-Request(1){User-Name,Calling-Station-Id, | 1148 | Example-Long-1[M],Example-Long-1[M], | 1149 | Example-Long-1[M],Example-Long-1[M], | 1150 | Example-Long-1[MT],Frag-Status(MDP)} | 1151 |--------------------------------------------------->| 1152 | | 1153 | Access-Challenge(1){User-Name, | 1154 | Frag-Status(MDR),State1} | 1155 |<---------------------------------------------------| 1156 | | 1157 | Access-Request(2)(User-Name,State1, | 1158 | Example-Long-1[M],Example-Long-1[M], | 1159 | Example-Long-1[M],Example-Long-1} | 1160 |--------------------------------------------------->| 1162 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 1163 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 1165 Figure 15: Updated proxy interacts with NAS 1167 +-+-+-+-+ +-+-+-+-+ 1168 | Proxy | | AS | 1169 +-+-+-+-+ +-+-+-+-+ 1170 | | 1171 | Access-Request(3){User-Name,Calling-Station-Id, | 1172 | Example-Long-1[M],Example-Long-1[M], | 1173 | Example-Long-1[M],Example-Long-1[M], | 1174 | Example-Long-1[MT],Frag-Status(MDP)} | 1175 |--------------------------------------------------->| 1176 | | 1177 | Access-Challenge(1){User-Name, | 1178 | Frag-Status(MDR),State2} | 1179 |<---------------------------------------------------| 1180 | | 1181 | Access-Request(4){User-Name,State2, | 1182 | Example-Long-1[M],Example-Long-1[M], | 1183 | Example-Long-1[M],Example-Long-1[M], | 1184 | Example-Long-1[MT],Frag-Status(MDP)} | 1185 |--------------------------------------------------->| 1186 | | 1187 | Access-Challenge(1){User-Name, | 1188 | Frag-Status(MDR),State3} | 1189 |<---------------------------------------------------| 1190 | | 1191 | Access-Request(5){User-Name,State3,Example-Long-1} | 1192 |--------------------------------------------------->| 1194 Figure 16: Updated proxy interacts with AS 1196 11. Operational considerations 1198 11.1. Flag T 1200 As described in Section 8, this document modifies the definition of 1201 the "Reserved" field of the "Long Extended Type" attribute [RFC6929], 1202 by allocating an additional flag "T". The meaning and position of 1203 this flag is defined in this document, and nowhere else. This might 1204 generate an issue if subsequent specifications want to allocate a new 1205 flag as well, as there would be no direct way for them to know which 1206 parts of the "Reserved" field have already been defined. 1208 An immediate and reasonable solution for this issue would be 1209 declaring that this draft updates [RFC6929]. In this way, [RFC6929] 1210 would include an "Updated by" clause that will point readers to this 1211 document. However, since this draft belongs to the Experimental 1212 track and [RFC6929] belongs to the Standards track, we do not know if 1213 including that "Updates" clause would be acceptable. 1215 Another alternative would be creating an IANA registry for the 1216 "Reserved" field. However, the working group thinks that would be 1217 overkill, as not such a great number of specifications extending that 1218 field are expected. 1220 Hence, we have decided to include the "Updates" clause in the 1221 document so far. 1223 11.2. Violation of RFC2865 1225 Section 4.1 indicates that all authorization and authentication 1226 handling will be postponed until all the chunks have been received. 1227 This postponement also affects to the verification that the Access- 1228 Request packet contains some kind of authentication attribute (e.g. 1229 User-Password, CHAP-Password, State or other future attribute), as 1230 required by [RFC2865]. This checking will therefore be delayed until 1231 the original large packet has been rebuilt, as some of the chunks may 1232 not contain any of them. 1234 The authors acknowledge that this specification violates the "MUST" 1235 requirement of [RFC2865] Section 4.1. We note that a proxy which 1236 enforces that requirement would be unable to support future RADIUS 1237 authentication extensions. Extensions to the protocol would 1238 therefore be impossible to deploy. All known implementations have 1239 chosen the philosophy of "be liberal in what you accept". That is, 1240 they accept traffic which violates the requirement of [RFC2865] 1241 Section 4.1. We therefore expect to see no operational issues with 1242 this specification. After we gain more operational experience with 1243 this specification, it can be re-issued as a standards track 1244 document, and update [RFC2865]. 1246 11.3. Proxying based on User-Name 1248 This proposal assumes legacy proxies to base their routing decisions 1249 on the value of the User-Name attribute. For this reason, every 1250 packet sent from the client to the server (either chunks or requests 1251 for more chunks) MUST contain a User-Name attribute. 1253 11.4. Transport behaviour 1255 This proposal does not modify the way RADIUS interacts with the 1256 underlying transport (UDP). That is, RADIUS keeps following a lock- 1257 step behaviour, that requires receiving an explicit acknowledge for 1258 each chunk sent. Hence, bursts of traffic which could congest links 1259 between peers are not an issue. 1261 12. Security Considerations 1263 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1264 RADIUS security is problematic. This specification changes nothing 1265 related to the security of the RADIUS protocol. It requires that all 1266 Access-Request packets associated with fragmentation are 1267 authenticated using the existing Message-Authenticator attribute. 1268 This signature prevents forging and replay, to the limits of the 1269 existing security. 1271 The ability to send bulk data from one party to another creates new 1272 security considerations. Clients and servers may have to store large 1273 amounts of data per session. The amount of this data can be 1274 significant, leading to the potential for resource exhaustion. We 1275 therefore suggest that implementations limit the amount of bulk data 1276 stored per session. The exact method for this limitation is 1277 implementation-specific. Section 6 gives some indications on what 1278 could be reasonable limits. 1280 The bulk data can often be pushed off to storage methods other than 1281 the memory of the RADIUS implementation. For example, it can be 1282 stored in an external database, or in files. This approach mitigates 1283 the resource exhaustion issue, as servers today already store large 1284 amounts of accounting data. 1286 13. IANA Considerations 1288 The authors request that Attribute Types and Attribute Values defined 1289 in this document be registered by the Internet Assigned Numbers 1290 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1291 Considerations" section of [RFC3575], in accordance with BCP 26 1292 [RFC5226]. For RADIUS packets, attributes and registries created by 1293 this document IANA is requested to place them at 1294 http://www.iana.org/assignments/radius-types. 1296 In particular, this document defines two new RADIUS attributes, 1297 entitled "Frag-Status" and "Proxy-State-Len" (see section 9), 1298 assigned values of TBD1 and TBD2 from the Long Extended Space of 1299 [RFC2865]: 1301 Tag Name Length Meaning 1302 ---- ---- ------ ------- 1303 TBD1 Frag-Status 7 Signals fragmentation 1304 TBD2 Proxy-State-Len 7 Indicates the length of the 1305 received Proxy-State attributes 1307 The Frag-Status attribute also defines a 8-bit "Code" field, for 1308 which the IANA is to create and maintain a new sub-registry entitled 1309 "Code values" under the RADIUS "Frag-Status" attribute. Initial 1310 values for the RADIUS Frag-Status "Code" registry are given below; 1311 future assignments are to be made through "RFC required" [IANA- 1312 CONSIDERATIONS]. Assignments consist of a Frag-Status "Code" name 1313 and its associated value. 1315 Value Frag-Status Code Name Definition 1316 ---- ------------------------ ---------- 1317 0 Reserved See Section 9.1 1318 1 Fragmentation-Supported See Section 9.1 1319 2 More-Data-Pending See Section 9.1 1320 3 More-Data-Request See Section 9.1 1321 4-255 Unassigned 1323 Additionally, allocation of a new Service-Type value for "Additional- 1324 Authorization" is requested. 1326 Value Service Type Value Definition 1327 ---- ------------------------ ---------- 1328 TBA Additional-Authorization See section 4.1 1330 14. Acknowledgements 1332 The authors would like to thank the members of the RADEXT working 1333 group who have contributed to the development of this specification, 1334 either by participating on the discussions on the mailing lists or by 1335 sending comments about our draft. 1337 The authors also thank David Cuenca (University of Murcia) for 1338 implementing a proof of concept implementation of this draft that has 1339 been useful to improve the quality of the specification. 1341 This work has been partly funded by the GEANT GN3+ SA5 and CLASSe 1342 (http://sec.cs.kent.ac.uk/CLASSe/) projects. 1344 15. References 1346 15.1. Normative References 1348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1349 Requirement Levels", BCP 14, RFC 2119, March 1997. 1351 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1352 "Remote Authentication Dial In User Service (RADIUS)", 1353 RFC 2865, June 2000. 1355 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1356 Authentication Dial In User Service)", RFC 3575, 1357 July 2003. 1359 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1360 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1361 May 2008. 1363 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1364 BCP 158, RFC 6158, March 2011. 1366 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1367 Service (RADIUS) Protocol Extensions", RFC 6929, 1368 April 2013. 1370 15.2. Informative References 1372 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1374 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1375 Dial In User Service) Support For Extensible 1376 Authentication Protocol (EAP)", RFC 3579, September 2003. 1378 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1379 Rule Attribute", RFC 4849, April 2007. 1381 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1382 Dial In User Service (RADIUS) Implementation Issues and 1383 Suggested Fixes", RFC 5080, December 2007. 1385 Authors' Addresses 1387 Alejandro Perez-Mendez (Ed.) 1388 University of Murcia 1389 Campus de Espinardo S/N, Faculty of Computer Science 1390 Murcia, 30100 1391 Spain 1393 Phone: +34 868 88 46 44 1394 Email: alex@um.es 1395 Rafa Marin-Lopez 1396 University of Murcia 1397 Campus de Espinardo S/N, Faculty of Computer Science 1398 Murcia, 30100 1399 Spain 1401 Phone: +34 868 88 85 01 1402 Email: rafa@um.es 1404 Fernando Pereniguez-Garcia 1405 University of Murcia 1406 Campus de Espinardo S/N, Faculty of Computer Science 1407 Murcia, 30100 1408 Spain 1410 Phone: +34 868 88 78 82 1411 Email: pereniguez@um.es 1413 Gabriel Lopez-Millan 1414 University of Murcia 1415 Campus de Espinardo S/N, Faculty of Computer Science 1416 Murcia, 30100 1417 Spain 1419 Phone: +34 868 88 85 04 1420 Email: gabilm@um.es 1422 Diego R. Lopez 1423 Telefonica I+D 1424 Don Ramon de la Cruz, 84 1425 Madrid, 28006 1426 Spain 1428 Phone: +34 913 129 041 1429 Email: diego@tid.es 1430 Alan DeKok 1431 Network RADIUS 1432 15 av du Granier 1433 Meylan, 38240 1434 France 1436 Phone: +34 913 129 041 1437 Email: aland@networkradius.com 1438 URI: http://networkradius.com