Re-mailing last email on issue 169 where discussion went cold. Proposed resolution in email. MS -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (ProCurve) Sent: Thursday, June 22, 2006 2:59 PM To: radiusext@ops.ietf.org Cc: Greg Weber (gdweber) Subject: Issue 169: Handling Unparsable NAS-Filter-Rule Greg pointed out... >Issue 169: Handling Unparsable NAS-Filter-Rule >Submitter names: Greg Weber >Submitter email address: gdweber@cisco.com >Date first submitted: February 2, 2006 >Reference: http://ops.ietf.org/lists/radiusext/2006/msg00104.html >Document: IEEE 802-01 >Comment type: Technical >Priority: S >Section: 1.4, 6 >Rationale/Explanation of issue: >The NAS-Filter-Rule represents a *lot* of functionality. >I think we can expect lots of variability in NASes which >support various parts, e.g. maybe all the filtering, but >not HTTP redirection, etc. I think we maybe need to be >clearer on what is supposed to happen when the NAS gets >a CoA-Request or Access-Request containing directives >that it cannot parse or apply. In particular, in Section >1.4 "Attribute Interpretation", I see text indicating that >non-understood attributes result in Access-Rejects. But, >in Section 6 "Security Considerations", I see text like: >"...a NAS could be configured to ... not accept any >redirection rules if it is known they are not used in >this environment." These would seem to be contradictory. > >Requested change: >Need clarification on the intent. I hear you on this issue. How about the change of section 1.4 to read from: "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject." To "If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject. A NAS may be incapable of applying an attribute due to functional limitations of the NAS or security reasons (as described in section 7 - Security Considerations)." Does this help? MS -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect ProCurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5557 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com --------------------------------------------
Attachment:
smime.p7s
Description: S/MIME cryptographic signature