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