--- 1/draft-ietf-radext-filter-03.txt 2006-10-25 23:13:30.000000000 +0200 +++ 2/draft-ietf-radext-filter-04.txt 2006-10-25 23:13:30.000000000 +0200 @@ -1,16 +1,16 @@ Network Working Group Paul Congdon INTERNET-DRAFT Mauricio Sanchez Category: Proposed Standard Hewlett-Packard Company - Bernard Aboba -4 October 2006 Microsoft Corporation + Bernard Aboba +22 October 2006 Microsoft Corporation RADIUS Filter Rule Attribute By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -44,22 +44,22 @@ 1. Introduction .......................................... 3 1.1 Terminology ..................................... 3 1.2 Requirements Language ........................... 3 1.3 Attribute Interpretation ........................ 3 2. NAS-Filter-Rule Attribute ............................. 4 3. Table of Attributes ................................... 5 4. Diameter Considerations ............................... 5 5. IANA Considerations ................................... 6 6. Security Considerations ............................... 6 -7. References ............................................ 7 - 7.1 Normative References ............................ 7 +7. References ............................................ 6 + 7.1 Normative References ............................ 6 7.2 Informative References .......................... 7 ACKNOWLEDGMENTS .............................................. 7 AUTHORS' ADDRESSES ........................................... 8 Intellectual Property Statement............................... 9 Disclaimer of Validity........................................ 9 Full Copyright Statement ..................................... 9 1. Introduction This document defines the NAS-Filter-Rule attribute within the Remote @@ -112,82 +112,68 @@ 2. NAS-Filter-Rule Attribute Description This attribute indicates filter rules to be applied for this user. Zero or more NAS-Filter-Rule attributes MAY be sent in Access- Accept, CoA-Request, or Accounting-Request packets. The NAS-Filter-Rule attribute is not intended to be used concurrently with any other filter rule attribute, including - Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and - SHOULD NOT appear in the same RADIUS packet. If a Filter-Id - attribute is present, then implementations of this specification - MUST silently discard NAS-Filter-Rule attributes, if present. + Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST + NOT appear in the same RADIUS packet. If a Filter-Id or NAS- + Traffic-Rule attribute is present, then implementations of this + specification MUST silently discard NAS-Filter-Rule attributes, if + present. - Where adjacent NAS-Filter-Rule attributes with the same non-zero - Tag field value are included in a RADIUS packet, the String field - of the attributes are to be concatenated to form a single filter. - As noted in [RFC2865] Section 2.3, "the forwarding server MUST NOT - change the order of any attributes of the same type", so that - RADIUS proxies will not reorder NAS-Filter-Rule attributes. + Where multiple NAS-Filter-Rule attributes are included in a RADIUS + packet, the String field of the attributes are to be concatenated + to form a set of filter rules. As noted in [RFC2865] Section 2.3, + "the forwarding server MUST NOT change the order of any attributes + of the same type", so that RADIUS proxies will not reorder NAS- + Filter-Rule attributes. A summary of the NAS-Filter-Rule Attribute format is shown below. The fields are transmitted from left to right. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Tag | String... + | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length - >=4 - - Tag - - The Tag field is used to identify the filter rule that is - represented; the length of the Tag field is one octet and it MUST - always be present. - - Where a single filter rule is less than or equal to 252 octets in - length, it MUST be encoded with a Tag field value of zero (0) and - MUST NOT be split between multiple NAS-Filter-Rule attributes. On - receipt, attributes with a Tag field value of zero (0) MUST NOT be - concatenated to form a single filter rule. - - Where a single filter rule exceeds 252 octets in length, the rule - MUST be encoded across multiple NAS-Filter-Rule attributes, each - with the same Tag value which MUST be in the range 0x01 - 0x3F. - - NAS-Filter-Rule attributes comprising a single filter rule MUST be - sent consecutively, without intervening attributes with another - Tag field value. The Tag field value of 0xFF is reserved and NAS- - Filter-Rule attributes containing this Tag field value should be - ignored upon receipt. - - Adjacent filter rules exceeding 252 octets in length MUST be - encoded with different non-zero Tag field values; however, the Tag - field value used for a given filter rule need not be unique within - the entire RADIUS packet. + >=3 String The String field is one or more octets. It contains filter rules - in the IPFilterRule syntax defined in [RFC3588] Section 4.3. A - robust implementation SHOULD support the field as undistinguished - octets. + in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with + individual filter rules separated by a NUL (0x00). A NAS-Filter- + Rule attribute may contain a partial rule, one rule, or more than + one rule. Filter rules may be continued across attribute + boundaries, so implementations cannot assume that individual + filter rules begin or end on attribute boundaries. + + The set of NAS-Filter-Rule attributes SHOULD be created by + concatenating the individual filter rules, separated by a NUL + (0x00) octet. The resulting data should be split on 253 byte + boundaries to obtain a set of NAS-Filter-Rule attributes. On + reception, the individual filter rules SHOULD be determined by + concatenating the contents of all NAS-Filter-Rule attributes, and + then splitting individual filter rules with the the NUL octet + (0x00) as a delimeter. 3. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Access- Access- Access- Access- CoA- Acct- Request Accept Reject Challenge Req Req # Attribute 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule @@ -198,30 +184,30 @@ present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet. 4. Diameter Considerations [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the same functionality as the RADIUS NAS-Filter-Rule attribute. In order to support interoperability, Diameter/RADIUS gateways will need to be configured to translate RADIUS attribute TBD to Diameter AVP 400 and - vice-versa. Where a Diameter NAS-Filter-Rule AVP contains a filter - rule larger than 252 octets, Diameter/RADIUS gateways translate the - AVP to multiple RADIUS NAS-Filter-Rule attributes, each with the same - Tag field value not equal to '0' (0x30). Similarly, when multiple - RADIUS NAS-Filter-Rule attributes are received with the same Tag - field value not equal to '0' (0x30), the String fields of the - attributes are concatenated together and encoded as the value in a - single Diameter NAS-Filter-Rule AVP. RADIUS NAS-Filter-Rule - attributes with a Tag field of '0' (0x30) are encoded as distinct - Diameter NAS-Filter-Rule AVPs. + vice-versa. + + Where a Diameter NAS-Filter-Rule AVP contains a filter rule larger + than 253 octets, Diameter/RADIUS gateways translate the AVP to + multiple RADIUS NAS-Filter-Rule attributes, with each filter rule + separated by a NUL octet (0x00). When multiple RADIUS NAS-Filter- + Rule attributes are received, the String fields of the attributes are + concatenated and the individual rules are separated out based on the + use of the NUL octet as a delimiter. Each rule is then encoded as a + single Diameter NAS-Filter-Rule AVP. Note that a translated Diameter message can be larger than the maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway receives a Diameter message containing a NAS-Filter-Rule AVP that is too large to fit into a RADIUS packet, the Diameter/RADIUS gateway will respond to the originating Diameter peer with the DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP. Since repairing the error will probably require re-working the filter rules, the originating peer should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error @@ -266,23 +252,20 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. -[RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629, - November 2003. - [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. 7.2. Informative references [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication @@ -293,22 +276,23 @@ [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC3580, September 2003. [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, "Filter Attributes", Internet draft (work in progress), draft- ietf-radext-filter-rules-00.txt, February 2006. Acknowledgments - The authors would like to acknowledge Greg Weber of Cisco and David - Nelson of Enterasys. + + The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg + Weber and David Nelson for contributions to this document. Authors' Addresses Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 EMail: paul.congdon@hp.com