--- 1/draft-ietf-radext-radius-fragmentation-00.txt 2013-10-21 12:16:22.436413575 -0700 +++ 2/draft-ietf-radext-radius-fragmentation-01.txt 2013-10-21 12:16:22.488414804 -0700 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Intended status: Experimental F. Pereniguez-Garcia -Expires: February 28, 2014 G. Lopez-Millan +Expires: April 24, 2014 G. Lopez-Millan University of Murcia D. Lopez Telefonica I+D A. DeKok Network RADIUS - August 27, 2013 + October 21, 2013 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-00 + draft-ietf-radext-radius-fragmentation-01 Abstract The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 28, 2014. + This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -55,44 +55,44 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Scope of this document . . . . . . . . . . . . . . . . . . . . 4 - 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 7 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 8 4.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 8 4.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 12 - 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 15 - 7. Handling special attributes . . . . . . . . . . . . . . . . . 16 - 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 16 - 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 17 - 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 17 - 7.4. Rebuilding the original large packet . . . . . . . . . . . 17 - 8. New attribute definition . . . . . . . . . . . . . . . . . . . 18 - 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 18 - 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 19 - 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 20 - 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 20 - 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 20 - 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 21 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + 5. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. Allowed large packet size . . . . . . . . . . . . . . . . . . 16 + 7. Handling special attributes . . . . . . . . . . . . . . . . . 17 + 7.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17 + 7.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18 + 7.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 19 + 7.4. Rebuilding the original large packet . . . . . . . . . . . 19 + 8. New attribute definition . . . . . . . . . . . . . . . . . . . 19 + 8.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 20 + 8.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 21 + 8.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21 + 9. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22 + 9.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22 + 9.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a Network Access Server (NAS) and an Authentication Server (AS). Information is exchanged between the NAS and the AS through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 octets. The protocol is a request/response protocol, as described in the operational model ( [RFC6158], Section @@ -143,28 +143,27 @@ o PMTU discovery does not solve the problem, as it does not allow to send data larger than the minimum of (PMTU or 4096) octets. This document provides a mechanism to allow RADIUS peers to exchange large amounts of authorization data exceeding the 4096 octet limit, by fragmenting it across several client/server exchanges. The proposed solution does not impose any additional requirements to the RADIUS system administrators (e.g. need to modify firewall rules, set up web servers, configure routers, or modify any application server). It maintains compatibility with intra-packet fragmentation mechanisms - (like those defined in [RFC3579] or in - [I-D.ietf-radext-radius-extensions]). It is also transparent to - existing RADIUS proxies, which do not implement this specification. - The only systems needing to implement the draft are the ones which - either generate, or consume the fragmented data being transmitted. - Intermediate proxies just pass the packets without changes. - Nevertheless, if a proxy supports this specification, it MAY re- - assemble the data in order to either examine and/or modify it. + (like those defined in [RFC3579] or in [RFC6929]). It is also + transparent to existing RADIUS proxies, which do not implement this + specification. The only systems needing to implement the draft are + the ones which either generate, or consume the fragmented data being + transmitted. Intermediate proxies just pass the packets without + changes. Nevertheless, if a proxy supports this specification, it + MAY re-assemble the data in order to either examine and/or modify it. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Scope of this document This specification describes how a RADIUS client and a RADIUS server @@ -188,38 +187,58 @@ existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 5.11 has been proven to work here. Similarly, there is no need to fragment CoA packets. Instead, the CoA client MUST send a CoA-Request packet containing session identification attributes, along with Service-Type = Additional- Authorization, and a State attribute. Implementations not supporting fragmentation will respond with a CoA-NAK, and an Error-Cause of Unsupported-Service. - Implementations supporting this specification may not be able to - change authorization data for a particular session. In that case, - they MUST respond with a CoA-NAK, as above. Otherwise, the - implementation MUST start fragmentation via Access-Request, using the - methods defined here. + The above requirement does not assume that the CoA client and the + RADIUS server are co-located. They may, in fact be run on separate + parts of the infrastructure, or even by separate administrators. + There is, however, a requirement that the two communicate. We can + see that the CoA client needs to send session identification + attributes in order to send CoA packets. These attributes cannot be + known a priori by the CoA client, and can only come from the RADIUS + server. Therefore, even when the two systems are not co-located, + they must be able to communicate in order to operate in unison. The + alternative is for the two systems to have differing views of the + users authorization parameters, which is a security disaster. - The above requirement solves a number of issues. It clearly - separates session identification from authorization. Without this - separation, it is difficult to both identify a session, and change - its authorization using the same attribute. It also ensures that the - authorization process is the same for initial authentication, and for - CoA. + This specification does not allow for fragmentation of CoA packets. + Allowing for fragmented CoA packets would involve changing multiple + parts of the RADIUS protocol, with the corresponding possibility for + implementation issues, mistakes, etc. - When a sessions authorization is changed, the CoA server MUST - continue the existing service until the new authorization parameters - are applied. The change of service SHOULD be done atomically. If - the CoA server is unable to apply the new authorization, it MUST - terminate the user session. + Where CoA clients need to send large amounts of authorization data to + a NAS, they need only send a minimal CoA-Request packet, containing + Service-Type of Authorize-Only, as per RFC 5176. They SHOULD also + have a co-located RADIUS server, for the sole purpose of implementing + this specification. + + The NAS will then perform fragmentation as per this draft to the + RADIUS server it is configured to use. That RADIUS server SHOULD + then act as a proxy, and forward the Access-Request to the RADIUS + server on the CoA client. That RADIUS server can then send the large + amounts of authorization to the proxy, which then sends them to the + NAS. + + That is, the NAS sends packets to a server which proxies them to the + system which is co-located with the CoA client. This process is more + complicated than allowing for fragmented CoA packets. However, the + CoA client and the RADIUS server must communicate even when not using + this specification. We believe that standardizing that + communication, and using one method for exchange of large data is + preferred to unspecified communication methods and multiple ways of + achieving the same result. 3. Overview Authorization exchanges can occur either before or after end user authentication has been completed. An authorization exchange before authentication allows a RADIUS client to provide the RADIUS server with information that MAY modify how the authentication process will be performed (e.g. it MAY affect the selection of the EAP method). An authorization exchange after authentication allows the RADIUS server to provide the RADIUS client with information about the end @@ -233,28 +252,28 @@ In this specification we refer to the "size limit" as the practical limit on RADIUS packet sizes. This limit is the minimum of 4096 octets, and the current PMTU. We define below a method which uses Access-Request and Access-Accept in order to exchange fragmented data. The NAS and server exchange a series of Access-Request / Access-Accept packets, until such time as all of the fragmented data has been transported. Each packet contains a Frag-Status attribute which lets the other party know if fragmentation is desired, ongoing, or finished. Each packet may also contain the fragmented data, or instead be an "ACK" to a previous fragment from the other party. - Each Access-Request contains a User-Name attribute, allowing it to be - proxied if necessary. Each Access-Request may also contain a State - attribute, which serves to tie it to a previous Access-Accept. Each - Access-Accept contains a State attribute, for use by the NAS in a - later Access-Request. Each Access-Accept contains a Service-Type - indicating that the service being provided is fragmentation, and that - the Access-Accept should not be interpreted as providing network - access to the end user. + Each Access-Request contains a User-Name attribute, allowing the + packet to be proxied if necessary (see Section 9.1). Each Access- + Request may also contain a State attribute, which serves to tie it to + a previous Access-Accept. Each Access-Accept contains a State + attribute, for use by the NAS in a later Access-Request. Each + Access-Accept contains a Service-Type indicating that the service + being provided is fragmentation, and that the Access-Accept should + not be interpreted as providing network access to the end user. When a RADIUS client or server need to send data that exceeds the size limit, the mechanism proposed in this document is used. Instead of encoding one large RADIUS packet, a series of smaller RADIUS packets of the same type are encoded. Each smaller packet is called a "chunk" in this specification, in order to distinguish it from traditional RADIUS packets. The encoding process is a simple linear walk over the attributes to be encoded. This walk preserves the order of the attributes, as required by [RFC2865]. The number of attributes encoded in a particular chunk depends on the size limit, @@ -265,31 +284,33 @@ After the first chunk is encoded, it is sent to the other party. The packet is identified as a chunk via the Frag-Status attribute. The other party then requests additional chunks, again using the Frag- Status attribute. This process is repeated until all the attributes have been sent from one party to the other. When all the chunks have been received, the original list of attributes is reconstructed and processed as if it had been received in one packet. When multiple chunks are sent, a special situation may occur for - Extended Type attributes as defined in - [I-D.ietf-radext-radius-extensions]. The fragmentation process may - split a fragmented attribute across two or more chunks, which is not - permitted by that specification. We address this issue by defining a - new field in the Reserved field of the "Long Extended Type" attribute - format. This field is one bit in size, and is called "T" for - Truncation. It indicates that the attribute is intentionally + Extended Type attributes as defined in [RFC6929]. The fragmentation + process may split a fragmented attribute across two or more chunks, + which is not permitted by that specification. We address this issue + by defining a new field in the Reserved field of the "Long Extended + Type" attribute format. This field is one bit in size, and is called + "T" for Truncation. It indicates that the attribute is intentionally truncated in this chunk, and is to be continued in the next chunk of the sequence. The combination of the flags "M" and "T" indicates that the attribute is fragmented (flag M), but that all the fragments - are not available in this chunk (flag T). + are not available in this chunk (flag T). Proxies implementing + [RFC6929] will see these attributes as invalid (they will not be able + to reconstruct them), but they will still forward them as [RFC6929] + section 5.2 indicates they SHOULD forward unknown attributes anyway. This last situation is expected to be the most common occurrence in chunks. Typically, packet fragmentation will occur as a consequence of a desire to send one or more large (and therefore fragmented) attributes. The large attribute will likely be split into two or more pieces. Where chunking does not split a fragmented attribute, no special treatment is necessary. The setting of the "T" flag is the only case where the chunking process affects the content of an attribute. Even then, the "Value" @@ -336,21 +357,21 @@ multiple Access-Request / Access-Accept exchanges. The example below shows this exchange. The following is an Access-Request which the NAS intends to send to a server. However, due to a combination of issues (PMTU, large attributes, etc.), the content does not fit into one Access-Request packet. Access-Request User-Name - User-Password + NAS-Identifier Calling-Station-Id Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 @@ -368,21 +389,21 @@ is sent with a RADIUS Identifier field having value 23. The Frag- Status attribute has value More-Data-Pending, to indicate that the NAS wishes to send more data in a subsequent Access-Request. The NAS also adds a Service-Type attribute, which indicates that it is part of the chunking process. The packet is signed with the Message- Authenticator attribute, completing the maximum number of attributes (11). Access-Request (ID = 23) User-Name - User-Password + NAS-Identifier Calling-Station-Id Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [MT] Frag-Status = More-Data-Pending Service-Type = Additional-Authorization Message-Authenticator @@ -416,26 +437,26 @@ will then continue the chunking process. Non-compliant NASes will never see a response such as this, as they will never send a Frag- Status attribute. The Service-Type attribute is included in the Access-Accept in order to signal that the response is part of the chunking process. This packet therefore does not provision any network service for the end user. The NAS continues the process by sending the next chunk, which includes an additional six (6) attributes from the original packet. It again includes the User-Name attribute, so that non-compliant - proxies can process the packet. It sets the Frag-Status attribute to - More-Data-Pending, as more data is pending. It includes a Service- - Type for reasons described above. It includes the State attribute - from the previous Access-accept. It signs the packet with Message- - Authenticator, as there are no authentication attributes in the - packet. It uses a new RADIUS Identifier field. + proxies can process the packet (see Section 9.1). It sets the Frag- + Status attribute to More-Data-Pending, as more data is pending. It + includes a Service-Type for reasons described above. It includes the + State attribute from the previous Access-accept. It signs the packet + with Message-Authenticator, as there are no authentication attributes + in the packet. It uses a new RADIUS Identifier field. Access-Request (ID = 181) User-Name Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 [M] Example-Long-1 Example-Long-2 [M] Example-Long-2 [MT] Frag-Status = More-Data-Request @@ -594,21 +615,22 @@ Compliant clients receiving this packet will see the Frag-Status attribute, wand suspend all authorization and authentication handling until all of the chunks have been received. Non-compliant clients should also see the Service-Type indicating the provisioning for an unknown service, and will treat it as an Access-Reject. Clients who wish to receive all of the chunks will respond with the following packet, where the value of the State attribute is taken from the received Access-Accept. They also include the User-Name - attribute so that non-compliant proxies can process the packet. + attribute so that non-compliant proxies can process the packet + (Section 9.1). Access-Request (ID = 131) User-Name Frag-Status = More-Data-Request Service-Type = Additional-Authorization State = 0xcba00004 Message-Authenticator Figure 10: Access-Request (chunk 1) @@ -710,20 +732,38 @@ which is undesired. It is RECOMMENDED that this limit be exposed to administrators, so that it can be changed if necessary. Implementations of this specification MUST limit the total number of round trips used during the fragmentation process. It is RECOMMENDED that the number of round trips be limited to twenty (20). Any more than this may indicate an implementation error, misconfiguration, or a denial of service (DoS) attack. It is RECOMMENDED that this limit be exposed to administrators, so that it can be changed if necessary. + For instance, let's imagine the RADIUS server wants to transport an + SAML assertion which is 15000 octets long, to the RADIUS client. In + this hypothetical scenario, we assume there are 3 intermediate + proxies, each one inserting a Proxy-State attribute of 20 octets. + Also we assume the State attributes generated by the RADIUS server + have a size of 6 octets. Therefore, the amount of free space in a + chunk for the transport of the SAML assertion attributes is: Total + (4096) - RADIUS header (20) - Frag-Status (7 octets) - Service-Type + (6 octets) - State (6 octets) - Proxy-State (20 octets) - Proxy-State + (20) - Proxy-State (20) - Message-Authenticator (18 octets), + resulting in a total of 3979 octets, that is, 15 attributes of 255 + bytes. + + According to [RFC6929], a Long-Extended-Type provides a payload of + 251 octets. Therefore, the SAML assertion described above would + result into 60 attributes, requiring of 4 round-trips to be + completely transmitted. + 7. Handling special attributes 7.1. Proxy-State attribute RADIUS proxies may introduce Proxy-State attributes into any Access- Request packet they forward. Should they cannot add this information to the packet, they may silently discard forwarding it to its destination, leading to DoS situations. Moreover, any Proxy-State attribute received by a RADIUS server in an Access-Request packet MUST be copied into the reply packet to it. For these reasons, @@ -749,24 +789,34 @@ 1. When a RADIUS client does not know how many space will be required by intermediate proxies for including their Proxy-State attributes, it SHOULD start using a conservative value (e.g. 1024 octets) as the chunk size. 2. When the RADIUS server receives a chunk from the client, it can calculate the total size of the Proxy-State attributes that have been introduced by intermediary proxies along the path. This information MUST be returned to the client in the next reply - packet, encoded into a new attribute called Proxy-State-Len. + packet, encoded into a new attribute called Proxy-State-Len. The + server MAY artificially increase this quantity in order to handle + with situations where proxies behave inconsistently (e.g. they + generate Proxy-State attributes with a different size for each + packet), or for situations where intermediary proxies remove + Proxy-State attributes generated by other proxies. Increasing + this value would make the client to leave some free space for + these situations. - 3. The RADIUS client reacts upon the reception of this attribute by - adjusting the maximum size for the next chunk accordingly. + 3. The RADIUS client SHOULD react upon the reception of this + attribute by adjusting the maximum size for the next chunk + accordingly. However, as the Proxy-State-Len offers just an + estimation of the space required by the proxies, the client MAY + select a smaller amount in environments known to be problematic. 7.2. State attribute This RADIUS fragmentation mechanism makes use of the State attribute to link all the chunks belonging to the same fragmented packet. However, some considerations are required when the RADIUS server is fragmenting a packet that already contains a State attribute for other purposes not related with the fragmentation. If the procedure described in Section 4 is followed, two different State attributes could be included into a single chunk, incurring into two problems. @@ -821,21 +871,21 @@ o Proxy-State (except the ones in the last chunk) o User-Name (except the one in the first chunk) 8. New attribute definition This document proposes the definition of two new extended type attributes, called Frag-Status and Proxy-State-Len. The format of these attributes follows the indications for an Extended Type - attribute defined in [I-D.ietf-radext-radius-extensions]. + attribute defined in [RFC6929]. 8.1. Frag-Status attribute This attribute is used for fragmentation signalling, and its meaning depends on the code value transported within it. The following figure represents the format of the Frag-Status attribute. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -937,24 +989,28 @@ this specification can even modify fragmented attributes. 9.1. Legacy proxies As every chunk is indeed a RADIUS packet, legacy proxies treat them as the rest of packets, routing them to their destination. Proxies can introduce Proxy-State attributes to Access-Request packets, even if they are indeed chunks. This will not affect how fragmentation is managed. The server will include all the received Proxy-State attributes into the generated response, as described in [RFC2865]. - Hence, proxies do not distinguish between a regular RADIUS packet and a chunk. + This proposal assumes legacy proxies to base their routing decisions + on the value of the User-Name attribute. For this reason, every + packet sent from the client to the server (either chunks or requests + for more chunks) MUST contain a User-Name attribute. + 9.2. Updated proxies Updated proxies can interact with clients and servers in order to obtain the complete large packet before start forwarding it. In this way, proxies can manipulate (modify and/or remove) any attribute of the packet, or introduce new attributes, without worrying about crossing the boundaries of the chunk size. Once the manipulated packet is ready, it is sent to the original destination using the fragmentation mechanism (if required). The following example shows how an updated proxy interacts with the NAS to obtain a large Access- @@ -1055,26 +1111,20 @@ o Proxy-State-Len Additionally, allocation of a new Service-Type value for "Additional- Authorization" is requested. 12. References 12.1. Normative References - [I-D.ietf-radext-radius-extensions] - DeKok, A. and A. Lior, "Remote Authentication Dial In User - Service (RADIUS) Protocol Extensions", - draft-ietf-radext-radius-extensions-13 (work in progress), - February 2013. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote @@ -1089,20 +1139,24 @@ Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. + [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User + Service (RADIUS) Protocol Extensions", RFC 6929, + April 2013. + 12.2. Informative References [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007. Authors' Addresses Alejandro Perez-Mendez (Ed.) University of Murcia Campus de Espinardo S/N, Faculty of Computer Science