idnits 2.17.1 draft-ietf-radext-filter-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 351. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Note 1' is mentioned on line 188, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) == Outdated reference: A later version (-03) exists of draft-ietf-radext-filter-rules-01 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul Congdon 3 INTERNET-DRAFT Mauricio Sanchez 4 Category: Proposed Standard Hewlett-Packard Company 5 Bernard Aboba 6 7 November 2006 Microsoft Corporation 8 RADIUS Filter Rule Attribute 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt. 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 May 10, 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2006). All rights reserved. 37 Abstract 39 This document defines the NAS-Filter-Rule attribute within the Remote 40 Authentication Dial In User Service (RADIUS). This attribute is 41 based on the Diameter NAS-Filter-Rule AVP described in RFC 4005. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Terminology ..................................... 3 47 1.2 Requirements Language ........................... 3 48 1.3 Attribute Interpretation ........................ 3 49 2. NAS-Filter-Rule Attribute ............................. 4 50 3. Table of Attributes ................................... 5 51 4. Diameter Considerations ............................... 5 52 5. IANA Considerations ................................... 6 53 6. Security Considerations ............................... 6 54 7. References ............................................ 6 55 7.1 Normative References ............................ 6 56 7.2 Informative References .......................... 7 57 ACKNOWLEDGMENTS .............................................. 7 58 AUTHORS' ADDRESSES ........................................... 8 59 Intellectual Property Statement............................... 9 60 Disclaimer of Validity........................................ 9 61 Full Copyright Statement ..................................... 9 62 1. Introduction 64 This document defines the NAS-Filter-Rule attribute within the Remote 65 Authentication Dialin User Service (RADIUS) which has the same 66 functionality as the Diameter NAS-Filter-Rule AVP (400) defined in 67 [RFC4005] Section 6.6. This attribute may prove useful for 68 provisioning of filter rules. 70 While [RFC2865] Section 5.11 defines the Filter-Id attribute (11), 71 this requires that the NAS be pre-populated with the desired filters. 72 However, in situations where the server operator does not know which 73 filters have been pre-populated, it useful to specify filter rules 74 explicitly. 76 1.1. Terminology 78 This document uses the following terms: 80 Network Access Server (NAS) 81 A device that provides an access service for a user to a network. 83 RADIUS server 84 A RADIUS authentication server is an entity that provides an 85 authentication service to a NAS. 87 RADIUS proxy 88 A RADIUS proxy acts as an authentication server to the NAS, and a 89 RADIUS client to the RADIUS server. 91 1.2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 1.3. Attribute Interpretation 99 If a NAS conforming to this specification receives an Access-Accept 100 packet containing a NAS-Filter-Rule attribute which it cannot apply, 101 it MUST act as though it had received an Access-Reject. [RFC3576] 102 requires that a NAS receiving a Change of Authorization Request 103 (CoA-Request) reply with a CoA-NAK if the Request contains an 104 unsupported attribute. It is RECOMMENDED that an Error-Cause 105 attribute with value set to "Unsupported Attribute" (401) be included 106 in the CoA-NAK. As noted in [RFC3576], authorization changes are 107 atomic so that this situation does not result in session termination 108 and the pre-existing configuration remains unchanged. As a result, 109 no accounting packets should be generated as a result of the CoA- 110 Request. 112 2. NAS-Filter-Rule Attribute 114 Description 116 This attribute indicates filter rules to be applied for this user. 117 Zero or more NAS-Filter-Rule attributes MAY be sent in Access- 118 Accept, CoA-Request, or Accounting-Request packets. 120 The NAS-Filter-Rule attribute is not intended to be used 121 concurrently with any other filter rule attribute, including 122 Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST 123 NOT appear in the same RADIUS packet. If a Filter-Id or NAS- 124 Traffic-Rule attribute is present, then implementations of this 125 specification MUST silently discard NAS-Filter-Rule attributes, if 126 present. 128 Where multiple NAS-Filter-Rule attributes are included in a RADIUS 129 packet, the String field of the attributes are to be concatenated 130 to form a set of filter rules. As noted in [RFC2865] Section 2.3, 131 "the forwarding server MUST NOT change the order of any attributes 132 of the same type", so that RADIUS proxies will not reorder NAS- 133 Filter-Rule attributes. 135 A summary of the NAS-Filter-Rule Attribute format is shown below. 136 The fields are transmitted from left to right. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type | Length | String... 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Type 146 TBD 148 Length 150 >=3 152 String 154 The String field is one or more octets. It contains filter rules 155 in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with 156 individual filter rules separated by a NUL (0x00). A NAS-Filter- 157 Rule attribute may contain a partial rule, one rule, or more than 158 one rule. Filter rules may be continued across attribute 159 boundaries, so implementations cannot assume that individual 160 filter rules begin or end on attribute boundaries. 162 The set of NAS-Filter-Rule attributes SHOULD be created by 163 concatenating the individual filter rules, separated by a NUL 164 (0x00) octet. The resulting data should be split on 253 byte 165 boundaries to obtain a set of NAS-Filter-Rule attributes. On 166 reception, the individual filter rules are determined by 167 concatenating the contents of all NAS-Filter-Rule attributes, and 168 then splitting individual filter rules with the the NUL octet 169 (0x00) as a delimeter. 171 3. Table of Attributes 173 The following table provides a guide to which attributes may be found 174 in which kinds of packets, and in what quantity. 176 Access- Access- Access- Access- CoA- Acct- 177 Request Accept Reject Challenge Req Req # Attribute 178 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule [Note 1] 180 The following table defines the meaning of the above table entries. 182 0 This attribute MUST NOT be present in the packet. 183 0+ Zero or more instances of this attribute MAY be 184 present in the packet. 185 0-1 Zero or one instance of this attribute MAY be 186 present in the packet. 188 [Note 1]: NAS-Filter-Rule is precluded from appearing in a packet if a 189 Filter-Id or NAS-Traffic-Rule attribute is present. 191 4. Diameter Considerations 193 [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the 194 same functionality as the RADIUS NAS-Filter-Rule attribute. In order 195 to support interoperability, Diameter/RADIUS gateways will need to be 196 configured to translate RADIUS attribute TBD to Diameter AVP 400 and 197 vice-versa. 199 When translating Diameter NAS-Filter-Rule AVPs to RADIUS NAS-Filter- 200 Rule attributes, the set of NAS-Filter-Rule attributes is created by 201 concatenating the individual filter rules, separated by a NUL octet. 202 The resulting data SHOULD then be split on 253 byte boundaries. 204 When translating RADIUS NAS-Filter-Rule attributes to Diameter NAS- 205 Filter-Rule AVPs, the individual rules are determined by 206 concatenating the contents of all NAS-Filter-Rule attributes, and 207 then splitting individual filter rules with the NUL octet as a 208 delimeter. Each rule is then encoded as a single Diameter NAS- 209 Filter-Rule AVP. 211 Note that a translated Diameter message can be larger than the 212 maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway 213 receives a Diameter message containing a NAS-Filter-Rule AVP that is 214 too large to fit into a RADIUS packet, the Diameter/RADIUS gateway 215 will respond to the originating Diameter peer with the 216 DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP 217 containing the NAS-Filter-Rule AVP. Since repairing the error will 218 probably require re-working the filter rules, the originating peer 219 should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error 220 and a Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal 221 error. 223 5. IANA Considerations 225 This specification does not create any new registries. 227 This document uses the RADIUS [RFC2865] namespace, see 228 . Allocation of one 229 update for the section "RADIUS Attribute Types" is requested. The 230 RADIUS attribute for which a value is requested is: 232 TBD - NAS-Filter-Rule 234 6. Security Considerations 236 This specification describes the use of RADIUS for purposes of 237 authentication, authorization and accounting. Threats and security 238 issues for this application are described in [RFC3579] and [RFC3580]; 239 security issues encountered in roaming are described in [RFC2607]. 241 This document specifies a new attribute that can be included in 242 existing RADIUS packets, which are protected as described in 243 [RFC3579] and [RFC3576]. See those documents for a more detailed 244 description. 246 A NAS-Filter-Rule attribute sent by a RADIUS server may not be 247 understood by the NAS which receives it. A legacy NAS not compliant 248 with this specification may silently discard the NAS-Filter-Rule 249 attribute while permitting the user to access the network. This can 250 lead to users improperly receiving unfiltered access to the network. 251 As a result, the NAS-Filter-Rule attribute SHOULD only be sent to a 252 NAS that is known to support it. 254 7. References 256 7.1. Normative references 258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 259 Requirement Levels", RFC 2119, March, 1997. 261 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 262 Authentication Dial In User Service (RADIUS)", RFC 2865, June 263 2000. 265 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 266 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 268 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 269 Network Access Server Application", RFC 4005, August 2005. 271 7.2. Informative references 273 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 274 Implementation in Roaming", RFC 2607, June 1999. 276 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 277 "Dynamic Authorization Extensions to Remote Authentication 278 Dial In User Service (RADIUS)", RFC 3576, July 2003. 280 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 281 Authentication Protocol (EAP)", RFC 3579, September 2003. 283 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 284 802.1X Remote Authentication Dial In User Service (RADIUS) 285 Usage Guidelines", RFC3580, September 2003. 287 [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, 288 "RADIUS Attributes for Filtering and Redirection", Internet 289 draft (work in progress), draft-ietf-radext-filter- 290 rules-01.txt, June 2006. 292 Acknowledgments 294 The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg 295 Weber, Pasi Eronen and David Nelson for contributions to this 296 document. 298 Authors' Addresses 300 Paul Congdon 301 Hewlett Packard Company 302 HP ProCurve Networking 303 8000 Foothills Blvd, M/S 5662 304 Roseville, CA 95747 306 EMail: paul.congdon@hp.com 307 Phone: +1 916 785 5753 308 Fax: +1 916 785 8478 310 Mauricio Sanchez 311 Hewlett Packard Company 312 HP ProCurve Networking 313 8000 Foothills Blvd, M/S 5559 314 Roseville, CA 95747 316 EMail: mauricio.sanchez@hp.com 317 Phone: +1 916 785 1910 318 Fax: +1 916 785 1815 320 Bernard Aboba 321 Microsoft Corporation 322 One Microsoft Way 323 Redmond, WA 98052 325 EMail: bernarda@microsoft.com 326 Phone: +1 425 706 6605 327 Fax: +1 425 936 7329 329 Intellectual Property Statement 331 The IETF takes no position regarding the validity or scope of any 332 Intellectual Property Rights or other rights that might be claimed to 333 pertain to the implementation or use of the technology described in 334 this document or the extent to which any license under such rights 335 might or might not be available; nor does it represent that it has 336 made any independent effort to identify any such rights. Information 337 on the procedures with respect to rights in RFC documents can be 338 found in BCP 78 and BCP 79. 340 Copies of IPR disclosures made to the IETF Secretariat and any 341 assurances of licenses to be made available, or the result of an 342 attempt made to obtain a general license or permission for the use of 343 such proprietary rights by implementers or users of this 344 specification can be obtained from the IETF on-line IPR repository at 345 http://www.ietf.org/ipr. 347 The IETF invites any interested party to bring to its attention any 348 copyrights, patents or patent applications, or other proprietary 349 rights that may cover technology that may be required to implement 350 this standard. Please address the information to the IETF at ietf- 351 ipr@ietf.org. 353 Disclaimer of Validity 355 This document and the information contained herein are provided on an 356 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 357 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 358 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 359 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 360 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 361 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 363 Copyright Statement 365 Copyright (C) The IETF Trust (2006). This document is subject to the 366 rights, licenses and restrictions contained in BCP 78, and except as 367 set forth therein, the authors retain all their rights. 369 Acknowledgment 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society. 374 Open issues 376 Open issues relating to this specification are tracked on the 377 following web site: 379 http://www.drizzle.com/~aboba/RADEXT/