idnits 2.17.1 draft-ietf-radext-radius-fragmentation-06.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 (April 7, 2014) is 3664 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1136, but not defined == Missing Reference: 'MT' is mentioned on line 1137, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 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: October 9, 2014 University of Murcia 7 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 April 7, 2014 13 Support of fragmentation of RADIUS packets 14 draft-ietf-radext-radius-fragmentation-06 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 October 9, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 67 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 9 68 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 13 69 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 17 71 7. Handling special attributes . . . . . . . . . . . . . . . . . 18 72 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 18 73 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 19 74 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 20 75 7.4. Rebuilding the original large packet . . . . . . . . . . . 20 76 8. New flag T field for the Long Extended Type attribute 77 definition . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. New attribute definition . . . . . . . . . . . . . . . . . . . 21 79 9.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 21 80 9.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 22 81 9.3. Table of attributes . . . . . . . . . . . . . . . . . . . 23 82 10. Operation with proxies . . . . . . . . . . . . . . . . . . . . 23 83 10.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 23 84 10.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 24 85 11. Operational considerations . . . . . . . . . . . . . . . . . . 25 86 11.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 11.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 26 88 11.3. Proxying based on User-Name . . . . . . . . . . . . . . . 26 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 91 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 97 1. Introduction 99 The RADIUS [RFC2865] protocol carries authentication, authorization, 100 and accounting information between a Network Access Server (NAS) and 101 an Authentication Server (AS). Information is exchanged between the 102 NAS and the AS through RADIUS packets. Each RADIUS packet is 103 composed of a header, and zero or more attributes, up to a maximum 104 packet size of 4096 octets. The protocol is a request/response 105 protocol, as described in the operational model ( [RFC6158], Section 106 3.1). 108 The above packet size limitation mean that peers desiring to send 109 large amounts of data must fragment it across multiple packets. For 110 example, RADIUS-EAP [RFC3579] defines how an EAP exchange occurs 111 across multiple Access-Request / Access-Challenge sequences. No such 112 exchange is possible for accounting or authorization data. [RFC6158] 113 Section 3.1 suggests that exchanging large amounts authorization data 114 is unnecessary in RADIUS. Instead, the data should be referenced by 115 name. This requirement allows large policies to be pre-provisioned, 116 and then referenced in an Access-Accept. In some cases, however, the 117 authorization data sent by the server is large and highly dynamic. 118 In other cases, the NAS needs to send large amounts of authorization 119 data to the server. Both of these cases are un-met by the 120 requirements in [RFC6158]. As noted in that document, the practical 121 limit on RADIUS packet sizes is governed by the Path MTU (PMTU), 122 which may be significantly smaller than 4096 octets. The combination 123 of the two limitations means that there is a pressing need for a 124 method to send large amounts of authorization data between NAS and 125 AS, with no accompanying solution. 127 [RFC6158] recommends three approaches for the transmission of large 128 amount of data within RADIUS. However, they are not applicable to 129 the problem statement of this document for the following reasons: 131 o The first approach does not talk about large amounts of data sent 132 from the NAS to a server. Leveraging EAP (request/challenge) to 133 send the data is not feasible, as EAP already fills packet to 134 PMTU, and not all authentications use EAP. Moreover, as noted for 135 NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the 136 problem of sending large amounts of data from a server to a NAS. 138 o The second approach is not usable either, as using names rather 139 than values is difficult when the nature of the data to be sent is 140 highly dynamic (e.g. SAML sentences or NAS-Filter-Rule 141 attributes). URLs could be used as a pointer to the location of 142 the actual data, but their use would require them to be (a) 143 dynamically created and modified, (b) securely accessed and (c) 144 accessible from remote systems. Satisfying these constraints 145 would require the modification of several networking systems (e.g. 146 firewalls and web servers). Furthermore, the set up of an 147 additional trust infrastructure (e.g. PKI) would be required to 148 allow secure retrieving of the information from the web server. 150 o PMTU discovery does not solve the problem, as it does not allow to 151 send data larger than the minimum of (PMTU or 4096) octets. 153 This document provides a mechanism to allow RADIUS peers to exchange 154 large amounts of authorization data exceeding the 4096 octet limit, 155 by fragmenting it across several client/server exchanges. The 156 proposed solution does not impose any additional requirements to the 157 RADIUS system administrators (e.g. need to modify firewall rules, set 158 up web servers, configure routers, or modify any application server). 159 It maintains compatibility with intra-packet fragmentation mechanisms 160 (like those defined in [RFC3579] or in [RFC6929]). It is also 161 transparent to existing RADIUS proxies, which do not implement this 162 specification. The only systems needing to implement the draft are 163 the ones which either generate, or consume the fragmented data being 164 transmitted. Intermediate proxies just pass the packets without 165 changes. Nevertheless, if a proxy supports this specification, it 166 may re-assemble the data in order to either examine and/or modify it. 168 1.1. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 173 When these words appear in lower case, they have their natural 174 language meaning. 176 2. Scope of this document 178 This specification describes how a RADIUS client and a RADIUS server 179 can exchange data exceeding the 4096 octet limit imposed by one 180 packet. However, the mechanism described in this specification MUST 181 NOT be used to exchange more than 100K of data. It has not been 182 designed to substitute for stream-oriented transport protocols, such 183 as TCP or SCTP. Experience shows that attempts to transport bulk 184 data across the Internet with UDP will inevitably fail, unless they 185 re-implement all of the behavior of TCP. The underlying design of 186 RADIUS lacks the proper retransmission policies or congestion control 187 mechanisms which would make it a competitor to TCP. 189 Therefore, RADIUS/UDP transport is by design unable to transport bulk 190 data. It is both undesired and impossible to change the protocol at 191 this point in time. This specification is intended to allow the 192 transport of slightly more than 4096 octets of data through existing 193 RADIUS/UDP proxies. Other solutions such as RADIUS/TCP MUST be used 194 when a "green field" deployment requires the transport of bulk data. 196 Section 6, below, describes with further details the reasoning for 197 this limitation, and recommends administrators to adjust it according 198 to the specific capabilities of their existing systems in terms of 199 memory and processing power. 201 Moreover, its scope is limited to the exchange of authorization data, 202 as other exchanges do not require of such a mechanism. In 203 particular, authentication exchanges have already been defined to 204 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 205 represent the most critical part of a RADIUS conversation, its 206 preferable to not introduce any modification to their operation that 207 may affect existing equipment. 209 There is no need to fragment accounting packets either. While the 210 accounting process can send large amounts of data, that data is 211 typically composed of many small updates. That is, there is no 212 demonstrated need to send indivisible blocks of more than 4K of data. 213 The need to send large amounts of data per user session often 214 originates from the need for flow-based accounting. In this use- 215 case, the client may send accounting data for many thousands of 216 flows, where all those flows are tied to one user session. The 217 existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 218 5.11 has been proven to work here. 220 Similarly, there is no need to fragment CoA packets. Instead, the 221 CoA client MUST send a CoA-Request packet containing session 222 identification attributes, along with Service-Type = Additional- 223 Authorization, and a State attribute. Implementations not supporting 224 fragmentation will respond with a CoA-NAK, and an Error-Cause of 225 Unsupported-Service. 227 The above requirement does not assume that the CoA client and the 228 RADIUS server are co-located. They may, in fact be run on separate 229 parts of the infrastructure, or even by separate administrators. 230 There is, however, a requirement that the two communicate. We can 231 see that the CoA client needs to send session identification 232 attributes in order to send CoA packets. These attributes cannot be 233 known a priori by the CoA client, and can only come from the RADIUS 234 server. Therefore, even when the two systems are not co-located, 235 they must be able to communicate in order to operate in unison. The 236 alternative is for the two systems to have differing views of the 237 users authorization parameters, which is a security disaster. 239 This specification does not allow for fragmentation of CoA packets. 241 Allowing for fragmented CoA packets would involve changing multiple 242 parts of the RADIUS protocol, with the corresponding possibility for 243 implementation issues, mistakes, etc. 245 Where CoA clients need to send large amounts of authorization data to 246 a NAS, they need only send a minimal CoA-Request packet, containing 247 Service-Type of Authorize-Only, as per RFC 5176. They SHOULD also 248 have a co-located RADIUS server, for the sole purpose of implementing 249 this specification. 251 The NAS will then perform fragmentation as per this draft to the 252 RADIUS server it is configured to use. That RADIUS server SHOULD 253 then act as a proxy, and forward the Access-Request to the RADIUS 254 server on the CoA client. That RADIUS server can then send the large 255 amounts of authorization to the proxy, which then sends them to the 256 NAS. 258 That is, the NAS sends packets to a server which proxies them to the 259 system which is co-located with the CoA client.This process is more 260 complicated than allowing for fragmented CoA packets. However, the 261 CoA client and the RADIUS server must communicate even when not using 262 this specification. We believe that standardizing that 263 communication, and using one method for exchange of large data is 264 preferred to unspecified communication methods and multiple ways of 265 achieving the same result. 267 The above requirement solves a number of issues. It clearly 268 separates session identification from authorization. Without this 269 separation, it is difficult to both identify a session, and change 270 its authorization using the same attribute. It also ensures that the 271 authorization process is the same for initial authentication, and for 272 CoA. 274 When a sessions authorization is changed, the CoA server MUST 275 continue the existing service until the new authorization parameters 276 are applied. The change of service SHOULD be done atomically. If 277 the CoA server is unable to apply the new authorization, it MUST 278 terminate the user session. 280 3. Overview 282 Authorization exchanges can occur either before or after end user 283 authentication has been completed. An authorization exchange before 284 authentication allows a RADIUS client to provide the RADIUS server 285 with information that MAY modify how the authentication process will 286 be performed (e.g. it may affect the selection of the EAP method). 287 An authorization exchange after authentication allows the RADIUS 288 server to provide the RADIUS client with information about the end 289 user, the results of the authentication process and/or obligations to 290 be enforced. In this specification we refer to the "pre- 291 authorization" as the exchange of authorization information before 292 the end user authentication has started, while the term "post- 293 authorization" is used to refer to an authorization exchange 294 happening after this authentication process. 296 In this specification we refer to the "size limit" as the practical 297 limit on RADIUS packet sizes. This limit is the minimum of 4096 298 octets, and the current PMTU. We define below a method which uses 299 Access-Request and Access-Accept in order to exchange fragmented 300 data. The NAS and server exchange a series of Access-Request / 301 Access-Accept packets, until such time as all of the fragmented data 302 has been transported. Each packet contains a Frag-Status attribute 303 which lets the other party know if fragmentation is desired, ongoing, 304 or finished. Each packet may also contain the fragmented data, or 305 instead be an "ACK" to a previous fragment from the other party. 306 Each Access-Request contains a User-Name attribute, allowing the 307 packet to be proxied if necessary (see Section 10.1). Each Access- 308 Request may also contain a State attribute, which serves to tie it to 309 a previous Access-Accept. Each Access-Accept contains a State 310 attribute, for use by the NAS in a later Access-Request. Each 311 Access-Accept contains a Service-Type indicating that the service 312 being provided is fragmentation, and that the Access-Accept should 313 not be interpreted as providing network access to the end user. 315 When a RADIUS client or server need to send data that exceeds the 316 size limit, the mechanism proposed in this document is used. Instead 317 of encoding one large RADIUS packet, a series of smaller RADIUS 318 packets of the same type are encoded. Each smaller packet is called 319 a "chunk" in this specification, in order to distinguish it from 320 traditional RADIUS packets. The encoding process is a simple linear 321 walk over the attributes to be encoded. This walk preserves the 322 order of the attributes of the same type, as required by [RFC2865]. 323 The number of attributes encoded in a particular chunk depends on the 324 size limit, the size of each attribute, the number of proxies between 325 client and server, and the overhead for fragmentation signalling 326 attributes. Specific details are given in Section 5. A a new 327 attribute called Frag-Status (Section 9.1) signals the fragmentation 328 status. 330 After the first chunk is encoded, it is sent to the other party. The 331 packet is identified as a chunk via the Frag-Status attribute. The 332 other party then requests additional chunks, again using the Frag- 333 Status attribute. This process is repeated until all the attributes 334 have been sent from one party to the other. When all the chunks have 335 been received, the original list of attributes is reconstructed and 336 processed as if it had been received in one packet. 338 When multiple chunks are sent, a special situation may occur for 339 Extended Type attributes as defined in [RFC6929]. The fragmentation 340 process may split a fragmented attribute across two or more chunks, 341 which is not permitted by that specification. We address this issue 342 by using the newly defined flag "T" in the Reserved field of the 343 "Long Extended Type" attribute format (see Section 8 for further 344 details on this flag). 346 This last situation is expected to be the most common occurrence in 347 chunks. Typically, packet fragmentation will occur as a consequence 348 of a desire to send one or more large (and therefore fragmented) 349 attributes. The large attribute will likely be split into two or 350 more pieces. Where chunking does not split a fragmented attribute, 351 no special treatment is necessary. 353 The setting of the "T" flag is the only case where the chunking 354 process affects the content of an attribute. Even then, the "Value" 355 fields of all attributes remain unchanged. Any per-packet security 356 attributes such as Message-Authenticator are calculated for each 357 chunk independently. There are neither integrity nor security checks 358 performed on the "original" packet. 360 Each RADIUS packet sent or received as part of the chunking process 361 MUST be a valid packet, subject to all format and security 362 requirements. This requirement ensures that a "transparent" proxy 363 not implementing this specification can receive and send compliant 364 packets. That is, a proxy which simply forwards packets without 365 detailed examination or any modification will be able to proxy 366 "chunks". 368 4. Fragmentation of packets 370 When the NAS or the AS desires to send a packet that exceeds the size 371 limit, it is split into chunks and sent via multiple client/server 372 exchanges. The exchange is indicated via the Frag-Status attribute, 373 which has value More-Data-Pending for all but the last chunk of the 374 series. The chunks are tied together via the State attribute. 376 The following sections describe how to perform fragmentation for 377 packets from the NAS to the server, followed by packets from the 378 server to the NAS. We give the packet type, along with a RADIUS 379 Identifier, to indicate that requests and responses are connected. 380 We then give a list of attributes. We do not give values for most 381 attributes, as we wish to concentrate on the fragmentation behaviour, 382 rather than packet contents. Attribute values are given for 383 attributes relevant to the fragmentation process. Where "long 384 extended" attributes are used, we indicate the M (More) and T 385 (Truncation) flags as optional square brackets after the attribute 386 name. As no "long extended" attributes have yet been defined, we use 387 example attributes, named as "Example-Long-1", etc. The maximum 388 chunk size is established in term of number of attributes (11), for 389 sake of simplicity. 391 4.1. Pre-authorization 393 When the client needs to send a large amount of data to the server, 394 the data to be sent is split into chunks and sent to the server via 395 multiple Access-Request / Access-Accept exchanges. The example below 396 shows this exchange. 398 The following is an Access-Request which the NAS intends to send to a 399 server. However, due to a combination of issues (PMTU, large 400 attributes, etc.), the content does not fit into one Access-Request 401 packet. 403 Access-Request 404 User-Name 405 NAS-Identifier 406 Calling-Station-Id 407 Example-Long-1 [M] 408 Example-Long-1 [M] 409 Example-Long-1 [M] 410 Example-Long-1 [M] 411 Example-Long-1 [M] 412 Example-Long-1 [M] 413 Example-Long-1 [M] 414 Example-Long-1 [M] 415 Example-Long-1 416 Example-Long-2 [M] 417 Example-Long-2 [M] 418 Example-Long-2 420 Figure 1: Desired Access-Request 422 The NAS therefore must send the attributes listed above in a series 423 of chunks. The first chunk contains eight (8) attributes from the 424 original Access-Request, and a Frag-Status attribute. Since last 425 attribute is "Example-Long-1" with the "M" flag set, the chunking 426 process also sets the "T" flag in that attribute. The Access-Request 427 is sent with a RADIUS Identifier field having value 23. The Frag- 428 Status attribute has value More-Data-Pending, to indicate that the 429 NAS wishes to send more data in a subsequent Access-Request. The NAS 430 also adds a Service-Type attribute, which indicates that it is part 431 of the chunking process. The packet is signed with the Message- 432 Authenticator attribute, completing the maximum number of attributes 433 (11). 435 Access-Request (ID = 23) 436 User-Name 437 NAS-Identifier 438 Calling-Station-Id 439 Example-Long-1 [M] 440 Example-Long-1 [M] 441 Example-Long-1 [M] 442 Example-Long-1 [M] 443 Example-Long-1 [MT] 444 Frag-Status = More-Data-Pending 445 Service-Type = Additional-Authorization 446 Message-Authenticator 448 Figure 2: Access-Request (chunk 1) 450 Compliant servers (i.e. servers implementing fragmentation) receiving 451 this packet will see the Frag-Status attribute, and postpone all 452 authorization and authentication handling until all of the chunks 453 have been received. This postponement also affects to the 454 verification that the Access-Request packet contains some kind of 455 authentication attribute (e.g. User-Password, CHAP-Password, State 456 or other future attribute), as required by [RFC2865] (see 457 Section 11.2 for more information on this). 459 Non-compliant servers (i.e. servers not implementing fragmentation) 460 should also see the Service-Type requesting provisioning for an 461 unknown service, and return Access-Reject. Other non-compliant 462 servers may return an Access-Reject, Access-Challenge, or an Access- 463 Accept with a particular Service-Type other then Additional- 464 Authorization. Compliant NAS implementations MUST treat these 465 responses as if they had received Access-Reject instead. 467 Compliant servers who wish to receive all of the chunks will respond 468 with the following packet. The value of the State here is arbitrary, 469 and serves only as a unique token for example purposes. We only note 470 that it MUST be temporally unique to the server. 472 Access-Accept (ID = 23) 473 Frag-Status = More-Data-Request 474 Service-Type = Additional-Authorization 475 State = 0xabc00001 476 Message-Authenticator 478 Figure 3: Access-Accept (chunk 1) 480 The NAS will see this response, and use the RADIUS Identifier field 481 to associate it with an ongoing chunking session. Compliant NASes 482 will then continue the chunking process. Non-compliant NASes will 483 never see a response such as this, as they will never send a Frag- 484 Status attribute. The Service-Type attribute is included in the 485 Access-Accept in order to signal that the response is part of the 486 chunking process. This packet therefore does not provision any 487 network service for the end user. 489 The NAS continues the process by sending the next chunk, which 490 includes an additional six (6) attributes from the original packet. 491 It again includes the User-Name attribute, so that non-compliant 492 proxies can process the packet (see Section 10.1). It sets the Frag- 493 Status attribute to More-Data-Pending, as more data is pending. It 494 includes a Service-Type for reasons described above. It includes the 495 State attribute from the previous Access-accept. It signs the packet 496 with Message-Authenticator, as there are no authentication attributes 497 in the packet. It uses a new RADIUS Identifier field. 499 Access-Request (ID = 181) 500 User-Name 501 Example-Long-1 [M] 502 Example-Long-1 [M] 503 Example-Long-1 [M] 504 Example-Long-1 505 Example-Long-2 [M] 506 Example-Long-2 [MT] 507 Frag-Status = More-Data-Pending 508 Service-Type = Additional-Authorization 509 State = 0xabc000001 510 Message-Authenticator 512 Figure 4: Access-Request (chunk 2) 514 Compliant servers receiving this packet will see the Frag-Status 515 attribute, and look for a State attribute. Since one exists and it 516 matches a State sent in an Access-Accept, this packet is part of a 517 chunking process. The server will associate the attributes with the 518 previous chunk. Since the Frag-Status attribute has value More-Data- 519 Request, the server will respond with an Access-Accept as before. It 520 MUST include a State attribute, with a value different from the 521 previous Access-Accept. This State MUST again be globally and 522 temporally unique. 524 Access-Accept (ID = 181) 525 Frag-Status = More-Data-Request 526 Service-Type = Additional-Authorization 527 State = 0xdef00002 528 Message-Authenticator 530 Figure 5: Access-Accept (chunk 2) 532 The NAS will see this response, and use the RADIUS Identifier field 533 to associate it with an ongoing chunking session. The NAS continues 534 the chunking process by sending the next chunk, with the final 535 attribute(s) from the original packet, and again includes the 536 original User-Name attribute. The Frag-Status attribute is not 537 included in the next Access-Request, as no more chunks are available 538 for sending. The NAS includes the State attribute from the previous 539 Access-accept. It signs the packet with Message-Authenticator, as 540 there are no authentication attributes in the packet. It again uses 541 a new RADIUS Identifier field. 543 Access-Request (ID = 241) 544 User-Name 545 Example-Long-2 546 State = 0xdef00002 547 Message-Authenticator 549 Figure 6: Access-Request (chunk 3) 551 On reception of this last chunk, the server matches it with an 552 ongoing session via the State attribute, and sees that there is no 553 Frag-Status attribute present. It then process the received 554 attributes as if they had been sent in one RADIUS packet. See 555 Section 7.4 for further details of this process. It generates the 556 appropriate response, which can be either Access-Accept or Access- 557 Reject. In this example, we show an Access-Accept. The server MUST 558 send a State attribute, which permits link the received data with the 559 authentication process. 561 Access-Accept (ID = 241) 562 State = 0x98700003 563 Message-Authenticator 565 Figure 7: Access-Accept (chunk 3) 567 The above example shows in practice how the chunking process works. 568 We re-iterate the implementation and security requirements here. 570 Each chunk is a valid RADIUS packet, and all RADIUS format and 571 security requirements MUST be followed before any chunking process is 572 applied. 574 Every chunk except for the last one from a NAS MUST include a Frag- 575 Status attribute, with value More-Data-Pending. The last chunk MUST 576 NOT contain a Frag-Status attribute. Each chunk except for the last 577 from a NAS MUST include a Service-Type attribute, with value 578 Additional-Authorization. Each chunk MUST include a User-Name 579 attribute, which MUST be identical in all chunks. Each chunk except 580 for the first one from a NAS MUST include a State attribute, which 581 MUST be copied from a previous Access-Accept. 583 Each Access-Accept MUST include a State attribute. The value for 584 this attribute MUST change in every new Access-Accept, and MUST be 585 globally and temporally unique. 587 4.2. Post-authorization 589 When the AS wants to send a large amount of authorization data to the 590 NAS after authentication, the operation is very similar to the pre- 591 authorization one. The presence of Service-Type = Additional- 592 Authorization attribute ensures that a NAS not supporting this 593 specification will treat that unrecognized Service-Type as though an 594 Access-Reject had been received instead ([RFC2865] Section 5.6). If 595 the original large Access-Accept packet contained a Service-Type 596 attribute, it will be included with its original value in the last 597 transmitted chunk, to avoid confusion with the one used for 598 fragmentation signalling. It is strongly RECOMMENDED that servers 599 include a State attribute on their original Access-Accept packets, 600 even if fragmentation is not taking place, to allow the client to 601 send additional authorization data in subsequent exchanges. This 602 State attribute would be included in the last transmitted chunk, to 603 avoid confusion with the ones used for fragmentation signalling. 605 Client supporting this specification MUST include a Frag-Status = 606 Fragmentation-Supported attribute in the first Access-Request sent to 607 the server, in order to indicate they would accept fragmented data 608 from the sever. This is not required if pre-authorization process 609 was carried out, as it is implicit. 611 The following is an Access-Accept which the AS intends to send to a 612 client. However, due to a combination of issues (PMTU, large 613 attributes, etc.), the content does not fit into one Access-Accept 614 packet. 616 Access-Accept 617 User-Name 618 EAP-Message 619 Service-Type(Login) 620 Example-Long-1 [M] 621 Example-Long-1 [M] 622 Example-Long-1 [M] 623 Example-Long-1 [M] 624 Example-Long-1 [M] 625 Example-Long-1 [M] 626 Example-Long-1 [M] 627 Example-Long-1 [M] 628 Example-Long-1 629 Example-Long-2 [M] 630 Example-Long-2 [M] 631 Example-Long-2 632 State = 0xcba00003 634 Figure 8: Desired Access-Accept 636 The AS therefore must send the attributes listed above in a series of 637 chunks. The first chunk contains seven (7) attributes from the 638 original Access-Accept, and a Frag-Status attribute. Since last 639 attribute is "Example-Long-1" with the "M" flag set, the chunking 640 process also sets the "T" flag in that attribute. The Access-Accept 641 is sent with a RADIUS Identifier field having value 30 corresponding 642 to a previous Access-Request not depicted. The Frag-Status attribute 643 has value More-Data-Pending, to indicate that the AS wishes to send 644 more data in a subsequent Access-Accept. The AS also adds a Service- 645 Type attribute with value Additional-Authorization, which indicates 646 that it is part of the chunking process. Note that the original 647 Service-Type is not included in this chunk. Finally, a State 648 attribute is included to allow matching subsequent requests with this 649 conversation, and the packet is signed with the Message-Authenticator 650 attribute, completing the maximum number of attributes of 11. 652 Access-Accept (ID = 30) 653 User-Name 654 EAP-Message 655 Example-Long-1 [M] 656 Example-Long-1 [M] 657 Example-Long-1 [M] 658 Example-Long-1 [M] 659 Example-Long-1 [MT] 660 Frag-Status = More-Data-Pending 661 Service-Type = Additional-Authorization 662 State = 0xcba00004 663 Message-Authenticator 665 Figure 9: Access-Accept (chunk 1) 667 Compliant clients receiving this packet will see the Frag-Status 668 attribute, wand suspend all authorization and authentication handling 669 until all of the chunks have been received. Non-compliant clients 670 should also see the Service-Type indicating the provisioning for an 671 unknown service, and will treat it as an Access-Reject. 673 Clients who wish to receive all of the chunks will respond with the 674 following packet, where the value of the State attribute is taken 675 from the received Access-Accept. They also include the User-Name 676 attribute so that non-compliant proxies can process the packet 677 (Section 10.1). 679 Access-Request (ID = 131) 680 User-Name 681 Frag-Status = More-Data-Request 682 Service-Type = Additional-Authorization 683 State = 0xcba00004 684 Message-Authenticator 686 Figure 10: Access-Request (chunk 1) 688 The AS receives this request, and uses the State attribute to 689 associate it with an ongoing chunking session. Compliant ASes will 690 then continue the chunking process. Non-compliant ASes will never 691 see a response such as this, as they will never send a Frag-Status 692 attribute. 694 The AS continues the chunking process by sending the next chunk, with 695 the final attribute(s) from the original packet. The value of the 696 Identifier field is taken from the received Access-Request. A Frag- 697 Status attribute is not included in the next Access-Accept, as no 698 more chunks are available for sending. The AS includes the original 699 State attribute to allow the client to send additional authorization 700 data. The original Service-Type attribute is included as well. 702 Access-Accept (ID = 131) 703 Example-Long-1 [M] 704 Example-Long-1 [M] 705 Example-Long-1 [M] 706 Example-Long-1 707 Example-Long-2 [M] 708 Example-Long-2 [M] 709 Example-Long-2 710 Service-Type = Login 711 State = 0xfda000003 712 Message-Authenticator 714 Figure 11: Access-Accept (chunk 2) 716 On reception of this last chunk, the client matches it with an 717 ongoing session via the Identifier field, and sees that there is no 718 Frag-Status attribute present. It then processes the received 719 attributes as if they had been sent in one RADIUS packet. See 720 Section 7.4 for further details of this process. 722 5. Chunk size 724 In an ideal scenario, each intermediate chunk would be exactly the 725 size limit in length. In this way, the number of round trips 726 required to send a large packet would be optimal. However, this is 727 not possible for several reasons. 729 1. RADIUS attributes have a variable length, and must be included 730 completely in a chunk. Thus, it is possible that, even if there 731 is some free space in the chunk, it is not enough to include the 732 next attribute. This can generate up to 254 octets of spare 733 space on every chunk. 735 2. RADIUS fragmentation requires the introduction of some extra 736 attributes for signalling. Specifically, a Frag-Status attribute 737 (7 octets) is included on every chunk of a packet, except the 738 last one. A RADIUS State attribute (from 3 to 255 octets) is 739 also included in most chunks, to allow the server to bind an 740 Access-Request with a previous Access-Challenge. User-Name 741 attributes (from 3 to 255 octets) are introduced on every chunk 742 the client sends as they are required by the proxies to route the 743 packet to its destination. Together, these attributes can 744 generate from up to 13 to 517 octets of signalling data, reducing 745 the amount of payload information that can be sent on each chunk. 747 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 748 MTU. Otherwise, IP fragmentation may occur, having undesirable 749 consequences. Hence, maximum chunk size would be decreased from 750 4096 to the actual MTU of the network. 752 4. The inclusion of Proxy-State attributes by intermediary proxies 753 can decrease the availability of usable space into the chunk. 754 This is described with further detail in Section 7.1. 756 6. Allowed large packet size 758 There are no provisions for signalling how much data is to be sent 759 via the fragmentation process as a whole. It is difficult to define 760 what is meant by the "length" of any fragmented data. That data can 761 be multiple attributes, which includes RADIUS attribute header 762 fields. Or it can be one or more "large" attributes (more than 256 763 octets in length). Proxies can also filter these attributes, to 764 modify, add, or delete them and their contents. These proxies act on 765 a "packet by packet" basis, and cannot know what kind of filtering 766 actions they take on future packets. As a result, it is impossible 767 to signal any meaningful value for the total amount of additional 768 data. 770 Unauthenticated clients are permitted to trigger the exchange of 771 large amounts of fragmented data between the NAS and the AS, having 772 the potential to allow Denial of Service (DoS) attacks. An attacker 773 could initiate a large number of connections, each of which requests 774 the server to store a large amount of data. This data could cause 775 memory exhaustion on the server, and result in authentic users being 776 denied access. It is worth noting that authentication mechanisms are 777 already designed to avoid exceeding the size limit. 779 Hence, implementations of this specification MUST limit the total 780 amount of data they send and/or receive via this specification to 781 100K. Any more than this may turn RADIUS into a generic transport 782 protocol, which is undesired. It is RECOMMENDED that this limit be 783 exposed to administrators, so that it can be changed if necessary. 785 Implementations of this specification MUST limit the total number of 786 round trips used during the fragmentation process to 25. Any more 787 than this may indicate an implementation error, misconfiguration, or 788 a denial of service (DoS) attack. It is RECOMMENDED that this limit 789 be exposed to administrators, so that it can be changed if necessary. 791 For instance, let's imagine the RADIUS server wants to transport an 792 SAML assertion which is 15000 octets long, to the RADIUS client. In 793 this hypothetical scenario, we assume there are 3 intermediate 794 proxies, each one inserting a Proxy-State attribute of 20 octets. 795 Also we assume the State attributes generated by the RADIUS server 796 have a size of 6 octets. Therefore, the amount of free space in a 797 chunk for the transport of the SAML assertion attributes is: Total 798 (4096) - RADIUS header (20) - Frag-Status (7 octets) - Service-Type 799 (6 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State 800 (20) - Proxy-State (20) - Message-Authenticator (18 octets), 801 resulting in a total of 3979 octets, that is, 15 attributes of 255 802 bytes. 804 According to [RFC6929], a Long-Extended-Type provides a payload of 805 251 octets. Therefore, the SAML assertion described above would 806 result into 60 attributes, requiring of 4 round-trips to be 807 completely transmitted. 809 7. Handling special attributes 811 7.1. Proxy-State attribute 813 RADIUS proxies may introduce Proxy-State attributes into any Access- 814 Request packet they forward. Should they cannot add this information 815 to the packet, they may silently discard forwarding it to its 816 destination, leading to DoS situations. Moreover, any Proxy-State 817 attribute received by a RADIUS server in an Access-Request packet 818 MUST be copied into the reply packet to it. For these reasons, 819 Proxy-State attributes require a special treatment within the packet 820 fragmentation mechanism. 822 When the RADIUS server replies to an Access-Request packet as part of 823 a conversation involving a fragmentation (either a chunk or a request 824 for chunks), it MUST include every Proxy-State attribute received 825 into the reply packet. This means that the server MUST take into 826 account the size of these Proxy-State attributes in order to 827 calculate the size of the next chunk to be sent. 829 However, while a RADIUS server will always know how much space MUST 830 be left on each reply packet for Proxy-State attributes (as they are 831 directly included by the RADIUS server), a RADIUS client cannot know 832 this information, as Proxy-State attributes are removed from the 833 reply packet by their respective proxies before forwarding them back. 834 Hence, clients need a mechanism to discover the amount of space 835 required by proxies to introduce their Proxy-State attributes. In 836 the following we describe a new mechanism to perform such a 837 discovery: 839 1. When a RADIUS client does not know how much space will be 840 required by intermediate proxies for including their Proxy-State 841 attributes, it SHOULD start using a conservative value (e.g. 1024 842 octets) as the chunk size. 844 2. When the RADIUS server receives a chunk from the client, it can 845 calculate the total size of the Proxy-State attributes that have 846 been introduced by intermediary proxies along the path. This 847 information MUST be returned to the client in the next reply 848 packet, encoded into a new attribute called Proxy-State-Len. The 849 server MAY artificially increase this quantity in order to handle 850 with situations where proxies behave inconsistently (e.g. they 851 generate Proxy-State attributes with a different size for each 852 packet), or for situations where intermediary proxies remove 853 Proxy-State attributes generated by other proxies. Increasing 854 this value would make the client to leave some free space for 855 these situations. 857 3. The RADIUS client SHOULD react upon the reception of this 858 attribute by adjusting the maximum size for the next chunk 859 accordingly. However, as the Proxy-State-Len offers just an 860 estimation of the space required by the proxies, the client MAY 861 select a smaller amount in environments known to be problematic. 863 7.2. State attribute 865 This RADIUS fragmentation mechanism makes use of the State attribute 866 to link all the chunks belonging to the same fragmented packet. 867 However, some considerations are required when the RADIUS server is 868 fragmenting a packet that already contains a State attribute for 869 other purposes not related with the fragmentation. If the procedure 870 described in Section 4 is followed, two different State attributes 871 could be included into a single chunk, incurring into two problems. 872 First, [RFC2865] explicitly forbids that more than one State 873 attribute appears into a single packet. 875 A straightforward solution consists on making the RADIUS server to 876 send the original State attribute into the last chunk of the sequence 877 (attributes can be re-ordered as specified in [RFC2865]). As the 878 last chunk (when generated by the RADIUS server) does not contain any 879 State attribute due to the fragmentation mechanism, both situations 880 described above are avoided. 882 Something similar happens when the RADIUS client has to send a 883 fragmented packet that contains a State attribute on it. The client 884 MUST assure that this original State is included into the first chunk 885 sent to the server (as this one never contains any State attribute 886 due to fragmentation). 888 7.3. Service-Type attribute 890 This RADIUS fragmentation mechanism makes use of the Service-Type 891 attribute to indicate an Access-Accept packet is not granting access 892 to the service yet, since additional authorization exchange needs to 893 be performed. Similarly to the State attribute, the RADIUS server 894 has to send the original Service-Type attribute into the last Access- 895 Accept of the RADIUS conversation to avoid ambiguity. 897 7.4. Rebuilding the original large packet 899 The RADIUS client stores the RADIUS attributes received on each chunk 900 in order to be able to rebuild the original large packet after 901 receiving the last chunk. However, some of these received attributes 902 MUST NOT be stored in this list, as they have been introduced as part 903 of the fragmentation signalling and hence, they are not part of the 904 original packet. 906 o State (except the one in the last chunk, if present) 908 o Service-Type = Additional-Authorization 910 o Frag-Status 912 o Proxy-State-Len 914 Similarly, the RADIUS server MUST NOT store the following attributes 915 as part of the original large packet: 917 o State (except the one in the first chunk, if present) 919 o Service-Type = Additional-Authorization 921 o Frag-Status 923 o Proxy-State (except the ones in the last chunk) 925 o User-Name (except the one in the first chunk) 927 8. New flag T field for the Long Extended Type attribute definition 929 This document defines a new field in the "Long Extended Type" 930 attribute format. This field is one bit in size, and is called "T" 931 for Truncation. It indicates that the attribute is intentionally 932 truncated in this chunk, and is to be continued in the next chunk of 933 the sequence. The combination of the flags "M" and "T" indicates 934 that the attribute is fragmented (flag M), but that all the fragments 935 are not available in this chunk (flag T). Proxies implementing 936 [RFC6929] will see these attributes as invalid (they will not be able 937 to reconstruct them), but they will still forward them as [RFC6929] 938 section 5.2 indicates they SHOULD forward unknown attributes anyway. 940 As a consequence of this addition, the Reserved field is now 6 bits 941 long (see Section 11.1 for some considerations). The following 942 figure represents the new attribute format. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | Extended-Type |M|T| Reserved | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Value ... 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 Figure 12: Updated Long Extended Type attribute format 954 9. New attribute definition 956 This document proposes the definition of two new extended type 957 attributes, called Frag-Status and Proxy-State-Len. The format of 958 these attributes follows the indications for an Extended Type 959 attribute defined in [RFC6929]. 961 9.1. Frag-Status attribute 963 This attribute is used for fragmentation signalling, and its meaning 964 depends on the code value transported within it. The following 965 figure represents the format of the Frag-Status attribute. 967 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Type | Length | Extended-Type | Code 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Code (cont) | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Figure 13: Frag-Status format 977 Type 979 To be assigned (TBA) 981 Length 982 7 984 Extended-Type 986 To be assigned (TBA). 988 Code 990 4 byte. Integer indicating the code. The values defined in this 991 specifications are: 993 0 - Reserved 995 1 - Fragmentation-Supported 997 2 - More-Data-Pending 999 3 - More-Data-Request 1001 This attribute MAY be present in Access-Request, Access-Challenge and 1002 Access-Accept packets. It MUST NOT be included in Access-Reject 1003 packets. Clients supporting this specification MUST include a Frag- 1004 Status = Fragmentation-Supported attribute in the first Access- 1005 Request sent to the server, in order to indicate they would accept 1006 fragmented data from the sever. 1008 9.2. Proxy-State-Len attribute 1010 This attribute indicates to the RADIUS client the length of the 1011 Proxy-State attributes received by the RADIUS server. This 1012 information is useful to adjust the length of the chunks sent by the 1013 RADIUS client. The format of this Proxy-State-Len attribute is the 1014 following: 1016 1 2 3 1017 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 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Type | Length | Extended-Type | Value 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Value (cont) | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 Figure 14: Proxy-State-Len format 1026 Type 1028 To be assigned (TBA) 1030 Length 1032 7 1034 Extended-Type 1036 To be assigned (TBA). 1038 Value 1040 4 octets. Total length (in octets) of received Proxy-State 1041 attributes (including headers). 1043 This attribute MAY be present in Access-Challenge and Access-Accept 1044 packets. It MUST NOT be included in Access-Request or Access-Reject 1045 packets. 1047 9.3. Table of attributes 1049 The following table shows the different attributes defined in this 1050 document related with the kind of RADIUS packets where they can be 1051 present. 1053 | Kind of packet | 1054 +-----+-----+-----+-----+ 1055 Attribute Name | Req | Acc | Rej | Cha | 1056 ----------------------+-----+-----+-----+-----+ 1057 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 1058 ----------------------+-----+-----+-----+-----+ 1059 Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | 1060 ----------------------+-----+-----+-----+-----+ 1062 Figure 15 1064 10. Operation with proxies 1066 The fragmentation mechanism defined above is designed to be 1067 transparent to legacy proxies, as long as they do not want to modify 1068 any fragmented attribute. Nevertheless, updated proxies supporting 1069 this specification can even modify fragmented attributes. 1071 10.1. Legacy proxies 1073 As every chunk is indeed a RADIUS packet, legacy proxies treat them 1074 as the rest of packets, routing them to their destination. Proxies 1075 can introduce Proxy-State attributes to Access-Request packets, even 1076 if they are indeed chunks. This will not affect how fragmentation is 1077 managed. The server will include all the received Proxy-State 1078 attributes into the generated response, as described in [RFC2865]. 1079 Hence, proxies do not distinguish between a regular RADIUS packet and 1080 a chunk. 1082 10.2. Updated proxies 1084 Updated proxies can interact with clients and servers in order to 1085 obtain the complete large packet before starting forwarding it. In 1086 this way, proxies can manipulate (modify and/or remove) any attribute 1087 of the packet, or introduce new attributes, without worrying about 1088 crossing the boundaries of the chunk size. Once the manipulated 1089 packet is ready, it is sent to the original destination using the 1090 fragmentation mechanism (if required). The following example shows 1091 how an updated proxy interacts with the NAS to obtain a large Access- 1092 Request packet, modify an attribute resulting into a even more large 1093 packet, and interacts with the AS to complete the transmission of the 1094 modified packet. 1096 +-+-+-+-+ +-+-+-+-+ 1097 | NAS | | Proxy | 1098 +-+-+-+-+ +-+-+-+-+ 1099 | | 1100 | Access-Request(1){User-Name,Calling-Station-Id, | 1101 | Example-Long-1[M],Example-Long-1[M], | 1102 | Example-Long-1[M],Example-Long-1[M], | 1103 | Example-Long-1[MT],Frag-Status(MDP)} | 1104 |--------------------------------------------------->| 1105 | | 1106 | Access-Challenge(1){User-Name, | 1107 | Frag-Status(MDR),State1} | 1108 |<---------------------------------------------------| 1109 | | 1110 | Access-Request(2)(User-Name,State1, | 1111 | Example-Long-1[M],Example-Long-1[M], | 1112 | Example-Long-1[M],Example-Long-1} | 1113 |--------------------------------------------------->| 1115 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 1116 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 1118 Figure 16: Updated proxy interacts with NAS 1120 +-+-+-+-+ +-+-+-+-+ 1121 | Proxy | | AS | 1122 +-+-+-+-+ +-+-+-+-+ 1123 | | 1124 | Access-Request(3){User-Name,Calling-Station-Id, | 1125 | Example-Long-1[M],Example-Long-1[M], | 1126 | Example-Long-1[M],Example-Long-1[M], | 1127 | Example-Long-1[MT],Frag-Status(MDP)} | 1128 |--------------------------------------------------->| 1129 | | 1130 | Access-Challenge(1){User-Name, | 1131 | Frag-Status(MDR),State2} | 1132 |<---------------------------------------------------| 1133 | | 1134 | Access-Request(4){User-Name,State2, | 1135 | Example-Long-1[M],Example-Long-1[M], | 1136 | Example-Long-1[M],Example-Long-1[M], | 1137 | Example-Long-1[MT],Frag-Status(MDP)} | 1138 |--------------------------------------------------->| 1139 | | 1140 | Access-Challenge(1){User-Name, | 1141 | Frag-Status(MDR),State3} | 1142 |<---------------------------------------------------| 1143 | | 1144 | Access-Request(5){User-Name,State3,Example-Long-1} | 1145 |--------------------------------------------------->| 1147 Figure 17: Updated proxy interacts with AS 1149 11. Operational considerations 1151 11.1. Flag T 1153 As described in Section 8, this document modifies the definition of 1154 the "Reserved" field of the "Long Extended Type" attribute [RFC6929], 1155 by allocating an additional flag "T". The meaning and position of 1156 this flag is defined in this document, and nowhere else. This might 1157 generate an issue if subsequent specifications want to allocate a new 1158 flag as well, as there would be no direct way for them to know which 1159 parts of the "Reserved" field have already been defined. 1161 An immediate and reasonable solution for this issue would be 1162 declaring that this draft updates [RFC6929]. In this way, [RFC6929] 1163 would include an "Updated by" clause that will point readers to this 1164 document. However, since this draft belongs to the Experimental 1165 track and [RFC6929] belongs to the Standards track, we do not know if 1166 including that "Updates" clause would be acceptable. 1168 Another alternative would be creating an IANA registry for the 1169 "Reserved" field. However, the working group thinks that would be 1170 overkill, as not such a great number of specifications extending that 1171 field are expected. 1173 Hence, we have decided to include the "Updates" clause in the 1174 document so far. 1176 11.2. Violation of RFC2865 1178 Section 4.1 indicates that all authorization and authentication 1179 handling will be postponed until all the chunks have been received. 1180 This postponement also affects to the verification that the Access- 1181 Request packet contains some kind of authentication attribute (e.g. 1182 User-Password, CHAP-Password, State or other future attribute), as 1183 required by [RFC2865]. This checking will therefore be delayed until 1184 the original large packet has been rebuilt, as some of the chunks may 1185 not contain any of them. The authors acknowledge this is formally 1186 violating [RFC2865], but there are no known operational issues with 1187 it. Proxies are supposed to not check this, as [RFC2865] specifies 1188 that other attributes might be considered as authentication 1189 information in future extensions, and doing so would make them too 1190 restrictive. Once this document goes beyond being considered as 1191 experimental, it will state it updates [RFC2865]. 1193 11.3. Proxying based on User-Name 1195 This proposal assumes legacy proxies to base their routing decisions 1196 on the value of the User-Name attribute. For this reason, every 1197 packet sent from the client to the server (either chunks or requests 1198 for more chunks) MUST contain a User-Name attribute. 1200 12. Security Considerations 1202 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1203 RADIUS security is problematic. This specification changes nothing 1204 related to the security of the RADIUS protocol. It requires that all 1205 Access-Request packets associated with fragmentation are 1206 authenticated using the existing Message-Authenticator attribute. 1207 This signature prevents forging and replay, to the limits of the 1208 existing security. 1210 The ability to send bulk data from one party to another creates new 1211 security considerations. Clients and servers may have to store large 1212 amounts of data per session. The amount of this data can be 1213 significant, leading to the potential for resource exhaustion. We 1214 therefore suggest that implementations limit the amount of bulk data 1215 stored per session. The exact method for this limitation is 1216 implementation-specific. Section 6 gives some indications on what 1217 could be reasonable limits. 1219 The bulk data can often be pushed off to storage methods other than 1220 the memory of the RADIUS implementation. For example, it can be 1221 stored in an external database, or in files. This approach mitigates 1222 the resource exhaustion issue, as servers today already store large 1223 amounts of accounting data. 1225 13. IANA Considerations 1227 The authors request that Attribute Types and Attribute Values defined 1228 in this document be registered by the Internet Assigned Numbers 1229 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1230 Considerations" section of [RFC3575], in accordance with BCP 26 1231 [RFC5226]. For RADIUS packets, attributes and registries created by 1232 this document IANA is requested to place them at 1233 http://www.iana.org/assignments/radius-types. 1235 This document defines the following RADIUS messages: 1237 o Frag-Status 1239 o Proxy-State-Len 1241 Additionally, allocation of a new Service-Type value for "Additional- 1242 Authorization" is requested. 1244 14. Acknowledgements 1246 The authors would like to thank the members of the RADEXT working 1247 group who have contributed to the development of this specification, 1248 either by participating on the discussions on the mailing lists or by 1249 sending comments about our draft. 1251 The authors also thank David Cuenca (University of Murcia) for 1252 implementing a proof of concept implementation of this draft that has 1253 been useful to improve the quality of the specification. 1255 This work has been partly funded by the GEANT GN3+ SA5 and CLASSe 1256 (http://sec.cs.kent.ac.uk/CLASSe/) projects. 1258 15. References 1259 15.1. Normative References 1261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1262 Requirement Levels", BCP 14, RFC 2119, March 1997. 1264 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1265 "Remote Authentication Dial In User Service (RADIUS)", 1266 RFC 2865, June 2000. 1268 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1269 Authentication Dial In User Service)", RFC 3575, 1270 July 2003. 1272 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1273 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1274 May 2008. 1276 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1277 BCP 158, RFC 6158, March 2011. 1279 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1280 Service (RADIUS) Protocol Extensions", RFC 6929, 1281 April 2013. 1283 15.2. Informative References 1285 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1287 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1288 Dial In User Service) Support For Extensible 1289 Authentication Protocol (EAP)", RFC 3579, September 2003. 1291 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1292 Rule Attribute", RFC 4849, April 2007. 1294 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1295 Dial In User Service (RADIUS) Implementation Issues and 1296 Suggested Fixes", RFC 5080, December 2007. 1298 Authors' Addresses 1300 Alejandro Perez-Mendez (Ed.) 1301 University of Murcia 1302 Campus de Espinardo S/N, Faculty of Computer Science 1303 Murcia, 30100 1304 Spain 1306 Phone: +34 868 88 46 44 1307 Email: alex@um.es 1309 Rafa Marin-Lopez 1310 University of Murcia 1311 Campus de Espinardo S/N, Faculty of Computer Science 1312 Murcia, 30100 1313 Spain 1315 Phone: +34 868 88 85 01 1316 Email: rafa@um.es 1318 Fernando Pereniguez-Garcia 1319 University of Murcia 1320 Campus de Espinardo S/N, Faculty of Computer Science 1321 Murcia, 30100 1322 Spain 1324 Phone: +34 868 88 78 82 1325 Email: pereniguez@um.es 1327 Gabriel Lopez-Millan 1328 University of Murcia 1329 Campus de Espinardo S/N, Faculty of Computer Science 1330 Murcia, 30100 1331 Spain 1333 Phone: +34 868 88 85 04 1334 Email: gabilm@um.es 1335 Diego R. Lopez 1336 Telefonica I+D 1337 Don Ramon de la Cruz, 84 1338 Madrid, 28006 1339 Spain 1341 Phone: +34 913 129 041 1342 Email: diego@tid.es 1344 Alan DeKok 1345 Network RADIUS 1346 15 av du Granier 1347 Meylan, 38240 1348 France 1350 Phone: +34 913 129 041 1351 Email: aland@networkradius.com 1352 URI: http://networkradius.com