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