idnits 2.17.1 draft-ietf-radext-radius-fragmentation-01.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 (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'M' is mentioned on line 1061, but not defined == Missing Reference: 'MT' is mentioned on line 1062, 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: April 24, 2014 G. Lopez-Millan 6 University of Murcia 7 D. Lopez 8 Telefonica I+D 9 A. DeKok 10 Network RADIUS 11 October 21, 2013 13 Support of fragmentation of RADIUS packets 14 draft-ietf-radext-radius-fragmentation-01 16 Abstract 18 The Remote Authentication Dial-In User Service (RADIUS) protocol is 19 limited to a total packet size of 4096 octets. Provisions exist for 20 fragmenting large amounts of authentication data across multiple 21 packets, via Access-Challenge. No similar provisions exist for 22 fragmenting large amounts of authorization data. This document 23 specifies how existing RADIUS mechanisms can be leveraged to provide 24 that functionality. These mechanisms are largely compatible with 25 existing implementations, and are designed to be invisible to 26 proxies, and "fail-safe" to legacy clients and servers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 67 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8 68 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12 69 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 16 71 7. Handling special attributes . . . . . . . . . . . . . . . . . 17 72 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17 73 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18 74 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 19 75 7.4. Rebuilding the original large packet . . . . . . . . . . . 19 76 8. New attribute definition . . . . . . . . . . . . . . . . . . . 19 77 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20 78 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21 79 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21 80 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22 81 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22 82 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 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 [RFC6929]). It is also 154 transparent to existing RADIUS proxies, which do not implement this 155 specification. The only systems needing to implement the draft are 156 the ones which either generate, or consume the fragmented data being 157 transmitted. Intermediate proxies just pass the packets without 158 changes. Nevertheless, if a proxy supports this specification, it 159 MAY re-assemble the data in order to either examine and/or modify it. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Scope of this document 169 This specification describes how a RADIUS client and a RADIUS server 170 can exchange large amounts of data exceeding the 4096 octet limit. 171 Specifically, its scope is limited to the exchange of authorization 172 data, as other exchanges do not require of such a mechanism. In 173 particular, authentication exchanges have already been defined to 174 overcome this limitation (e.g. RADIUS-EAP). Moreover, as they 175 represent the most critical part of a RADIUS conversation, its 176 preferable to not introduce any modification to their operation that 177 may affect existing equipment. 179 There is no need to fragment accounting packets either. While the 180 accounting process can send large amounts of data, that data is 181 typically composed of many small updates. That is, there is no 182 demonstrated need to send indivisible blocks of more than 4K of data. 183 The need to send large amounts of data per user session often 184 originates from the need for flow-based accounting. In this use- 185 case, the client may send accounting data for many thousands of 186 flows, where all those flows are tied to one user session. The 187 existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 188 5.11 has been proven to work here. 190 Similarly, there is no need to fragment CoA packets. Instead, the 191 CoA client MUST send a CoA-Request packet containing session 192 identification attributes, along with Service-Type = Additional- 193 Authorization, and a State attribute. Implementations not supporting 194 fragmentation will respond with a CoA-NAK, and an Error-Cause of 195 Unsupported-Service. 197 The above requirement does not assume that the CoA client and the 198 RADIUS server are co-located. They may, in fact be run on separate 199 parts of the infrastructure, or even by separate administrators. 200 There is, however, a requirement that the two communicate. We can 201 see that the CoA client needs to send session identification 202 attributes in order to send CoA packets. These attributes cannot be 203 known a priori by the CoA client, and can only come from the RADIUS 204 server. Therefore, even when the two systems are not co-located, 205 they must be able to communicate in order to operate in unison. The 206 alternative is for the two systems to have differing views of the 207 users authorization parameters, which is a security disaster. 209 This specification does not allow for fragmentation of CoA packets. 210 Allowing for fragmented CoA packets would involve changing multiple 211 parts of the RADIUS protocol, with the corresponding possibility for 212 implementation issues, mistakes, etc. 214 Where CoA clients need to send large amounts of authorization data to 215 a NAS, they need only send a minimal CoA-Request packet, containing 216 Service-Type of Authorize-Only, as per RFC 5176. They SHOULD also 217 have a co-located RADIUS server, for the sole purpose of implementing 218 this specification. 220 The NAS will then perform fragmentation as per this draft to the 221 RADIUS server it is configured to use. That RADIUS server SHOULD 222 then act as a proxy, and forward the Access-Request to the RADIUS 223 server on the CoA client. That RADIUS server can then send the large 224 amounts of authorization to the proxy, which then sends them to the 225 NAS. 227 That is, the NAS sends packets to a server which proxies them to the 228 system which is co-located with the CoA client. This process is more 229 complicated than allowing for fragmented CoA packets. However, the 230 CoA client and the RADIUS server must communicate even when not using 231 this specification. We believe that standardizing that 232 communication, and using one method for exchange of large data is 233 preferred to unspecified communication methods and multiple ways of 234 achieving the same result. 236 3. Overview 238 Authorization exchanges can occur either before or after end user 239 authentication has been completed. An authorization exchange before 240 authentication allows a RADIUS client to provide the RADIUS server 241 with information that MAY modify how the authentication process will 242 be performed (e.g. it MAY affect the selection of the EAP method). 243 An authorization exchange after authentication allows the RADIUS 244 server to provide the RADIUS client with information about the end 245 user, the results of the authentication process and/or obligations to 246 be enforced. In this specification we refer to the "pre- 247 authorization" as the exchange of authorization information before 248 the end user authentication has started, while the term "post- 249 authorization" is used to refer to an authorization exchange 250 happening after this authentication process. 252 In this specification we refer to the "size limit" as the practical 253 limit on RADIUS packet sizes. This limit is the minimum of 4096 254 octets, and the current PMTU. We define below a method which uses 255 Access-Request and Access-Accept in order to exchange fragmented 256 data. The NAS and server exchange a series of Access-Request / 257 Access-Accept packets, until such time as all of the fragmented data 258 has been transported. Each packet contains a Frag-Status attribute 259 which lets the other party know if fragmentation is desired, ongoing, 260 or finished. Each packet may also contain the fragmented data, or 261 instead be an "ACK" to a previous fragment from the other party. 262 Each Access-Request contains a User-Name attribute, allowing the 263 packet to be proxied if necessary (see Section 9.1). Each Access- 264 Request may also contain a State attribute, which serves to tie it to 265 a previous Access-Accept. Each Access-Accept contains a State 266 attribute, for use by the NAS in a later Access-Request. Each 267 Access-Accept contains a Service-Type indicating that the service 268 being provided is fragmentation, and that the Access-Accept should 269 not be interpreted as providing network access to the end user. 271 When a RADIUS client or server need to send data that exceeds the 272 size limit, the mechanism proposed in this document is used. Instead 273 of encoding one large RADIUS packet, a series of smaller RADIUS 274 packets of the same type are encoded. Each smaller packet is called 275 a "chunk" in this specification, in order to distinguish it from 276 traditional RADIUS packets. The encoding process is a simple linear 277 walk over the attributes to be encoded. This walk preserves the 278 order of the attributes, as required by [RFC2865]. The number of 279 attributes encoded in a particular chunk depends on the size limit, 280 the size of each attribute, the number of proxies between client and 281 server, and the overhead for fragmentation signalling attributes. 282 Specific details are given in Section 5. A a new attribute called 283 Frag-Status (Section 8.1) signals the fragmentation status. 285 After the first chunk is encoded, it is sent to the other party. The 286 packet is identified as a chunk via the Frag-Status attribute. The 287 other party then requests additional chunks, again using the Frag- 288 Status attribute. This process is repeated until all the attributes 289 have been sent from one party to the other. When all the chunks have 290 been received, the original list of attributes is reconstructed and 291 processed as if it had been received in one packet. 293 When multiple chunks are sent, a special situation may occur for 294 Extended Type attributes as defined in [RFC6929]. The fragmentation 295 process may split a fragmented attribute across two or more chunks, 296 which is not permitted by that specification. We address this issue 297 by defining a new field in the Reserved field of the "Long Extended 298 Type" attribute format. This field is one bit in size, and is called 299 "T" for Truncation. It indicates that the attribute is intentionally 300 truncated in this chunk, and is to be continued in the next chunk of 301 the sequence. The combination of the flags "M" and "T" indicates 302 that the attribute is fragmented (flag M), but that all the fragments 303 are not available in this chunk (flag T). Proxies implementing 304 [RFC6929] will see these attributes as invalid (they will not be able 305 to reconstruct them), but they will still forward them as [RFC6929] 306 section 5.2 indicates they SHOULD forward unknown attributes anyway. 308 This last situation is expected to be the most common occurrence in 309 chunks. Typically, packet fragmentation will occur as a consequence 310 of a desire to send one or more large (and therefore fragmented) 311 attributes. The large attribute will likely be split into two or 312 more pieces. Where chunking does not split a fragmented attribute, 313 no special treatment is necessary. 315 The setting of the "T" flag is the only case where the chunking 316 process affects the content of an attribute. Even then, the "Value" 317 fields of all attributes remain unchanged. Any per-packet security 318 attributes such as Message-Authenticator are calculated for each 319 chunk independently. There are neither integrity nor security checks 320 performed on the "original" packet. 322 Each RADIUS packet sent or received as part of the chunking process 323 MUST be a valid packet, subject to all format and security 324 requirements. This requirement ensures that a "transparent" proxy 325 not implementing this specification can receive and send compliant 326 packets. That is, a proxy which simply forwards packets without 327 detailed examination or any modification will be able to proxy 328 "chunks". 330 4. Fragmentation of packets 332 When the NAS or the AS desires to send a packet that exceeds the size 333 limit, it is split into chunks and sent via multiple client/server 334 exchanges. The exchange is indicated via the Frag-Status attribute, 335 which has value More-Data-Pending for all but the last chunk of the 336 series. The chunks are tied together via the State attribute. 338 The following sections describe how to perform fragmentation for 339 packets from the NAS to the server, followed by packets from the 340 server to the NAS. We give the packet type, along with a RADIUS 341 Identifier, to indicate that requests and responses are connected. 342 We then give a list of attributes. We do not give values for most 343 attributes, as we wish to concentrate on the fragmentation behaviour, 344 rather than packet contents. Attribute values are given for 345 attributes relevant to the fragmentation process. Where "long 346 extended" attributes are used, we indicate the M (More) and T 347 (Truncation) flags as optional square brackets after the attribute 348 name. As no "long extended" attributes have yet been defined, we use 349 example attributes, named as "Example-Long-1", etc. The maximum 350 chunk size is established in term of number of attributes (11), for 351 sake of simplicity. 353 4.1. Pre-authorization 355 When the client needs to send a large amount of data to the server, 356 the data to be sent is split into chunks and sent to the server via 357 multiple Access-Request / Access-Accept exchanges. The example below 358 shows this exchange. 360 The following is an Access-Request which the NAS intends to send to a 361 server. However, due to a combination of issues (PMTU, large 362 attributes, etc.), the content does not fit into one Access-Request 363 packet. 365 Access-Request 366 User-Name 367 NAS-Identifier 368 Calling-Station-Id 369 Example-Long-1 [M] 370 Example-Long-1 [M] 371 Example-Long-1 [M] 372 Example-Long-1 [M] 373 Example-Long-1 [M] 374 Example-Long-1 [M] 375 Example-Long-1 [M] 376 Example-Long-1 [M] 377 Example-Long-1 378 Example-Long-2 [M] 379 Example-Long-2 [M] 380 Example-Long-2 382 Figure 1: Desired Access-Request 384 The NAS therefore must send the attributes listed above in a series 385 of chunks. The first chunk contains eight (8) attributes from the 386 original Access-Request, and a Frag-Status attribute. Since last 387 attribute is "Example-Long-1" with the "M" flag set, the chunking 388 process also sets the "T" flag in that attribute. The Access-Request 389 is sent with a RADIUS Identifier field having value 23. The Frag- 390 Status attribute has value More-Data-Pending, to indicate that the 391 NAS wishes to send more data in a subsequent Access-Request. The NAS 392 also adds a Service-Type attribute, which indicates that it is part 393 of the chunking process. The packet is signed with the Message- 394 Authenticator attribute, completing the maximum number of attributes 395 (11). 397 Access-Request (ID = 23) 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 [MT] 406 Frag-Status = More-Data-Pending 407 Service-Type = Additional-Authorization 408 Message-Authenticator 410 Figure 2: Access-Request (chunk 1) 412 Compliant servers receiving this packet will see the Frag-Status 413 attribute, wand suspend all authorization and authentication handling 414 until all of the chunks have been received. Non-compliant servers 415 should also see the Service-Type requesting provisioning for an 416 unknown service, and return Access-Reject. Other non-compliant 417 servers may return an Access-Reject, Access-Challenge, or an Access- 418 Accept with a particular Service-Type. Compliant NAS implementations 419 MUST treat these responses as if they had received Access-Reject 420 instead. 422 Compliant servers who wish to receive all of the chunks will respond 423 with the following packet. The value of the State here is arbitrary, 424 and serves only as a unique token for example purposes. We only note 425 that it MUST be globally and temporally unique. 427 Access-Accept (ID = 23) 428 Frag-Status = More-Data-Request 429 Service-Type = Additional-Authorization 430 State = 0xabc00001 431 Message-Authenticator 433 Figure 3: Access-Accept (chunk 1) 435 The NAS will see this response, and use the RADIUS Identifier field 436 to associate it with an ongoing chunking session. Compliant NASes 437 will then continue the chunking process. Non-compliant NASes will 438 never see a response such as this, as they will never send a Frag- 439 Status attribute. The Service-Type attribute is included in the 440 Access-Accept in order to signal that the response is part of the 441 chunking process. This packet therefore does not provision any 442 network service for the end user. 444 The NAS continues the process by sending the next chunk, which 445 includes an additional six (6) attributes from the original packet. 446 It again includes the User-Name attribute, so that non-compliant 447 proxies can process the packet (see Section 9.1). It sets the Frag- 448 Status attribute to More-Data-Pending, as more data is pending. It 449 includes a Service-Type for reasons described above. It includes the 450 State attribute from the previous Access-accept. It signs the packet 451 with Message-Authenticator, as there are no authentication attributes 452 in the packet. It uses a new RADIUS Identifier field. 454 Access-Request (ID = 181) 455 User-Name 456 Example-Long-1 [M] 457 Example-Long-1 [M] 458 Example-Long-1 [M] 459 Example-Long-1 460 Example-Long-2 [M] 461 Example-Long-2 [MT] 462 Frag-Status = More-Data-Request 463 Service-Type = Additional-Authorization 464 State = 0xabc000001 465 Message-Authenticator 467 Figure 4: Access-Request (chunk 2) 469 Compliant servers receiving this packet will see the Frag-Status 470 attribute, and look for a State attribute. Since one exists and it 471 matches a State sent in an Access-Accept, this packet is part of a 472 chunking process. The server will associate the attributes with the 473 previous chunk. Since the Frag-Status attribute has value More-Data- 474 Request, the server will respond with an Access-Accept as before. It 475 MUST include a State attribute, with a value different from the 476 previous Access-Accept. This State MUST again be globally and 477 temporally unique. 479 Access-Accept (ID = 181) 480 Frag-Status = More-Data-Request 481 Service-Type = Additional-Authorization 482 State = 0xdef00002 483 Message-Authenticator 485 Figure 5: Access-Accept (chunk 2) 487 The NAS will see this response, and use the RADIUS Identifier field 488 to associate it with an ongoing chunking session. The NAS continues 489 the chunking process by sending the next chunk, with the final 490 attribute(s) from the original packet, and again includes the 491 original User-Name attribute. The Frag-Status attribute is not 492 included in the next Access-Request, as no more chunks are available 493 for sending. The NAS includes the State attribute from the previous 494 Access-accept. It signs the packet with Message-Authenticator, as 495 there are no authentication attributes in the packet. It again uses 496 a new RADIUS Identifier field. 498 Access-Request (ID = 241) 499 User-Name 500 Example-Long-2 501 State = 0xdef00002 502 Message-Authenticator 504 Figure 6: Access-Request (chunk 3) 506 On reception of this last chunk, the server matches it with an 507 ongoing session via the State attribute, and sees that there is no 508 Frag-Status attribute present. It then process the received 509 attributes as if they had been sent in one RADIUS packet. See 510 Section 7.4 for further details of this process. It generates the 511 appropriate response, which can be either Access-Accept or Access- 512 Reject. In this example, we show an Access-Accept. The server MUST 513 send a State attribute, which permits link the received data with the 514 authentication process. 516 Access-Accept (ID = 241) 517 State = 0x98700003 518 Message-Authenticator 520 Figure 7: Access-Accept (chunk 3) 522 The above example shows in practice how the chunking process works. 523 We re-iterate the implementation and security requirements here. 525 Each chunk is a valid RADIUS packet, and all RADIUS format and 526 security requirements MUST be followed before any chunking process is 527 applied. 529 Every chunk except for the last one from a NAS MUST include a Frag- 530 Status attribute, with value More-Data-Pending. The last chunk MUST 531 NOT contain a Frag-Status attribute. Each chunk except for the last 532 from a NAS MUST include a Service-Type attribute, with value 533 Additional-Authorization. Each chunk MUST include a User-Name 534 attribute, which MUST be identical in all chunks. Each chunk except 535 for the first one from a NAS MUST include a State attribute, which 536 MUST be copied from a previous Access-Accept. 538 Each Access-Accept MUST include a State attribute. The value for 539 this attribute MUST change in every new Access-Accept, and MUST be 540 globally and temporally unique. 542 4.2. Post-authorization 544 When the AS wants to send a large amount of authorization data to the 545 NAS after authentication, the operation is very similar to the pre- 546 authorization one. The presence of Service-Type = Additional- 547 Authorization attribute ensures that a NAS not supporting this 548 specification will treat that unrecognized Service-Type as though an 549 Access-Reject had been received instead ([RFC2865] Section 5.6). If 550 the original large Access-Accept packet contained a Service-Type 551 attribute, it will be included with its original value in the last 552 transmitted chunk, to avoid confusion with the one used for 553 fragmentation signalling. 555 Client supporting this specification MUST include a Frag-Status = 556 Fragmentation-Supported attribute in the first Access-Request sent to 557 the server, in order to indicate they would accept fragmented data 558 from the sever. This is not required if pre-authorization process 559 was carried out, as it is implicit. 561 The following is an Access-Accept which the AS intends to send to a 562 client. However, due to a combination of issues (PMTU, large 563 attributes, etc.), the content does not fit into one Access-Accept 564 packet. 566 Access-Accept 567 User-Name 568 EAP-Message 569 Service-Type(Login) 570 Example-Long-1 [M] 571 Example-Long-1 [M] 572 Example-Long-1 [M] 573 Example-Long-1 [M] 574 Example-Long-1 [M] 575 Example-Long-1 [M] 576 Example-Long-1 [M] 577 Example-Long-1 [M] 578 Example-Long-1 579 Example-Long-2 [M] 580 Example-Long-2 [M] 581 Example-Long-2 583 Figure 8: Desired Access-Accept 585 The AS therefore must send the attributes listed above in a series of 586 chunks. The first chunk contains eight (7) attributes from the 587 original Access-Accept, and a Frag-Status attribute. Since last 588 attribute is "Example-Long-1" with the "M" flag set, the chunking 589 process also sets the "T" flag in that attribute. The Access-Accept 590 is sent with a RADIUS Identifier field having value 30 corresponding 591 to a previous Access-Request not depicted. The Frag-Status attribute 592 has value More-Data-Pending, to indicate that the AS wishes to send 593 more data in a subsequent Access-Accept. The AS also adds a Service- 594 Type attribute with value Additional-Authorization, which indicates 595 that it is part of the chunking process. Note that the original 596 Service-Type is not included in this chunk. Finally, a State 597 attribute is included to allow matching subsequent requests with this 598 conversation, and the packet is signed with the Message-Authenticator 599 attribute, completing the maximum number of attributes of 11. 601 Access-Accept (ID = 30) 602 User-Name 603 EAP-Message 604 Example-Long-1 [M] 605 Example-Long-1 [M] 606 Example-Long-1 [M] 607 Example-Long-1 [M] 608 Example-Long-1 [MT] 609 Frag-Status = More-Data-Pending 610 Service-Type = Additional-Authorization 611 State = 0xcba00004 612 Message-Authenticator 614 Figure 9: Access-Accept (chunk 1) 616 Compliant clients receiving this packet will see the Frag-Status 617 attribute, wand suspend all authorization and authentication handling 618 until all of the chunks have been received. Non-compliant clients 619 should also see the Service-Type indicating the provisioning for an 620 unknown service, and will treat it as an Access-Reject. 622 Clients who wish to receive all of the chunks will respond with the 623 following packet, where the value of the State attribute is taken 624 from the received Access-Accept. They also include the User-Name 625 attribute so that non-compliant proxies can process the packet 626 (Section 9.1). 628 Access-Request (ID = 131) 629 User-Name 630 Frag-Status = More-Data-Request 631 Service-Type = Additional-Authorization 632 State = 0xcba00004 633 Message-Authenticator 635 Figure 10: Access-Request (chunk 1) 637 The AS receives this request, and uses the State attribute to 638 associate it with an ongoing chunking session. Compliant ASes will 639 then continue the chunking process. Non-compliant ASes will never 640 see a response such as this, as they will never send a Frag-Status 641 attribute. 643 The AS continues the chunking process by sending the next chunk, with 644 the final attribute(s) from the original packet. The value of the 645 Identifier field is taken from the received Access-Request. A Frag- 646 Status attribute is not included in the next Access-Accept, as no 647 more chunks are available for sending. The AS includes an State 648 attribute to allow the client to send additional authorization data. 649 The original Service-Type attribute is included in this final chunk. 651 Access-Accept (ID = 131) 652 Example-Long-1 [M] 653 Example-Long-1 [M] 654 Example-Long-1 [M] 655 Example-Long-1 656 Example-Long-2 [M] 657 Example-Long-2 [M] 658 Example-Long-2 659 Service-Type = Login 660 State = 0xfda000005 661 Message-Authenticator 663 Figure 11: Access-Accept (chunk 2) 665 On reception of this last chunk, the client matches it with an 666 ongoing session via the Identifier field, and sees that there is no 667 Frag-Status attribute present. It then processes the received 668 attributes as if they had been sent in one RADIUS packet. See 669 Section 7.4 for further details of this process. 671 5. Chunk size 673 In an ideal scenario, each intermediate chunk would be exactly the 674 size limit in length. In this way, the number of round trips 675 required to send a large packet would be optimal. However, this is 676 not possible for several reasons. 678 1. RADIUS attributes have a variable length, and must be included 679 completely in a chunk. Thus, it is possible that, even if there 680 is some free space in the chunk, it is not enough to include the 681 next attribute. This can generate up to 254 octets of spare 682 space on every chunk. 684 2. RADIUS fragmentation requires the introduction of some extra 685 attributes for signalling. Specifically, a Frag-Status attribute 686 (7 octets) is included on every chunk of a packet, except the 687 last one. A RADIUS State attribute (from 3 to 255 octets) is 688 also included in most chunks, to allow the server to bind an 689 Access-Request with a previous Access-Challenge. User-Name 690 attributes (from 3 to 255 octets) are introduced on every chunk 691 the client sends as they are required by the proxies to route the 692 packet to its destination. Together, these attributes can 693 generate from up to 13 to 517 octets of signalling data, reducing 694 the amount of payload information that can be sent on each chunk. 696 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network 697 MTU. Otherwise, IP fragmentation may occur, having undesirable 698 consequences. Hence, maximum chunk size would be decreased from 699 4096 to the actual MTU of the network. 701 4. The inclusion of Proxy-State attributes by intermediary proxies 702 can decrease the availability of usable space into the chunk. 703 This is described with further detail in Section 7.1. 705 6. Allowed large packet size 707 There are no provisions for signalling how much data is to be sent 708 via the fragmentation process as a whole. It is difficult to define 709 what is meant by the "length" of any fragmented data. That data can 710 be multiple attributes, which includes RADIUS attribute header 711 fields. Or it can be one or more "large" attributes (more than 256 712 octets in length). Proxies can also filter these attributes, to 713 modify, add, or delete them and their contents. These proxies act on 714 a "packet by packet" basis, and cannot know what kind of filtering 715 actions they take on future packets. As a result, it is impossible 716 to signal any meaningful value for the total amount of additional 717 data. 719 Unauthenticated clients are permitted to trigger the exchange of 720 large amounts of fragmented data between the NAS and the AS, having 721 the potential to allow Denial of Service (DoS) attacks. An attacker 722 could initiate a large number of connections, each of which requests 723 the server to store a large amount of data. This data could cause 724 memory exhaustion on the server, and result in authentic users being 725 denied access. It is worth noting that authentication mechanisms are 726 already designed to avoid exceeding the size limit. 728 Hence, implementations of this specification MUST limit the total 729 amount of data they send and/or receive via this specification. It 730 is RECOMMENDED that the limits be set to a few tens of kilooctets. 731 Any more than this may turn RADIUS into a generic transport protocol, 732 which is undesired. It is RECOMMENDED that this limit be exposed to 733 administrators, so that it can be changed if necessary. 735 Implementations of this specification MUST limit the total number of 736 round trips used during the fragmentation process. It is RECOMMENDED 737 that the number of round trips be limited to twenty (20). Any more 738 than this may indicate an implementation error, misconfiguration, or 739 a denial of service (DoS) attack. It is RECOMMENDED that this limit 740 be exposed to administrators, so that it can be changed if necessary. 742 For instance, let's imagine the RADIUS server wants to transport an 743 SAML assertion which is 15000 octets long, to the RADIUS client. In 744 this hypothetical scenario, we assume there are 3 intermediate 745 proxies, each one inserting a Proxy-State attribute of 20 octets. 746 Also we assume the State attributes generated by the RADIUS server 747 have a size of 6 octets. Therefore, the amount of free space in a 748 chunk for the transport of the SAML assertion attributes is: Total 749 (4096) - RADIUS header (20) - Frag-Status (7 octets) - Service-Type 750 (6 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State 751 (20) - Proxy-State (20) - Message-Authenticator (18 octets), 752 resulting in a total of 3979 octets, that is, 15 attributes of 255 753 bytes. 755 According to [RFC6929], a Long-Extended-Type provides a payload of 756 251 octets. Therefore, the SAML assertion described above would 757 result into 60 attributes, requiring of 4 round-trips to be 758 completely transmitted. 760 7. Handling special attributes 762 7.1. Proxy-State attribute 764 RADIUS proxies may introduce Proxy-State attributes into any Access- 765 Request packet they forward. Should they cannot add this information 766 to the packet, they may silently discard forwarding it to its 767 destination, leading to DoS situations. Moreover, any Proxy-State 768 attribute received by a RADIUS server in an Access-Request packet 769 MUST be copied into the reply packet to it. For these reasons, 770 Proxy-State attributes require a special treatment within the packet 771 fragmentation mechanism. 773 When the RADIUS server replies to an Access-Request packet as part of 774 a conversation involving a fragmentation (either a chunk or a request 775 for chunks), it MUST include every Proxy-State attribute received 776 into the reply packet. This means that the server MUST take into 777 account the size of these Proxy-State attributes in order to 778 calculate the size of the next chunk to be sent. 780 However, while a RADIUS server will always know how many space MUST 781 be left on each reply packet for Proxy-State attributes (as they are 782 directly included by the RADIUS server), a RADIUS client cannot know 783 this information, as Proxy-State attributes are removed from the 784 reply packet by their respective proxies before forwarding them back. 785 Hence, clients need a mechanism to discover the amount of space 786 required by proxies to introduce their Proxy-State attributes. In 787 the following we describe a new mechanism to perform such a 788 discovery: 790 1. When a RADIUS client does not know how many space will be 791 required by intermediate proxies for including their Proxy-State 792 attributes, it SHOULD start using a conservative value (e.g. 1024 793 octets) as the chunk size. 795 2. When the RADIUS server receives a chunk from the client, it can 796 calculate the total size of the Proxy-State attributes that have 797 been introduced by intermediary proxies along the path. This 798 information MUST be returned to the client in the next reply 799 packet, encoded into a new attribute called Proxy-State-Len. The 800 server MAY artificially increase this quantity in order to handle 801 with situations where proxies behave inconsistently (e.g. they 802 generate Proxy-State attributes with a different size for each 803 packet), or for situations where intermediary proxies remove 804 Proxy-State attributes generated by other proxies. Increasing 805 this value would make the client to leave some free space for 806 these situations. 808 3. The RADIUS client SHOULD react upon the reception of this 809 attribute by adjusting the maximum size for the next chunk 810 accordingly. However, as the Proxy-State-Len offers just an 811 estimation of the space required by the proxies, the client MAY 812 select a smaller amount in environments known to be problematic. 814 7.2. State attribute 816 This RADIUS fragmentation mechanism makes use of the State attribute 817 to link all the chunks belonging to the same fragmented packet. 818 However, some considerations are required when the RADIUS server is 819 fragmenting a packet that already contains a State attribute for 820 other purposes not related with the fragmentation. If the procedure 821 described in Section 4 is followed, two different State attributes 822 could be included into a single chunk, incurring into two problems. 823 First, [RFC2865] explicitly forbids that more than one State 824 attribute appears into a single packet. 826 A straightforward solution consists on making the RADIUS server to 827 send the original State attribute into the last chunk of the sequence 828 (attributes can be re-ordered as specified in [RFC2865]). As the 829 last chunk (when generated by the RADIUS server) does not contain any 830 State attribute due to the fragmentation mechanism, both situations 831 described above are avoided. 833 Something similar happens when the RADIUS client has to send a 834 fragmented packet that contains a State attribute on it. The client 835 MUST assure that this original State is included into the first chunk 836 sent to the server (as this one never contains any State attribute 837 due to fragmentation). 839 7.3. Service-Type attribute 841 This RADIUS fragmentation mechanism makes use of the Service-Type 842 attribute to indicate an Access-Accept packet is not granting access 843 to the service yet, since additional authorization exchange needs to 844 be performed. Similarly to the State attribute, the RADIUS server 845 has to send the original Service-Type attribute into the last Access- 846 Accept of the RADIUS conversation to avoid ambiguity. 848 7.4. Rebuilding the original large packet 850 The RADIUS client stores the RADIUS attributes received on each chunk 851 in order to be able to rebuild the original large packet after 852 receiving the last chunk. However, some of these received attributes 853 MUST NOT be stored in this list, as they have been introduced as part 854 of the fragmentation signalling and hence, they are not part of the 855 original packet. 857 o State (except the one in the last chunk, if present) 859 o Service-Type = Additional-Authorization 861 o Frag-Status 863 o Proxy-State-Len 865 Similarly, the RADIUS server MUST NOT store the following attributes 866 as part of the original large packet: 868 o State (except the one in the first chunk, if present) 870 o Frag-Status 872 o Proxy-State (except the ones in the last chunk) 874 o User-Name (except the one in the first chunk) 876 8. New attribute definition 878 This document proposes the definition of two new extended type 879 attributes, called Frag-Status and Proxy-State-Len. The format of 880 these attributes follows the indications for an Extended Type 881 attribute defined in [RFC6929]. 883 8.1. Frag-Status attribute 885 This attribute is used for fragmentation signalling, and its meaning 886 depends on the code value transported within it. The following 887 figure represents the format of the Frag-Status attribute. 889 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | Extended-Type | Code 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Code (cont) | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Figure 12: Frag-Status format 899 Type 901 To be assigned (TBA) 903 Length 905 7 907 Extended-Type 909 To be assigned (TBA). 911 Code 913 4 byte. Integer indicating the code. The values defined in this 914 specifications are: 916 0 - Reserved 918 1 - Fragmentation-Supported 920 2 - More-Data-Pending 922 3 - More-Data-Request 924 This attribute MAY be present in Access-Request, Access-Challenge and 925 Access-Accept packets. It MUST not be included in Access-Reject 926 packets. 928 8.2. Proxy-State-Len attribute 930 This attribute indicates to the RADIUS client the length of the 931 Proxy-State attributes received by the RADIUS server. This 932 information is useful to adjust the length of the chunks sent by the 933 RADIUS client. The format of this Proxy-State-Len attribute is the 934 following: 936 1 2 3 937 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 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Type | Length | Extended-Type | Value 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Value (cont) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 13: Proxy-State-Len format 946 Type 948 To be assigned (TBA) 950 Length 952 7 954 Extended-Type 956 To be assigned (TBA). 958 Value 960 4 octets. Total length (in octets) of received Proxy-State 961 attributes (including headers). 963 This attribute MAY be present in Access-Challenge and Access-Accept 964 packets. It MUST not be included in Access-Request or Access-Reject 965 packets. 967 8.3. Table of attributes 969 The following table shows the different attributes defined in this 970 document related with the kind of RADIUS packets where they can be 971 present. 973 | Kind of packet | 974 +-----+-----+-----+-----+ 975 Attribute Name | Req | Acc | Rej | Cha | 976 ----------------------+-----+-----+-----+-----+ 977 Frag-Status | 0-1 | 0-1 | 0 | 0-1 | 978 ----------------------+-----+-----+-----+-----+ 979 Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | 980 ----------------------+-----+-----+-----+-----+ 982 Figure 14 984 9. Operation with proxies 986 The fragmentation mechanism defined above is designed to be 987 transparent to legacy proxies, as long as they do not want to modify 988 any fragmented attribute. Nevertheless, updated proxies supporting 989 this specification can even modify fragmented attributes. 991 9.1. Legacy proxies 993 As every chunk is indeed a RADIUS packet, legacy proxies treat them 994 as the rest of packets, routing them to their destination. Proxies 995 can introduce Proxy-State attributes to Access-Request packets, even 996 if they are indeed chunks. This will not affect how fragmentation is 997 managed. The server will include all the received Proxy-State 998 attributes into the generated response, as described in [RFC2865]. 999 Hence, proxies do not distinguish between a regular RADIUS packet and 1000 a chunk. 1002 This proposal assumes legacy proxies to base their routing decisions 1003 on the value of the User-Name attribute. For this reason, every 1004 packet sent from the client to the server (either chunks or requests 1005 for more chunks) MUST contain a User-Name attribute. 1007 9.2. Updated proxies 1009 Updated proxies can interact with clients and servers in order to 1010 obtain the complete large packet before start forwarding it. In this 1011 way, proxies can manipulate (modify and/or remove) any attribute of 1012 the packet, or introduce new attributes, without worrying about 1013 crossing the boundaries of the chunk size. Once the manipulated 1014 packet is ready, it is sent to the original destination using the 1015 fragmentation mechanism (if required). The following example shows 1016 how an updated proxy interacts with the NAS to obtain a large Access- 1017 Request packet, modify an attribute resulting into a even more large 1018 packet, and interacts with the AS to complete the transmission of the 1019 modified packet. 1021 +-+-+-+-+ +-+-+-+-+ 1022 | NAS | | Proxy | 1023 +-+-+-+-+ +-+-+-+-+ 1024 | | 1025 | Access-Request(1){User-Name,Calling-Station-Id, | 1026 | Example-Long-1[M],Example-Long-1[M], | 1027 | Example-Long-1[M],Example-Long-1[M], | 1028 | Example-Long-1[MT],Frag-Status(MDP)} | 1029 |--------------------------------------------------->| 1030 | | 1031 | Access-Challenge(1){User-Name, | 1032 | Frag-Status(MDR),State1} | 1033 |<---------------------------------------------------| 1034 | | 1035 | Access-Request(2)(User-Name,State1, | 1036 | Example-Long-1[M],Example-Long-1[M], | 1037 | Example-Long-1[M],Example-Long-1} | 1038 |--------------------------------------------------->| 1040 PROXY MODIFIES ATTRIBUTE Data INCREASING ITS 1041 SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS 1043 Figure 15: Updated proxy interacts with NAS 1045 +-+-+-+-+ +-+-+-+-+ 1046 | Proxy | | AS | 1047 +-+-+-+-+ +-+-+-+-+ 1048 | | 1049 | Access-Request(3){User-Name,Calling-Station-Id, | 1050 | Example-Long-1[M],Example-Long-1[M], | 1051 | Example-Long-1[M],Example-Long-1[M], | 1052 | Example-Long-1[MT],Frag-Status(MDP)} | 1053 |--------------------------------------------------->| 1054 | | 1055 | Access-Challenge(1){User-Name, | 1056 | Frag-Status(MDR),State2} | 1057 |<---------------------------------------------------| 1058 | | 1059 | Access-Request(4){User-Name,State2, | 1060 | Example-Long-1[M],Example-Long-1[M], | 1061 | Example-Long-1[M],Example-Long-1[M], | 1062 | Example-Long-1[MT],Frag-Status(MDP)} | 1063 |--------------------------------------------------->| 1064 | | 1065 | Access-Challenge(1){User-Name, | 1066 | Frag-Status(MDR),State3} | 1067 |<---------------------------------------------------| 1068 | | 1069 | Access-Request(5){User-Name,State3,Example-Long-1} | 1070 |--------------------------------------------------->| 1072 Figure 16: Updated proxy interacts with AS 1074 10. Security Considerations 1076 As noted in many earlier specifications ([RFC5080], [RFC6158], etc.) 1077 RADIUS security is problematic. This specification changes nothing 1078 related to the security of the RADIUS protocol. It requires that all 1079 Access-Request packets associated with fragmentation are signed using 1080 the existing Message-Authenticator attribute. This signature 1081 prevents forging and replay, to the limits of the existing security. 1083 The ability to send bulk data from one party to another creates new 1084 security considerations. Clients and servers may have to store large 1085 amounts of data per session. The amount of this data can be 1086 significant, leading to the potential for resource exhaustion. We 1087 therefore suggest that implementations limit the amount of bulk data 1088 stored per session. The exact method for this limitation is 1089 implementation-specific. Section 6 gives some indications on what 1090 could be a reasonable limits. 1092 The bulk data can often be pushed off to storage methods other than 1093 the memory of the RADIUS implementation. For example, it can be 1094 stored in an external database, or in files. This approach mitigates 1095 the resource exhaustion issue, as servers today already store large 1096 amounts of accounting data. 1098 11. IANA Considerations 1100 The authors request that Attribute Types and Attribute Values defined 1101 in this document be registered by the Internet Assigned Numbers 1102 Authority (IANA) from the RADIUS namespaces as described in the "IANA 1103 Considerations" section of [RFC3575], in accordance with BCP 26 1104 [RFC5226]. For RADIUS packets, attributes and registries created by 1105 this document IANA is requested to place them at 1106 http://www.iana.org/assignments/radius-types. 1108 This document defines the following RADIUS messages: 1110 o Frag-Status 1112 o Proxy-State-Len 1114 Additionally, allocation of a new Service-Type value for "Additional- 1115 Authorization" is requested. 1117 12. References 1119 12.1. Normative References 1121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1122 Requirement Levels", BCP 14, RFC 2119, March 1997. 1124 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1125 "Remote Authentication Dial In User Service (RADIUS)", 1126 RFC 2865, June 2000. 1128 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1130 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 1131 Authentication Dial In User Service)", RFC 3575, 1132 July 2003. 1134 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1135 Dial In User Service) Support For Extensible 1136 Authentication Protocol (EAP)", RFC 3579, September 2003. 1138 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 1139 Dial In User Service (RADIUS) Implementation Issues and 1140 Suggested Fixes", RFC 5080, December 2007. 1142 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1143 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1144 May 2008. 1146 [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", 1147 BCP 158, RFC 6158, March 2011. 1149 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 1150 Service (RADIUS) Protocol Extensions", RFC 6929, 1151 April 2013. 1153 12.2. Informative References 1155 [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter 1156 Rule Attribute", RFC 4849, April 2007. 1158 Authors' Addresses 1160 Alejandro Perez-Mendez (Ed.) 1161 University of Murcia 1162 Campus de Espinardo S/N, Faculty of Computer Science 1163 Murcia, 30100 1164 Spain 1166 Phone: +34 868 88 46 44 1167 Email: alex@um.es 1169 Rafa Marin-Lopez 1170 University of Murcia 1171 Campus de Espinardo S/N, Faculty of Computer Science 1172 Murcia, 30100 1173 Spain 1175 Phone: +34 868 88 85 01 1176 Email: rafa@um.es 1177 Fernando Pereniguez-Garcia 1178 University of Murcia 1179 Campus de Espinardo S/N, Faculty of Computer Science 1180 Murcia, 30100 1181 Spain 1183 Phone: +34 868 88 78 82 1184 Email: pereniguez@um.es 1186 Gabriel Lopez-Millan 1187 University of Murcia 1188 Campus de Espinardo S/N, Faculty of Computer Science 1189 Murcia, 30100 1190 Spain 1192 Phone: +34 868 88 85 04 1193 Email: gabilm@um.es 1195 Diego R. Lopez 1196 Telefonica I+D 1197 Don Ramon de la Cruz, 84 1198 Madrid, 28006 1199 Spain 1201 Phone: +34 913 129 041 1202 Email: diego@tid.es 1204 Alan DeKok 1205 Network RADIUS 1206 15 av du Granier 1207 Meylan, 38240 1208 France 1210 Phone: +34 913 129 041 1211 Email: aland@networkradius.com 1212 URI: http://networkradius.com