idnits 2.17.1 draft-perez-radext-radius-fragmentation-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This attribute MAY be present in Access-Request, Access-Challenge and Access-Accept packets. It MUST not be included in Access-Reject packets. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This attribute MAY be present in Access-Challenge and Access-Accept packets. It MUST not be included in Access-Request or Access-Reject packets. -- The document date (July 2, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1005, but not defined == Missing Reference: 'MT' is mentioned on line 1006, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS EXTensions Working Group A. Perez-Mendez 3 Internet-Draft R. Marin-Lopez 4 Intended status: Experimental F. Pereniguez-Garcia 5 Expires: January 3, 2014 G. Lopez-Millan 6 University of Murcia 7 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 July 2, 2013 13 Support of fragmentation of RADIUS packets 14 draft-perez-radext-radius-fragmentation-06 16 Abstract 18 The Remote Authentication Dial-In User Service (RADIUS) protocol is 19 limited to a total packet size of 4096 octets. Provisions exist for 20 fragmenting large amounts of authentication data across multiple 21 packets, via Access-Challenge. No similar provisions exist for 22 fragmenting large amounts of authorization data. This document 23 specifies how existing RADIUS mechanisms can be leveraged to provide 24 that functionality. These mechanisms are largely compatible with 25 existing implementations, and are designed to be invisible to 26 proxies, and "fail-safe" to legacy clients and servers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 3, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 7 67 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12 69 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 15 71 7. Handling special attributes . . . . . . . . . . . . . . . . . 16 72 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 16 73 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 17 74 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 17 75 7.4. Rebuilding the original large packet . . . . . . . . . . . 17 76 8. New attribute definition . . . . . . . . . . . . . . . . . . . 18 77 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 18 78 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 19 79 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 20 80 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 20 81 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 20 82 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 21 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 90 1. Introduction 92 The RADIUS [RFC2865] protocol carries authentication, authorization, 93 and accounting information between a Network Access Server (NAS) and 94 an Authentication Server (AS). Information is exchanged between the 95 NAS and the AS through RADIUS packets. Each RADIUS packet is 96 composed of a header, and zero or more attributes, up to a maximum 97 packet size of 4096 octets. The protocol is a request/response 98 protocol, as described in the operational model ( [RFC6158], Section 99 3.1). 101 The above packet size limitation mean that peers desiring to send 102 large amounts of data must fragment it across multiple packets. For 103 example, RADIUS-EAP [RFC3579] defines how an EAP exchange occurs 104 across multiple Access-Request / Access-Challenge sequences. No such 105 exchange is possible for accounting or authorization data. [RFC6158] 106 Section 3.1 suggests that exchanging large amounts authorization data 107 is unnecessary in RADIUS. Instead, the data should be referenced by 108 name. This requirement allows large policies to be pre-provisioned, 109 and then referenced in an Access-Accept. In some cases, however, the 110 authorization data sent by the server is large and highly dynamic. 111 In other cases, the NAS needs to send large amounts of authorization 112 data to the server. Both of these cases are un-met by the 113 requirements in [RFC6158]. As noted in that document, the practical 114 limit on RADIUS packet sizes is governed by the Path MTU (PMTU), 115 which may be significantly smaller than 4096 octets. The combination 116 of the two limitations means that there is a pressing need for a 117 method to send large amounts of authorization data between NAS and 118 AS, with no accompanying solution. 120 [RFC6158] recommends three approaches for the transmission of large 121 amount of data within RADIUS. However, they are not applicable to 122 the problem statement of this document for the following reasons: 124 o The first approach does not talk about large amounts of data sent 125 from the NAS to a server. Leveraging EAP (request/challenge) to 126 send the data is not feasible, as EAP already fills packet to 127 PMTU, and not all authentications use EAP. Moreover, as noted for 128 NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the 129 problem of sending large amounts of data from a server to a NAS. 131 o The second approach is not usable either, as using names rather 132 than values is difficult when the nature of the data to be sent is 133 highly dynamic (e.g. SAML sentences or NAS-Filter-Rule 134 attributes). URLs could be used as a pointer to the location of 135 the actual data, but their use would require them to be (a) 136 dynamically created and modified, (b) securely accessed and (c) 137 accessible from remote systems. Satisfying these constraints 138 would require the modification of several networking systems (e.g. 139 firewalls and web servers). Furthermore, the set up of an 140 additional trust infrastructure (e.g. PKI) would be required to 141 allow secure retrieving of the information from the web server. 143 o PMTU discovery does not solve the problem, as it does not allow to 144 send data larger than the minimum of (PMTU or 4096) octets. 146 This document provides a mechanism to allow RADIUS peers to exchange 147 large amounts of authorization data exceeding the 4096 octet limit, 148 by fragmenting it across several client/server exchanges. The 149 proposed solution does not impose any additional requirements to the 150 RADIUS system administrators (e.g. need to modify firewall rules, set 151 up web servers, configure routers, or modify any application server). 152 It maintains compatibility with intra-packet fragmentation mechanisms 153 (like those defined in [RFC3579] or in 154 [I-D.ietf-radext-radius-extensions]). It is also transparent to 155 existing RADIUS proxies, which do not implement this specification. 156 The only systems needing to implement the draft are the ones which 157 either generate, or consume the fragmented data being transmitted. 158 Intermediate proxies just pass the packets without changes. 159 Nevertheless, if a proxy supports this specification, it MAY re- 160 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]. 168 2. Scope of this document 170 This specification describes how a RADIUS client and a RADIUS server 171 can exchange large amounts of data exceeding the 4096 octet limit. 172 Specifically, its scope is limited to the exchange of authorization 173 data, as other exchanges do not require of such a mechanism. In 174 particular, authentication exchanges have already been defined to 175 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 176 represent the most critical part of a RADIUS conversation, its 177 preferable to not introduce any modification to their operation that 178 may affect existing equipment. 180 There is no need to fragment accounting packets either. While the 181 accounting process can send large amounts of data, that data is 182 typically composed of many small updates. That is, there is no 183 demonstrated need to send indivisible blocks of more than 4K of data. 184 The need to send large amounts of data per user session often 185 originates from the need for flow-based accounting. In this use- 186 case, the client may send accounting data for many thousands of 187 flows, where all those flows are tied to one user session. The 188 existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 189 5.11 has been proven to work here. 191 Similarly, there is no need to fragment CoA packets. Instead, the 192 CoA client MUST send a CoA-Request packet containing session 193 identification attributes, along with Service-Type = Additional- 194 Authorization, and a State attribute. Implementations not supporting 195 fragmentation will respond with a CoA-NAK, and an Error-Cause of 196 Unsupported-Service. 198 Implementations supporting this specification may not be able to 199 change authorization data for a particular session. In that case, 200 they MUST respond with a CoA-NAK, as above. Otherwise, the 201 implementation MUST start fragmentation via Access-Request, using the 202 methods defined here. 204 The above requirement solves a number of issues. It clearly 205 separates session identification from authorization. Without this 206 separation, it is difficult to both identify a session, and change 207 its authorization using the same attribute. It also ensures that the 208 authorization process is the same for initial authentication, and for 209 CoA. 211 When a sessions authorization is changed, the CoA server MUST 212 continue the existing service until the new authorization parameters 213 are applied. The change of service SHOULD be done atomically. If 214 the CoA server is unable to apply the new authorization, it MUST 215 terminate the user session. 217 3. Overview 219 Authorization exchanges can occur either before or after end user 220 authentication has been completed. An authorization exchange before 221 authentication allows a RADIUS client to provide the RADIUS server 222 with information that MAY modify how the authentication process will 223 be performed (e.g. it MAY affect the selection of the EAP method). 224 An authorization exchange after authentication allows the RADIUS 225 server to provide the RADIUS client with information about the end 226 user, the results of the authentication process and/or obligations to 227 be enforced. In this specification we refer to the "pre- 228 authorization" as the exchange of authorization information before 229 the end user authentication has started, while the term "post- 230 authorization" is used to refer to an authorization exchange 231 happening after this authentication process. 233 In this specification we refer to the "size limit" as the practical 234 limit on RADIUS packet sizes. This limit is the minimum of 4096 235 octets, and the current PMTU. We define below a method which uses 236 Access-Request and Access-Accept in order to exchange fragmented 237 data. The NAS and server exchange a series of Access-Request / 238 Access-Accept packets, until such time as all of the fragmented data 239 has been transported. Each packet contains a Frag-Status attribute 240 which lets the other party know if fragmentation is desired, ongoing, 241 or finished. Each packet may also contain the fragmented data, or 242 instead be an "ACK" to a previous fragment from the other party. 243 Each Access-Request contains a User-Name attribute, allowing it to be 244 proxied if necessary. Each Access-Request may also contain a State 245 attribute, which serves to tie it to a previous Access-Accept. Each 246 Access-Accept contains a State attribute, for use by the NAS in a 247 later Access-Request. Each Access-Accept contains a Service-Type 248 indicating that the service being provided is fragmentation, and that 249 the Access-Accept should not be interpreted as providing network 250 access to the end user. 252 When a RADIUS client or server need to send data that exceeds the 253 size limit, the mechanism proposed in this document is used. Instead 254 of encoding one large RADIUS packet, a series of smaller RADIUS 255 packets of the same type are encoded. Each smaller packet is called 256 a "chunk" in this specification, in order to distinguish it from 257 traditional RADIUS packets. The encoding process is a simple linear 258 walk over the attributes to be encoded. This walk preserves the 259 order of the attributes, as required by [RFC2865]. The number of 260 attributes encoded in a particular chunk depends on the size limit, 261 the size of each attribute, the number of proxies between client and 262 server, and the overhead for fragmentation signalling attributes. 263 Specific details are given in Section 5. A a new attribute called 264 Frag-Status (Section 8.1) signals the fragmentation status. 266 After the first chunk is encoded, it is sent to the other party. The 267 packet is identified as a chunk via the Frag-Status attribute. The 268 other party then requests additional chunks, again using the Frag- 269 Status attribute. This process is repeated until all the attributes 270 have been sent from one party to the other. When all the chunks have 271 been received, the original list of attributes is reconstructed and 272 processed as if it had been received in one packet. 274 When multiple chunks are sent, a special situation may occur for 275 Extended Type attributes as defined in 276 [I-D.ietf-radext-radius-extensions]. The fragmentation process may 277 split a fragmented attribute across two or more chunks, which is not 278 permitted by that specification. We address this issue by defining a 279 new field in the Reserved field of the "Long Extended Type" attribute 280 format. This field is one bit in size, and is called "T" for 281 Truncation. It indicates that the attribute is intentionally 282 truncated in this chunk, and is to be continued in the next chunk of 283 the sequence. The combination of the flags "M" and "T" indicates 284 that the attribute is fragmented (flag M), but that all the fragments 285 are not available in this chunk (flag T). 287 This last situation is expected to be the most common occurrence in 288 chunks. Typically, packet fragmentation will occur as a consequence 289 of a desire to send one or more large (and therefore fragmented) 290 attributes. The large attribute will likely be split into two or 291 more pieces. Where chunking does not split a fragmented attribute, 292 no special treatment is necessary. 294 The setting of the "T" flag is the only case where the chunking 295 process affects the content of an attribute. Even then, the "Value" 296 fields of all attributes remain unchanged. Any per-packet security 297 attributes such as Message-Authenticator are calculated for each 298 chunk independently. There are neither integrity nor security checks 299 performed on the "original" packet. 301 Each RADIUS packet sent or received as part of the chunking process 302 MUST be a valid packet, subject to all format and security 303 requirements. This requirement ensures that a "transparent" proxy 304 not implementing this specification can receive and send compliant 305 packets. That is, a proxy which simply forwards packets without 306 detailed examination or any modification will be able to proxy 307 "chunks". 309 4. Fragmentation of packets 311 When the NAS or the AS desires to send a packet that exceeds the size 312 limit, it is split into chunks and sent via multiple client/server 313 exchanges. The exchange is indicated via the Frag-Status attribute, 314 which has value More-Data-Pending for all but the last chunk of the 315 series. The chunks are tied together via the State attribute. 317 The following sections describe how to perform fragmentation for 318 packets from the NAS to the server, followed by packets from the 319 server to the NAS. We give the packet type, along with a RADIUS 320 Identifier, to indicate that requests and responses are connected. 321 We then give a list of attributes. We do not give values for most 322 attributes, as we wish to concentrate on the fragmentation behaviour, 323 rather than packet contents. Attribute values are given for 324 attributes relevant to the fragmentation process. Where "long 325 extended" attributes are used, we indicate the M (More) and T 326 (Truncation) flags as optional square brackets after the attribute 327 name. As no "long extended" attributes have yet been defined, we use 328 example attributes, named as "Example-Long-1", etc. The maximum 329 chunk size is established in term of number of attributes (11), for 330 sake of simplicity. 332 4.1. Pre-authorization 334 When the client needs to send a large amount of data to the server, 335 the data to be sent is split into chunks and sent to the server via 336 multiple Access-Request / Access-Accept exchanges. The example below 337 shows this exchange. 339 The following is an Access-Request which the NAS intends to send to a 340 server. However, due to a combination of issues (PMTU, large 341 attributes, etc.), the content does not fit into one Access-Request 342 packet. 344 Access-Request 345 User-Name 346 User-Password 347 Calling-Station-Id 348 Example-Long-1 [M] 349 Example-Long-1 [M] 350 Example-Long-1 [M] 351 Example-Long-1 [M] 352 Example-Long-1 [M] 353 Example-Long-1 [M] 354 Example-Long-1 [M] 355 Example-Long-1 [M] 356 Example-Long-1 357 Example-Long-2 [M] 358 Example-Long-2 [M] 359 Example-Long-2 361 Figure 1: Desired Access-Request 363 The NAS therefore must send the attributes listed above in a series 364 of chunks. The first chunk contains eight (8) attributes from the 365 original Access-Request, and a Frag-Status attribute. Since last 366 attribute is "Example-Long-1" with the "M" flag set, the chunking 367 process also sets the "T" flag in that attribute. The Access-Request 368 is sent with a RADIUS Identifier field having value 23. The Frag- 369 Status attribute has value More-Data-Pending, to indicate that the 370 NAS wishes to send more data in a subsequent Access-Request. The NAS 371 also adds a Service-Type attribute, which indicates that it is part 372 of the chunking process. The packet is signed with the Message- 373 Authenticator attribute, completing the maximum number of attributes 374 (11). 376 Access-Request (ID = 23) 377 User-Name 378 User-Password 379 Calling-Station-Id 380 Example-Long-1 [M] 381 Example-Long-1 [M] 382 Example-Long-1 [M] 383 Example-Long-1 [M] 384 Example-Long-1 [MT] 385 Frag-Status = More-Data-Pending 386 Service-Type = Additional-Authorization 387 Message-Authenticator 389 Figure 2: Access-Request (chunk 1) 391 Compliant servers receiving this packet will see the Frag-Status 392 attribute, wand suspend all authorization and authentication handling 393 until all of the chunks have been received. Non-compliant servers 394 should also see the Service-Type requesting provisioning for an 395 unknown service, and return Access-Reject. Other non-compliant 396 servers may return an Access-Reject, Access-Challenge, or an Access- 397 Accept with a particular Service-Type. Compliant NAS implementations 398 MUST treat these responses as if they had received Access-Reject 399 instead. 401 Compliant servers who wish to receive all of the chunks will respond 402 with the following packet. The value of the State here is arbitrary, 403 and serves only as a unique token for example purposes. We only note 404 that it MUST be globally and temporally unique. 406 Access-Accept (ID = 23) 407 Frag-Status = More-Data-Request 408 Service-Type = Additional-Authorization 409 State = 0xabc00001 410 Message-Authenticator 412 Figure 3: Access-Accept (chunk 1) 414 The NAS will see this response, and use the RADIUS Identifier field 415 to associate it with an ongoing chunking session. Compliant NASes 416 will then continue the chunking process. Non-compliant NASes will 417 never see a response such as this, as they will never send a Frag- 418 Status attribute. The Service-Type attribute is included in the 419 Access-Accept in order to signal that the response is part of the 420 chunking process. This packet therefore does not provision any 421 network service for the end user. 423 The NAS continues the process by sending the next chunk, which 424 includes an additional six (6) attributes from the original packet. 425 It again includes the User-Name attribute, so that non-compliant 426 proxies can process the packet. It sets the Frag-Status attribute to 427 More-Data-Pending, as more data is pending. It includes a Service- 428 Type for reasons described above. It includes the State attribute 429 from the previous Access-accept. It signs the packet with Message- 430 Authenticator, as there are no authentication attributes in the 431 packet. It uses a new RADIUS Identifier field. 433 Access-Request (ID = 181) 434 User-Name 435 Example-Long-1 [M] 436 Example-Long-1 [M] 437 Example-Long-1 [M] 438 Example-Long-1 439 Example-Long-2 [M] 440 Example-Long-2 [MT] 441 Frag-Status = More-Data-Request 442 Service-Type = Additional-Authorization 443 State = 0xabc000001 444 Message-Authenticator 446 Figure 4: Access-Request (chunk 2) 448 Compliant servers receiving this packet will see the Frag-Status 449 attribute, and look for a State attribute. Since one exists and it 450 matches a State sent in an Access-Accept, this packet is part of a 451 chunking process. The server will associate the attributes with the 452 previous chunk. Since the Frag-Status attribute has value More-Data- 453 Request, the server will respond with an Access-Accept as before. It 454 MUST include a State attribute, with a value different from the 455 previous Access-Accept. This State MUST again be globally and 456 temporally unique. 458 Access-Accept (ID = 181) 459 Frag-Status = More-Data-Request 460 Service-Type = Additional-Authorization 461 State = 0xdef00002 462 Message-Authenticator 464 Figure 5: Access-Accept (chunk 2) 466 The NAS will see this response, and use the RADIUS Identifier field 467 to associate it with an ongoing chunking session. The NAS continues 468 the chunking process by sending the next chunk, with the final 469 attribute(s) from the original packet, and again includes the 470 original User-Name attribute. The Frag-Status attribute is not 471 included in the next Access-Request, as no more chunks are available 472 for sending. The NAS includes the State attribute from the previous 473 Access-accept. It signs the packet with Message-Authenticator, as 474 there are no authentication attributes in the packet. It again uses 475 a new RADIUS Identifier field. 477 Access-Request (ID = 241) 478 User-Name 479 Example-Long-2 480 State = 0xdef00002 481 Message-Authenticator 483 Figure 6: Access-Request (chunk 3) 485 On reception of this last chunk, the server matches it with an 486 ongoing session via the State attribute, and sees that there is no 487 Frag-Status attribute present. It then process the received 488 attributes as if they had been sent in one RADIUS packet. See 489 Section 7.4 for further details of this process. It generates the 490 appropriate response, which can be either Access-Accept or Access- 491 Reject. In this example, we show an Access-Accept. The server MUST 492 send a State attribute, which permits link the received data with the 493 authentication process. 495 Access-Accept (ID = 241) 496 State = 0x98700003 497 Message-Authenticator 499 Figure 7: Access-Accept (chunk 3) 501 The above example shows in practice how the chunking process works. 502 We re-iterate the implementation and security requirements here. 504 Each chunk is a valid RADIUS packet, and all RADIUS format and 505 security requirements MUST be followed before any chunking process is 506 applied. 508 Every chunk except for the last one from a NAS MUST include a Frag- 509 Status attribute, with value More-Data-Pending. The last chunk MUST 510 NOT contain a Frag-Status attribute. Each chunk except for the last 511 from a NAS MUST include a Service-Type attribute, with value 512 Additional-Authorization. Each chunk MUST include a User-Name 513 attribute, which MUST be identical in all chunks. Each chunk except 514 for the first one from a NAS MUST include a State attribute, which 515 MUST be copied from a previous Access-Accept. 517 Each Access-Accept MUST include a State attribute. The value for 518 this attribute MUST change in every new Access-Accept, and MUST be 519 globally and temporally unique. 521 4.2. Post-authorization 523 When the AS wants to send a large amount of authorization data to the 524 NAS after authentication, the operation is very similar to the pre- 525 authorization one. The presence of Service-Type = Additional- 526 Authorization attribute ensures that a NAS not supporting this 527 specification will treat that unrecognized Service-Type as though an 528 Access-Reject had been received instead ([RFC2865] Section 5.6). If 529 the original large Access-Accept packet contained a Service-Type 530 attribute, it will be included with its original value in the last 531 transmitted chunk, to avoid confusion with the one used for 532 fragmentation signalling. 534 Client supporting this specification MUST include a Frag-Status = 535 Fragmentation-Supported attribute in the first Access-Request sent to 536 the server, in order to indicate they would accept fragmented data 537 from the sever. This is not required if pre-authorization process 538 was carried out, as it is implicit. 540 The following is an Access-Accept which the AS intends to send to a 541 client. However, due to a combination of issues (PMTU, large 542 attributes, etc.), the content does not fit into one Access-Accept 543 packet. 545 Access-Accept 546 User-Name 547 EAP-Message 548 Service-Type(Login) 549 Example-Long-1 [M] 550 Example-Long-1 [M] 551 Example-Long-1 [M] 552 Example-Long-1 [M] 553 Example-Long-1 [M] 554 Example-Long-1 [M] 555 Example-Long-1 [M] 556 Example-Long-1 [M] 557 Example-Long-1 558 Example-Long-2 [M] 559 Example-Long-2 [M] 560 Example-Long-2 562 Figure 8: Desired Access-Accept 564 The AS therefore must send the attributes listed above in a series of 565 chunks. The first chunk contains eight (7) attributes from the 566 original Access-Accept, and a Frag-Status attribute. Since last 567 attribute is "Example-Long-1" with the "M" flag set, the chunking 568 process also sets the "T" flag in that attribute. The Access-Accept 569 is sent with a RADIUS Identifier field having value 30 corresponding 570 to a previous Access-Request not depicted. The Frag-Status attribute 571 has value More-Data-Pending, to indicate that the AS wishes to send 572 more data in a subsequent Access-Accept. The AS also adds a Service- 573 Type attribute with value Additional-Authorization, which indicates 574 that it is part of the chunking process. Note that the original 575 Service-Type is not included in this chunk. Finally, a State 576 attribute is included to allow matching subsequent requests with this 577 conversation, and the packet is signed with the Message-Authenticator 578 attribute, completing the maximum number of attributes of 11. 580 Access-Accept (ID = 30) 581 User-Name 582 EAP-Message 583 Example-Long-1 [M] 584 Example-Long-1 [M] 585 Example-Long-1 [M] 586 Example-Long-1 [M] 587 Example-Long-1 [MT] 588 Frag-Status = More-Data-Pending 589 Service-Type = Additional-Authorization 590 State = 0xcba00004 591 Message-Authenticator 593 Figure 9: Access-Accept (chunk 1) 595 Compliant clients receiving this packet will see the Frag-Status 596 attribute, wand suspend all authorization and authentication handling 597 until all of the chunks have been received. Non-compliant clients 598 should also see the Service-Type indicating the provisioning for an 599 unknown service, and will treat it as an Access-Reject. 601 Clients who wish to receive all of the chunks will respond with the 602 following packet, where the value of the State attribute is taken 603 from the received Access-Accept. They also include the User-Name 604 attribute so that non-compliant proxies can process the packet. 606 Access-Request (ID = 131) 607 User-Name 608 Frag-Status = More-Data-Request 609 Service-Type = Additional-Authorization 610 State = 0xcba00004 611 Message-Authenticator 613 Figure 10: Access-Request (chunk 1) 615 The AS receives this request, and uses the State attribute to 616 associate it with an ongoing chunking session. Compliant ASes will 617 then continue the chunking process. Non-compliant ASes will never 618 see a response such as this, as they will never send a Frag-Status 619 attribute. 621 The AS continues the chunking process by sending the next chunk, with 622 the final attribute(s) from the original packet. The value of the 623 Identifier field is taken from the received Access-Request. A Frag- 624 Status attribute is not included in the next Access-Accept, as no 625 more chunks are available for sending. The AS includes an State 626 attribute to allow the client to send additional authorization data. 627 The original Service-Type attribute is included in this final chunk. 629 Access-Accept (ID = 131) 630 Example-Long-1 [M] 631 Example-Long-1 [M] 632 Example-Long-1 [M] 633 Example-Long-1 634 Example-Long-2 [M] 635 Example-Long-2 [M] 636 Example-Long-2 637 Service-Type = Login 638 State = 0xfda000005 639 Message-Authenticator 641 Figure 11: Access-Accept (chunk 2) 643 On reception of this last chunk, the client matches it with an 644 ongoing session via the Identifier field, and sees that there is no 645 Frag-Status attribute present. It then processes the received 646 attributes as if they had been sent in one RADIUS packet. See 647 Section 7.4 for further details of this process. 649 5. Chunk size 651 In an ideal scenario, each intermediate chunk would be exactly the 652 size limit in length. In this way, the number of round trips 653 required to send a large packet would be optimal. However, this is 654 not possible for several reasons. 656 1. RADIUS attributes have a variable length, and must be included 657 completely in a chunk. Thus, it is possible that, even if there 658 is some free space in the chunk, it is not enough to include the 659 next attribute. This can generate up to 254 octets of spare 660 space on every chunk. 662 2. RADIUS fragmentation requires the introduction of some extra 663 attributes for signalling. Specifically, a Frag-Status attribute 664 (7 octets) is included on every chunk of a packet, except the 665 last one. A RADIUS State attribute (from 3 to 255 octets) is 666 also included in most chunks, to allow the server to bind an 667 Access-Request with a previous Access-Challenge. User-Name 668 attributes (from 3 to 255 octets) are introduced on every chunk 669 the client sends as they are required by the proxies to route the 670 packet to its destination. Together, these attributes can 671 generate from up to 13 to 517 octets of signalling data, reducing 672 the amount of payload information that can be sent on each chunk. 674 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 675 MTU. Otherwise, IP fragmentation may occur, having undesirable 676 consequences. Hence, maximum chunk size would be decreased from 677 4096 to the actual MTU of the network. 679 4. The inclusion of Proxy-State attributes by intermediary proxies 680 can decrease the availability of usable space into the chunk. 681 This is described with further detail in Section 7.1. 683 6. Allowed large packet size 685 There are no provisions for signalling how much data is to be sent 686 via the fragmentation process as a whole. It is difficult to define 687 what is meant by the "length" of any fragmented data. That data can 688 be multiple attributes, which includes RADIUS attribute header 689 fields. Or it can be one or more "large" attributes (more than 256 690 octets in length). Proxies can also filter these attributes, to 691 modify, add, or delete them and their contents. These proxies act on 692 a "packet by packet" basis, and cannot know what kind of filtering 693 actions they take on future packets. As a result, it is impossible 694 to signal any meaningful value for the total amount of additional 695 data. 697 Unauthenticated clients are permitted to trigger the exchange of 698 large amounts of fragmented data between the NAS and the AS, having 699 the potential to allow Denial of Service (DoS) attacks. An attacker 700 could initiate a large number of connections, each of which requests 701 the server to store a large amount of data. This data could cause 702 memory exhaustion on the server, and result in authentic users being 703 denied access. It is worth noting that authentication mechanisms are 704 already designed to avoid exceeding the size limit. 706 Hence, implementations of this specification MUST limit the total 707 amount of data they send and/or receive via this specification. It 708 is RECOMMENDED that the limits be set to a few tens of kilooctets. 709 Any more than this may turn RADIUS into a generic transport protocol, 710 which is undesired. It is RECOMMENDED that this limit be exposed to 711 administrators, so that it can be changed if necessary. 713 Implementations of this specification MUST limit the total number of 714 round trips used during the fragmentation process. It is RECOMMENDED 715 that the number of round trips be limited to twenty (20). Any more 716 than this may indicate an implementation error, misconfiguration, or 717 a denial of service (DoS) attack. It is RECOMMENDED that this limit 718 be exposed to administrators, so that it can be changed if necessary. 720 7. Handling special attributes 722 7.1. Proxy-State attribute 724 RADIUS proxies may introduce Proxy-State attributes into any Access- 725 Request packet they forward. Should they cannot add this information 726 to the packet, they may silently discard forwarding it to its 727 destination, leading to DoS situations. Moreover, any Proxy-State 728 attribute received by a RADIUS server in an Access-Request packet 729 MUST be copied into the reply packet to it. For these reasons, 730 Proxy-State attributes require a special treatment within the packet 731 fragmentation mechanism. 733 When the RADIUS server replies to an Access-Request packet as part of 734 a conversation involving a fragmentation (either a chunk or a request 735 for chunks), it MUST include every Proxy-State attribute received 736 into the reply packet. This means that the server MUST take into 737 account the size of these Proxy-State attributes in order to 738 calculate the size of the next chunk to be sent. 740 However, while a RADIUS server will always know how many space MUST 741 be left on each reply packet for Proxy-State attributes (as they are 742 directly included by the RADIUS server), a RADIUS client cannot know 743 this information, as Proxy-State attributes are removed from the 744 reply packet by their respective proxies before forwarding them back. 745 Hence, clients need a mechanism to discover the amount of space 746 required by proxies to introduce their Proxy-State attributes. In 747 the following we describe a new mechanism to perform such a 748 discovery: 750 1. When a RADIUS client does not know how many space will be 751 required by intermediate proxies for including their Proxy-State 752 attributes, it SHOULD start using a conservative value (e.g. 1024 753 octets) as the chunk size. 755 2. When the RADIUS server receives a chunk from the client, it can 756 calculate the total size of the Proxy-State attributes that have 757 been introduced by intermediary proxies along the path. This 758 information MUST be returned to the client in the next reply 759 packet, encoded into a new attribute called Proxy-State-Len. 761 3. The RADIUS client reacts upon the reception of this attribute by 762 adjusting the maximum size for the next chunk accordingly. 764 7.2. State attribute 766 This RADIUS fragmentation mechanism makes use of the State attribute 767 to link all the chunks belonging to the same fragmented packet. 768 However, some considerations are required when the RADIUS server is 769 fragmenting a packet that already contains a State attribute for 770 other purposes not related with the fragmentation. If the procedure 771 described in Section 4 is followed, two different State attributes 772 could be included into a single chunk, incurring into two problems. 773 First, [RFC2865] explicitly forbids that more than one State 774 attribute appears into a single packet. 776 A straightforward solution consists on making the RADIUS server to 777 send the original State attribute into the last chunk of the sequence 778 (attributes can be re-ordered as specified in [RFC2865]). As the 779 last chunk (when generated by the RADIUS server) does not contain any 780 State attribute due to the fragmentation mechanism, both situations 781 described above are avoided. 783 Something similar happens when the RADIUS client has to send a 784 fragmented packet that contains a State attribute on it. The client 785 MUST assure that this original State is included into the first chunk 786 sent to the server (as this one never contains any State attribute 787 due to fragmentation). 789 7.3. Service-Type attribute 791 This RADIUS fragmentation mechanism makes use of the Service-Type 792 attribute to indicate an Access-Accept packet is not granting access 793 to the service yet, since additional authorization exchange needs to 794 be performed. Similarly to the State attribute, the RADIUS server 795 has to send the original Service-Type attribute into the last Access- 796 Accept of the RADIUS conversation to avoid ambiguity. 798 7.4. Rebuilding the original large packet 800 The RADIUS client stores the RADIUS attributes received on each chunk 801 in order to be able to rebuild the original large packet after 802 receiving the last chunk. However, some of these received attributes 803 MUST NOT be stored in this list, as they have been introduced as part 804 of the fragmentation signalling and hence, they are not part of the 805 original packet. 807 o State (except the one in the last chunk, if present) 809 o Service-Type = Additional-Authorization 811 o Frag-Status 813 o Proxy-State-Len 815 Similarly, the RADIUS server MUST NOT store the following attributes 816 as part of the original large packet: 818 o State (except the one in the first chunk, if present) 820 o Frag-Status 822 o Proxy-State (except the ones in the last chunk) 824 o User-Name (except the one in the first chunk) 826 8. New attribute definition 828 This document proposes the definition of two new extended type 829 attributes, called Frag-Status and Proxy-State-Len. The format of 830 these attributes follows the indications for an Extended Type 831 attribute defined in [I-D.ietf-radext-radius-extensions]. 833 8.1. Frag-Status attribute 835 This attribute is used for fragmentation signalling, and its meaning 836 depends on the code value transported within it. The following 837 figure represents the format of the Frag-Status attribute. 839 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Type | Length | Extended-Type | Code 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Code (cont) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Figure 12: Frag-Status format 849 Type 851 To be assigned (TBA) 853 Length 854 7 856 Extended-Type 858 To be assigned (TBA). 860 Code 862 4 byte. Integer indicating the code. The values defined in this 863 specifications are: 865 0 - Reserved 867 1 - Fragmentation-Supported 869 2 - More-Data-Pending 871 3 - More-Data-Request 873 This attribute MAY be present in Access-Request, Access-Challenge and 874 Access-Accept packets. It MUST not be included in Access-Reject 875 packets. 877 8.2. Proxy-State-Len attribute 879 This attribute indicates to the RADIUS client the length of the 880 Proxy-State attributes received by the RADIUS server. This 881 information is useful to adjust the length of the chunks sent by the 882 RADIUS client. The format of this Proxy-State-Len attribute is the 883 following: 885 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | Extended-Type | Value 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Value (cont) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Figure 13: Proxy-State-Len format 895 Type 897 To be assigned (TBA) 899 Length 900 7 902 Extended-Type 904 To be assigned (TBA). 906 Value 908 4 octets. Total length (in octets) of received Proxy-State 909 attributes (including headers). 911 This attribute MAY be present in Access-Challenge and Access-Accept 912 packets. It MUST not be included in Access-Request or Access-Reject 913 packets. 915 8.3. Table of attributes 917 The following table shows the different attributes defined in this 918 document related with the kind of RADIUS packets where they can be 919 present. 921 | Kind of packet | 922 +-----+-----+-----+-----+ 923 Attribute Name | Req | Acc | Rej | Cha | 924 ----------------------+-----+-----+-----+-----+ 925 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 926 ----------------------+-----+-----+-----+-----+ 927 Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | 928 ----------------------+-----+-----+-----+-----+ 930 Figure 14 932 9. Operation with proxies 934 The fragmentation mechanism defined above is designed to be 935 transparent to legacy proxies, as long as they do not want to modify 936 any fragmented attribute. Nevertheless, updated proxies supporting 937 this specification can even modify fragmented attributes. 939 9.1. Legacy proxies 941 As every chunk is indeed a RADIUS packet, legacy proxies treat them 942 as the rest of packets, routing them to their destination. Proxies 943 can introduce Proxy-State attributes to Access-Request packets, even 944 if they are indeed chunks. This will not affect how fragmentation is 945 managed. The server will include all the received Proxy-State 946 attributes into the generated response, as described in [RFC2865]. 948 Hence, proxies do not distinguish between a regular RADIUS packet and 949 a chunk. 951 9.2. Updated proxies 953 Updated proxies can interact with clients and servers in order to 954 obtain the complete large packet before start forwarding it. In this 955 way, proxies can manipulate (modify and/or remove) any attribute of 956 the packet, or introduce new attributes, without worrying about 957 crossing the boundaries of the chunk size. Once the manipulated 958 packet is ready, it is sent to the original destination using the 959 fragmentation mechanism (if required). The following example shows 960 how an updated proxy interacts with the NAS to obtain a large Access- 961 Request packet, modify an attribute resulting into a even more large 962 packet, and interacts with the AS to complete the transmission of the 963 modified packet. 965 +-+-+-+-+ +-+-+-+-+ 966 | NAS | | Proxy | 967 +-+-+-+-+ +-+-+-+-+ 968 | | 969 | Access-Request(1){User-Name,Calling-Station-Id, | 970 | Example-Long-1[M],Example-Long-1[M], | 971 | Example-Long-1[M],Example-Long-1[M], | 972 | Example-Long-1[MT],Frag-Status(MDP)} | 973 |--------------------------------------------------->| 974 | | 975 | Access-Challenge(1){User-Name, | 976 | Frag-Status(MDR),State1} | 977 |<---------------------------------------------------| 978 | | 979 | Access-Request(2)(User-Name,State1, | 980 | Example-Long-1[M],Example-Long-1[M], | 981 | Example-Long-1[M],Example-Long-1} | 982 |--------------------------------------------------->| 984 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 985 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 987 Figure 15: Updated proxy interacts with NAS 989 +-+-+-+-+ +-+-+-+-+ 990 | Proxy | | AS | 991 +-+-+-+-+ +-+-+-+-+ 992 | | 993 | Access-Request(3){User-Name,Calling-Station-Id, | 994 | Example-Long-1[M],Example-Long-1[M], | 995 | Example-Long-1[M],Example-Long-1[M], | 996 | Example-Long-1[MT],Frag-Status(MDP)} | 997 |--------------------------------------------------->| 998 | | 999 | Access-Challenge(1){User-Name, | 1000 | Frag-Status(MDR),State2} | 1001 |<---------------------------------------------------| 1002 | | 1003 | Access-Request(4){User-Name,State2, | 1004 | Example-Long-1[M],Example-Long-1[M], | 1005 | Example-Long-1[M],Example-Long-1[M], | 1006 | Example-Long-1[MT],Frag-Status(MDP)} | 1007 |--------------------------------------------------->| 1008 | | 1009 | Access-Challenge(1){User-Name, | 1010 | Frag-Status(MDR),State3} | 1011 |<---------------------------------------------------| 1012 | | 1013 | Access-Request(5){User-Name,State3,Example-Long-1} | 1014 |--------------------------------------------------->| 1016 Figure 16: Updated proxy interacts with AS 1018 10. Security Considerations 1020 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1021 RADIUS security is problematic. This specification changes nothing 1022 related to the security of the RADIUS protocol. It requires that all 1023 Access-Request packets associated with fragmentation are signed using 1024 the existing Message-Authenticator attribute. This signature 1025 prevents forging and replay, to the limits of the existing security. 1027 The ability to send bulk data from one party to another creates new 1028 security considerations. Clients and servers may have to store large 1029 amounts of data per session. The amount of this data can be 1030 significant, leading to the potential for resource exhaustion. We 1031 therefore suggest that implementations limit the amount of bulk data 1032 stored per session. The exact method for this limitation is 1033 implementation-specific. Section 6 gives some indications on what 1034 could be a reasonable limits. 1036 The bulk data can often be pushed off to storage methods other than 1037 the memory of the RADIUS implementation. For example, it can be 1038 stored in an external database, or in files. This approach mitigates 1039 the resource exhaustion issue, as servers today already store large 1040 amounts of accounting data. 1042 11. IANA Considerations 1044 The authors request that Attribute Types and Attribute Values defined 1045 in this document be registered by the Internet Assigned Numbers 1046 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1047 Considerations" section of [RFC3575], in accordance with BCP 26 1048 [RFC5226]. For RADIUS packets, attributes and registries created by 1049 this document IANA is requested to place them at 1050 http://www.iana.org/assignments/radius-types. 1052 This document defines the following RADIUS messages: 1054 o Frag-Status 1056 o Proxy-State-Len 1058 Additionally, allocation of a new Service-Type value for "Additional- 1059 Authorization" is requested. 1061 12. References 1063 12.1. Normative References 1065 [I-D.ietf-radext-radius-extensions] 1066 DeKok, A. and A. Lior, "Remote Authentication Dial In User 1067 Service (RADIUS) Protocol Extensions", 1068 draft-ietf-radext-radius-extensions-13 (work in progress), 1069 February 2013. 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1074 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1075 "Remote Authentication Dial In User Service (RADIUS)", 1076 RFC 2865, June 2000. 1078 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1080 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1081 Authentication Dial In User Service)", RFC 3575, 1082 July 2003. 1084 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1085 Dial In User Service) Support For Extensible 1086 Authentication Protocol (EAP)", RFC 3579, September 2003. 1088 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1089 Dial In User Service (RADIUS) Implementation Issues and 1090 Suggested Fixes", RFC 5080, December 2007. 1092 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1093 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1094 May 2008. 1096 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1097 BCP 158, RFC 6158, March 2011. 1099 12.2. Informative References 1101 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1102 Rule Attribute", RFC 4849, April 2007. 1104 Authors' Addresses 1106 Alejandro Perez-Mendez (Ed.) 1107 University of Murcia 1108 Campus de Espinardo S/N, Faculty of Computer Science 1109 Murcia, 30100 1110 Spain 1112 Phone: +34 868 88 46 44 1113 Email: alex@um.es 1115 Rafa Marin-Lopez 1116 University of Murcia 1117 Campus de Espinardo S/N, Faculty of Computer Science 1118 Murcia, 30100 1119 Spain 1121 Phone: +34 868 88 85 01 1122 Email: rafa@um.es 1123 Fernando Pereniguez-Garcia 1124 University of Murcia 1125 Campus de Espinardo S/N, Faculty of Computer Science 1126 Murcia, 30100 1127 Spain 1129 Phone: +34 868 88 78 82 1130 Email: pereniguez@um.es 1132 Gabriel Lopez-Millan 1133 University of Murcia 1134 Campus de Espinardo S/N, Faculty of Computer Science 1135 Murcia, 30100 1136 Spain 1138 Phone: +34 868 88 85 04 1139 Email: gabilm@um.es 1141 Diego R. Lopez 1142 Telefonica I+D 1143 Don Ramon de la Cruz, 84 1144 Madrid, 28006 1145 Spain 1147 Phone: +34 913 129 041 1148 Email: diego@tid.es 1150 Alan DeKok 1151 Network RADIUS 1152 15 av du Granier 1153 Meylan, 38240 1154 France 1156 Phone: +34 913 129 041 1157 Email: aland@networkradius.com 1158 URI: http://networkradius.com