draft-ietf-radext-filter-04.txt   draft-ietf-radext-filter-05.txt 
Network Working Group Paul Congdon Network Working Group Paul Congdon
INTERNET-DRAFT Mauricio Sanchez INTERNET-DRAFT Mauricio Sanchez
Category: Proposed Standard Hewlett-Packard Company Category: Proposed Standard Hewlett-Packard Company
<draft-ietf-radext-filter-04.txt> Bernard Aboba <draft-ietf-radext-filter-05.txt> Bernard Aboba
22 October 2006 Microsoft Corporation 7 November 2006 Microsoft Corporation
RADIUS Filter Rule Attribute RADIUS Filter Rule Attribute
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 10, 2007. This Internet-Draft will expire on May 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2006. Copyright (C) The IETF Trust (2006). All rights reserved.
Abstract Abstract
This document defines the NAS-Filter-Rule attribute within the Remote This document defines the NAS-Filter-Rule attribute within the Remote
Authentication Dial In User Service (RADIUS), equivalent to the Authentication Dial In User Service (RADIUS). This attribute is
Diameter NAS-Filter-Rule AVP described in RFC 4005. based on the Diameter NAS-Filter-Rule AVP described in RFC 4005.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Terminology ..................................... 3 1.1 Terminology ..................................... 3
1.2 Requirements Language ........................... 3 1.2 Requirements Language ........................... 3
1.3 Attribute Interpretation ........................ 3 1.3 Attribute Interpretation ........................ 3
2. NAS-Filter-Rule Attribute ............................. 4 2. NAS-Filter-Rule Attribute ............................. 4
3. Table of Attributes ................................... 5 3. Table of Attributes ................................... 5
4. Diameter Considerations ............................... 5 4. Diameter Considerations ............................... 5
skipping to change at page 3, line 47 skipping to change at page 3, line 47
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.3. Attribute Interpretation 1.3. Attribute Interpretation
If a NAS conforming to this specification receives an Access-Accept If a NAS conforming to this specification receives an Access-Accept
packet containing a NAS-Filter-Rule attribute which it cannot apply, packet containing a NAS-Filter-Rule attribute which it cannot apply,
it MUST act as though it had received an Access-Reject. [RFC3576] it MUST act as though it had received an Access-Reject. [RFC3576]
requires that a NAS receiving a Change of Authorization Request requires that a NAS receiving a Change of Authorization Request
(CoA-Request) reply with a CoA-NAK if the Request contains an (CoA-Request) reply with a CoA-NAK if the Request contains an
unsupported attribute. It is recommended that an Error-Cause unsupported attribute. It is RECOMMENDED that an Error-Cause
attribute with value set to "Unsupported Attribute" (401) be included attribute with value set to "Unsupported Attribute" (401) be included
in the CoA-NAK. As noted in [RFC3576], authorization changes are in the CoA-NAK. As noted in [RFC3576], authorization changes are
atomic so that this situation does not result in session termination atomic so that this situation does not result in session termination
and the pre-existing configuration remains unchanged. As a result, and the pre-existing configuration remains unchanged. As a result,
no accounting packets should be generated. no accounting packets should be generated as a result of the CoA-
Request.
2. NAS-Filter-Rule Attribute 2. NAS-Filter-Rule Attribute
Description Description
This attribute indicates filter rules to be applied for this user. This attribute indicates filter rules to be applied for this user.
Zero or more NAS-Filter-Rule attributes MAY be sent in Access- Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
Accept, CoA-Request, or Accounting-Request packets. Accept, CoA-Request, or Accounting-Request packets.
The NAS-Filter-Rule attribute is not intended to be used The NAS-Filter-Rule attribute is not intended to be used
skipping to change at page 5, line 10 skipping to change at page 5, line 12
individual filter rules separated by a NUL (0x00). A NAS-Filter- individual filter rules separated by a NUL (0x00). A NAS-Filter-
Rule attribute may contain a partial rule, one rule, or more than Rule attribute may contain a partial rule, one rule, or more than
one rule. Filter rules may be continued across attribute one rule. Filter rules may be continued across attribute
boundaries, so implementations cannot assume that individual boundaries, so implementations cannot assume that individual
filter rules begin or end on attribute boundaries. filter rules begin or end on attribute boundaries.
The set of NAS-Filter-Rule attributes SHOULD be created by The set of NAS-Filter-Rule attributes SHOULD be created by
concatenating the individual filter rules, separated by a NUL concatenating the individual filter rules, separated by a NUL
(0x00) octet. The resulting data should be split on 253 byte (0x00) octet. The resulting data should be split on 253 byte
boundaries to obtain a set of NAS-Filter-Rule attributes. On boundaries to obtain a set of NAS-Filter-Rule attributes. On
reception, the individual filter rules SHOULD be determined by reception, the individual filter rules are determined by
concatenating the contents of all NAS-Filter-Rule attributes, and concatenating the contents of all NAS-Filter-Rule attributes, and
then splitting individual filter rules with the the NUL octet then splitting individual filter rules with the the NUL octet
(0x00) as a delimeter. (0x00) as a delimeter.
3. Table of Attributes 3. Table of Attributes
The following table provides a guide to which attributes may be found The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity. in which kinds of packets, and in what quantity.
Access- Access- Access- Access- CoA- Acct- Access- Access- Access- Access- CoA- Acct-
Request Accept Reject Challenge Req Req # Attribute Request Accept Reject Challenge Req Req # Attribute
0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule 0 0+ 0 0 0+ 0+ TBD NAS-Filter-Rule [Note 1]
The following table defines the meaning of the above table entries. The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in the packet. 0 This attribute MUST NOT be present in the packet.
0+ Zero or more instances of this attribute MAY be 0+ Zero or more instances of this attribute MAY be
present in the packet. present in the packet.
0-1 Zero or one instance of this attribute MAY be 0-1 Zero or one instance of this attribute MAY be
present in the packet. present in the packet.
[Note 1]: NAS-Filter-Rule is precluded from appearing in a packet if a
Filter-Id or NAS-Traffic-Rule attribute is present.
4. Diameter Considerations 4. Diameter Considerations
[RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the [RFC4005] Section 6.6 defines the NAS-Filter-Rule AVP (400) with the
same functionality as the RADIUS NAS-Filter-Rule attribute. In order same functionality as the RADIUS NAS-Filter-Rule attribute. In order
to support interoperability, Diameter/RADIUS gateways will need to be to support interoperability, Diameter/RADIUS gateways will need to be
configured to translate RADIUS attribute TBD to Diameter AVP 400 and configured to translate RADIUS attribute TBD to Diameter AVP 400 and
vice-versa. vice-versa.
Where a Diameter NAS-Filter-Rule AVP contains a filter rule larger When translating Diameter NAS-Filter-Rule AVPs to RADIUS NAS-Filter-
than 253 octets, Diameter/RADIUS gateways translate the AVP to Rule attributes, the set of NAS-Filter-Rule attributes is created by
multiple RADIUS NAS-Filter-Rule attributes, with each filter rule concatenating the individual filter rules, separated by a NUL octet.
separated by a NUL octet (0x00). When multiple RADIUS NAS-Filter- The resulting data SHOULD then be split on 253 byte boundaries.
Rule attributes are received, the String fields of the attributes are
concatenated and the individual rules are separated out based on the When translating RADIUS NAS-Filter-Rule attributes to Diameter NAS-
use of the NUL octet as a delimiter. Each rule is then encoded as a Filter-Rule AVPs, the individual rules are determined by
single Diameter NAS-Filter-Rule AVP. concatenating the contents of all NAS-Filter-Rule attributes, and
then splitting individual filter rules with the NUL octet as a
delimeter. Each rule is then encoded as a single Diameter NAS-
Filter-Rule AVP.
Note that a translated Diameter message can be larger than the Note that a translated Diameter message can be larger than the
maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway maximum RADIUS packet size (4096). Where a Diameter/RADIUS gateway
receives a Diameter message containing a NAS-Filter-Rule AVP that is receives a Diameter message containing a NAS-Filter-Rule AVP that is
too large to fit into a RADIUS packet, the Diameter/RADIUS gateway too large to fit into a RADIUS packet, the Diameter/RADIUS gateway
will respond to the originating Diameter peer with the will respond to the originating Diameter peer with the
DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP DIAMETER_INVALID_AVP_LENGTH error (5014), and with a Failed-AVP AVP
containing the NAS-Filter-Rule AVP. Since repairing the error will containing the NAS-Filter-Rule AVP. Since repairing the error will
probably require re-working the filter rules, the originating peer probably require re-working the filter rules, the originating peer
should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error should treat the combination of a DIAMETER_INVALID_AVP_LENGTH error
skipping to change at page 7, line 32 skipping to change at page 7, line 39
Dial In User Service (RADIUS)", RFC 3576, July 2003. Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE
802.1X Remote Authentication Dial In User Service (RADIUS) 802.1X Remote Authentication Dial In User Service (RADIUS)
Usage Guidelines", RFC3580, September 2003. Usage Guidelines", RFC3580, September 2003.
[Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba, [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F. and B. Aboba,
"Filter Attributes", Internet draft (work in progress), draft- "RADIUS Attributes for Filtering and Redirection", Internet
ietf-radext-filter-rules-00.txt, February 2006. draft (work in progress), draft-ietf-radext-filter-
rules-01.txt, June 2006.
Acknowledgments Acknowledgments
The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg
Weber and David Nelson for contributions to this document. Weber, Pasi Eronen and David Nelson for contributions to this
document.
Authors' Addresses Authors' Addresses
Paul Congdon Paul Congdon
Hewlett Packard Company Hewlett Packard Company
HP ProCurve Networking HP ProCurve Networking
8000 Foothills Blvd, M/S 5662 8000 Foothills Blvd, M/S 5662
Roseville, CA 95747 Roseville, CA 95747
EMail: paul.congdon@hp.com EMail: paul.congdon@hp.com
skipping to change at page 9, line 33 skipping to change at page 9, line 33
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2006). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open issues Open issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
 End of changes. 13 change blocks. 
27 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/