idnits 2.17.1 draft-chen-radext-extended-header-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 (March 27, 2017) is 2558 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: September 28, 2017 March 27, 2017 7 RADIUS Identifier Attribute 8 draft-chen-radext-extended-header-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 September 28, 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 ("Identifier Attribute") is defined that can be used to 77 discover the support of this specification between a client and a 78 server using the Status-Server message [RFC5997]. Once the support 79 is confirmed, the attribute can then be used to carry the identifier 80 parameter in subsequent RADIUS packets. 82 The attribute also provides an option for carrying the RADIUS packet 83 type "Code" in a larger field just in case that becomes necessary in 84 the future. 86 For brevity the extensions specified in this document are referred to 87 as "the Extended Identifier feature" hereafter. 89 1.1. Specification of Requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Protocol Extensions 97 2.1. The Identifier Attribute 99 A new attribute, termed "Identifier Attribute", is specified which 100 can be used to discover the support for the Extended Identifier 101 feature between a client and a server. It can also be used to carry 102 the Identifier field (and optionally the Code field) in a RADIUS 103 packet after the support is confirmed. The attribute number is TBD. 104 The value of the attribute has 6 octets, and consists of the 105 following fields: 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 |Status | Code | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Identifier | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 where the 4-bit Status field is to be used in a Status-Server message 116 to discover the support for the Extended Identifier feature. The 117 following settings are defined: 119 o It is set to 1 (for "request") when a client sends the 120 Status-Server request to a server indicating its support for 121 the Extended Identifier feature. 123 o It is set to 2 (for "accept") or 3 (for "reject") by the 124 server in its response to indicate whether it supports the 125 Extended Identifier feature. 127 The 12-bit Code field, when needed, can be used in lieu of the Code 128 field in the RADIUS packet header. The field is unused if its value 129 is zero. The field is in use otherwise. 131 The Identifier field is a 4-octet unsigned integer. It is to be used 132 in lieu of the Identifier field in the RADIUS packet header. 134 When the "Identifier Attribute" is used in a Status-Server request or 135 reply, only the Status field is used. All other fields SHOULD be set 136 to zero by the sender and MUST be ignored by the receiver. 138 When the "Identifier Attribute" is used in a message other than the 139 Status-Server request or reply, the Status field is unused, and 140 SHOULD be set to zero by the sender and MUST be ignored by the 141 receiver. 143 Other than the larger sizes for the Identifier field and optionally 144 for the Code field, these two fields remain unchanged semantically as 145 defined in RFC 2865 [RFC2865] (and subsequent documents using the 146 same packet format). 148 To simplify packet processing and for consistency, the "Identifier 149 Attribute" MUST be encoded as the very first attribute in the 150 attribute list of a RADIUS packet. If the attribute does not appear 151 as the first one in the attribute list of a RADIUS packet, the RADIUS 152 packet MUST be treated as invalid and the packet be discarded 153 according to [RFC2865]. 155 Due to the hop-by-hop nature of RADIUS packet transmission between 156 RADIUS devices, a PROXY server MUST strip the "Identifier Attribute" 157 (and reconstruct if appropriate) before sending the packet over a 158 different session. 160 2.2. Status-Server Considerations 162 This section extends processing of Status-Server messages as 163 described in Sections 4.1 and 4.2 of [RFC5997]. 165 Prior to sending a RADIUS packet (other than the Status-Server 166 request) with the "Identifier Attribute", a client implementing this 167 specification SHOULD first send a Status-Server request with the 168 "Identifier Attribute" to indicate its support for the Extended 169 Identifier feature. 171 When a server implementing this specification receives a Status- 172 Server request with the "Identifier Attribute", it MUST include the 173 "Identifier Attribute" in its response to indicate whether it 174 supports the Extended Identifier feature. If the Status-server reply 175 from a server does not contain the "Identifier Attribute", the client 176 MUST treat this case as "reject" by the server for the Extended 177 Identifier feature. 179 Unless specified by configuration, a client MUST NOT send a RADIUS 180 packet (other than the Status-Server request) with the "Identifier 181 Attribute" to a server until it has received a response from the 182 server confirming its support for the Extended Identifier feature 183 using the "Identifier Attribute". 185 When TCP is used as the transport protocol for RADIUS [RFC6613] 186 between a client and a server, the Extended Identifier feature SHOULD 187 be discovered each time the TCP session is established. 189 2.3. Co-existence of Identifier Fields 191 After the functionality defined in this specification is discovered 192 between the client and the server, RADIUS packets can be exchanged 193 using either the Identifier field in the RADIUS packet header 194 (without the "Identifier Attribute" in the packet), or the Identifier 195 field in the "Identifier Attribute" as the very first attribute in 196 the attribute list. 198 When the "Identifier Attribute" is present in a RADIUS packet other 199 than the Status-Server request or reply, the Identifier field in the 200 attribute MUST be used in lieu of the Identifier field in the RADIUS 201 packet header. Similarly the Code field in the attribute, if it is 202 non-zero, MUST be used in lieu of the Code field in the RADIUS packet 203 header. 205 When the "Identifier Attribute" is used to carry the Identifier 206 field, for better debugging it is RECOMMENDED that 255 be used in the 207 Identifier field of the RADIUS packet header. Similarly it is 208 RECOMMENDED that 255 be used in the Code field of the RADIUS packet 209 header when the attribute is used to carry the Code field as well. 211 To simplify implementation, it is RECOMMENDED that the numbers 256 212 and larger be used as the "Identifier" in the "Identifier Attribute". 214 In response to a request from a client, the server SHOULD format the 215 Identifier field in the same way as in the request, i.e., using 216 either the Identifier field in the RADIUS packet header or the one in 217 the "Identifier Attribute". 219 3. IANA Considerations 221 A new attribute ("Identifier Attribute") is defined for the RADIUS 222 protocol. The type value [RFC3575] needs to be assigned using the 223 assignment rules in section 10.3 of [RFC6929]. 225 4. Security Considerations 227 This document defines a new RADIUS attribute, which does not affect 228 the security considerations of the RADIUS protocol [RFC2865]. 230 The new RADIUS attribute and the procedures described in this 231 document helps eliminate the need for "parallel connections" between 232 a RADIUS client and a server due to the limitation with the 233 "Identifier" field. Thus the resource utilization (such as the 234 number of UDP/TCP ports) on a RADIUS device is expected to be reduced 235 significantly in large scale deployment. 237 5. Acknowledgments 239 TBD 241 6. References 243 6.1. Normative References 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 251 "Remote Authentication Dial In User Service (RADIUS)", 252 RFC 2865, June 2000. 254 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote 255 Authentication Dial In User Service)", RFC 3575, July 256 2003. 258 6.2. Informative References 260 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization 261 and Accounting (AAA) Transport Profile", RFC 3539, June 262 2003. 264 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. 266 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote 267 Authentication Dial In User Service (RADIUS) Protocol", 268 RFC 5997, August 2010. 270 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 271 Service (RADIUS) Protocol Extensions", RFC 6929, April 272 2013. 274 7. Authors' Addresses 276 Enke Chen 277 Cisco Systems 278 560 McCarthy Blvd. 279 Milpitas, CA 95035 280 USA 282 Email: enkechen@cisco.com 284 Naiming Shen 285 Cisco Systems 286 560 McCarthy Blvd. 287 Milpitas, CA 95035 288 USA 290 Email: naiming@cisco.com