idnits 2.17.1 draft-chen-radext-identifier-attr-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 -- The document date (October 20, 2017) is 2380 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft N. Shen 4 Intended Status: Standards Track Cisco Systems 5 Expiration Date: April 21, 2018 October 20, 2017 7 RADIUS Extended Identifier Attribute 8 draft-chen-radext-identifier-attr-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on October 26, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 The limitation with the one-octet "Identifier" field in the RADIUS 51 packet is well known. In this document we propose extensions to the 52 RADIUS protocol to address this fundamental limitation, and thus 53 allowing for more efficient and more scalable implementations. 55 1. Introduction 57 The "Identifier" field in the RADIUS packet [RFC2865] is used to 58 match outstanding requests and replies. As the field is one octet in 59 size, only 256 requests can be in progress between two endpoints, 60 which would present a significant bottleneck for performance. The 61 workaround for this limitation is to use multiple source ports as 62 documented and discussed in [RFC2865], [RFC3539], and [RFC6613]. 64 Currently it is quite common to have hundreds of parallel connections 65 between a RADIUS client and a server, especially in the deployment of 66 controllers for wireless clients. As the scale requirement continues 67 to increase, the number of "parallel connections" is expected to grow 68 (perhaps reaching thousands), which will undoubtedly create a number 69 of challenges with resource utilization, efficiency, and connection 70 management (with RADIUS over TCP [RFC6613] in particular) on both the 71 client and the server. 73 In this document we propose extensions to the RADIUS protocol to 74 address this fundamental limitation and thus allowing for more 75 efficient and more scalable implementations. More specifically, a new 76 attribute ("Extended Identifier Attribute") is defined that can be 77 used to discover the support of this specification between a client 78 and a server using the Status-Server message [RFC5997]. Once the 79 support is confirmed, the attribute can then be used to carry the 80 extended identifier parameter in subsequent RADIUS packets. The 81 extended identifier parameter can be used together with the 82 Identifier to match outstanding requests and replies. 84 For brevity the extensions specified in this document are referred to 85 as "the Extended Identifier feature" hereafter. 87 1.1. Specification of Requirements 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Protocol Extensions 95 2.1. The Extended Identifier Attribute 97 A new attribute, termed "Extended Identifier Attribute", is specified 98 which can be used to discover the support for the Extended Identifier 99 feature between a client and a server. It can also be used to carry 100 the "extended identifier" parameter in a RADIUS packet after the 101 support is confirmed. The attribute number is TBD. The value of the 102 attribute has 4 octets, and consists of the following fields: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 |Sta| Extended Identifier | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 where the 2-bit Status field is to be used in a Status-Server message 111 to discover the support for the Extended Identifier feature. The 112 following settings are defined: 114 o It is set to 1 (for "request") when a client sends the 115 Status-Server request to a server indicating its support for 116 the Extended Identifier feature. 118 o It is set to 2 (for "accept") or 3 (for "reject") by the 119 server in its response to indicate whether it supports the 120 Extended Identifier feature. 122 The 30-bit "Extended Identifier" field is an unsigned integer. It is 123 to be used together with the Identifier field to match outstanding 124 requests and replies. 126 When the "Extended Identifier Attribute" is used in a Status-Server 127 request or reply, only the Status field is used. All other fields 128 SHOULD be set to zero by the sender and MUST be ignored by the 129 receiver. 131 When the "Extended Identifier Attribute" is used in a message other 132 than the Status-Server request or reply, the Status field is unused, 133 and SHOULD be set to zero by the sender and MUST be ignored by the 134 receiver. 136 To simplify packet processing and for consistency, the "Extended 137 Identifier Attribute" MUST be encoded as the very first attribute in 138 the attribute list of a RADIUS packet. If the attribute does not 139 appear as the first one in the attribute list of a RADIUS packet, the 140 RADIUS packet MUST be treated as invalid and the packet be discarded 141 according to [RFC2865]. 143 Due to the hop-by-hop nature of RADIUS packet transmission between 144 RADIUS devices, a PROXY server MUST strip the "Extended Identifier 145 Attribute" (and reconstruct if appropriate) before sending the packet 146 over a different session. 148 2.2. Status-Server Considerations 150 This section extends processing of Status-Server messages as 151 described in Sections 4.1 and 4.2 of [RFC5997]. 153 Prior to sending a RADIUS packet (other than the Status-Server 154 request) with the "Extended Identifier Attribute", a client 155 implementing this specification SHOULD first send a Status-Server 156 request with the "Extended Identifier Attribute" to indicate its 157 support for the Extended Identifier feature. 159 When a server implementing this specification receives a Status- 160 Server request with the "Extended Identifier Attribute", it MUST 161 include the "Extended Identifier Attribute" in its response to 162 indicate whether it supports the Extended Identifier feature. If the 163 Status-server reply from a server does not contain the "Extended 164 Identifier Attribute", the client MUST treat this case as "reject" by 165 the server for the Extended Identifier feature. 167 Unless specified by configuration, a client MUST NOT send a RADIUS 168 packet (other than the Status-Server request) with the "Extended 169 Identifier Attribute" to a server until it has received a response 170 from the server confirming its support for the Extended Identifier 171 feature using the "Extended Identifier Attribute". 173 When TCP is used as the transport protocol for RADIUS [RFC6613] 174 between a client and a server, the Extended Identifier feature SHOULD 175 be discovered each time the TCP session is established. 177 2.3. Use of the Extended Identifier Field 179 After the functionality defined in this specification is discovered 180 between the client and the server, the Extended Identifier field can 181 be carried using the "Extended Identifier Attribute" in a RADIUS 182 packet. The Extended Identifier is to be used together with the 183 Identifier to identify requests and replies. The assignment of these 184 parameters is left to implementation. 186 When the "Extended Identifier Attribute" is present in a RADIUS 187 packet other than the Status-Server request or reply, the Extended 188 Identifier field in the attribute MUST be used together with the 189 Identifier field to identify requests and replies. 191 In response to a request from a client that contains the Extended 192 Identifier field, the server MUST include the Extended Identifier 193 field with an identical value in its reply. 195 3. IANA Considerations 197 A new attribute ("Extended Identifier Attribute") is defined for the 198 RADIUS protocol. The type value [RFC3575] needs to be assigned using 199 the assignment rules in section 10.3 of [RFC6929]. 201 4. Security Considerations 203 This document defines a new RADIUS attribute, which does not affect 204 the security considerations of the RADIUS protocol [RFC2865]. 206 The new RADIUS attribute and the procedures described in this 207 document helps eliminate the need for "parallel connections" between 208 a RADIUS client and a server due to the limitation with the 209 "Identifier" field. Thus the resource utilization (such as the 210 number of UDP/TCP ports) on a RADIUS device is expected to be reduced 211 significantly in large scale deployment. 213 5. Acknowledgments 215 We would like to thank Alan DeKok for useful discussions and 216 suggestions. 218 6. References 220 6.1. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, 224 DOI 10.17487/RFC2119, March 1997, 225 . 227 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 228 "Remote Authentication Dial In User Service (RADIUS)", 229 RFC 2865, June 2000. 231 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 232 Authentication Dial In User Service)", RFC 3575, July 233 2003. 235 6.2. Informative References 237 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization 238 and Accounting (AAA) Transport Profile", RFC 3539, June 239 2003. 241 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 243 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 244 Authentication Dial In User Service (RADIUS) Protocol", 245 RFC 5997, August 2010. 247 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 248 Service (RADIUS) Protocol Extensions", RFC 6929, April 249 2013. 251 7. Authors' Addresses 253 Enke Chen 254 Cisco Systems 255 560 McCarthy Blvd. 256 Milpitas, CA 95035 257 USA 259 Email: enkechen@cisco.com 261 Naiming Shen 262 Cisco Systems 263 560 McCarthy Blvd. 264 Milpitas, CA 95035 265 USA 267 Email: naiming@cisco.com