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