[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576




I'm fine with leveraging the wording you note below for section 1.4 of the
filter draft.

MS 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Thursday, March 16, 2006 2:28 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Proposed Resolution to Issue 167: Compatibility 
> with RFC 2866 and RFC 3576
> 
> Note the text from the VLAN/Priority document on a similar subject:
> 
> 1.3.  Attribute Interpretation
> 
>    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.
> 
>    Similarly, [RFC3576] requires that a NAS receiving a  CoA-Request
>    containing an unsupported attribute reply with a CoA-NAK.  It is
>    recommended that an Error-Cause attribute with value set to
>    "Unsupported Attribute" (401) be included in the packet.  
> As noted in
>    [RFC3576], authorization changes are atomic so that this situation
>    does not result in session termination and the pre-existing
>    configuration remains unchanged.  As a result, no 
> accounting packets
>    should be generated.
> 
> 
> >From: "Bernard Aboba" <bernard_aboba@hotmail.com>
> >To: radiusext@ops.ietf.org
> >Subject: Proposed Resolution to Issue 167: Compatibility 
> with RFC 2866 
> >and RFC 3576
> >Date: Thu, 16 Mar 2006 14:12:04 -0800
> >
> >The text of Issue 167 is enclosed below.   The proposed 
> resolution is as 
> >follows:
> >
> >In Section 1.4, change:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.  If accounting is enabled on the NAS, it
> >     MUST generate an Accounting-Request(Stop) message upon session
> >     termination.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet
> >     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
> >     accounting is enabled on the NAS, it MUST NOT generate an
> >     Accounting-Request(Stop) message in such instances.
> >
> >To:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet.
> >
> >-------------------------------------------------------------
> ----------
> >------------------------------ Issue 167: Compatibility with 
> RFC 2866 
> >and RFC 3576 Submitter names: Bernard Aboba Submitter email address: 
> >aboba@internaut.com Date first submitted: January 30, 2006
> >Reference:
> >Document: IEEE 802-01
> >Comment type: Technical
> >Priority: S
> >Section: 1.4
> >Rationale/Explanation of issue:
> >
> >Section 1.4 states:
> >
> >  1.4 Attribute Interpretation
> >
> >     Unless otherwise noted in the individual description of an
> >     attribute contained herein, a NAS that conforms to this
> >     specification and receives an Access-Accept message 
> that contains
> >     an attribute from this document that it cannot apply MUST
> >     interpret this though an Access-Reject had been sent and MUST
> >     terminate the session.  If accounting is enabled on the NAS, it
> >     MUST generate an Accounting-Request(Stop) message upon session
> >     termination.
> >
> >     Similarly, if a NAS conforming to this specification and also
> >     conforming to RFC 3576 [RFC3576] receives a CoA message that
> >     contains an attribute from this document that it cannot 
> apply, it
> >     MUST NOT terminate the session and MUST generate a 
> CoA-NAK packet
> >     with ERROR-CAUSE(101) set to "Unsupported Attribute"(401).  If
> >     accounting is enabled on the NAS, it MUST NOT generate an
> >     Accounting-Request(Stop) message in such instances.
> >RFC 2866 does not specify the generation of Accounting Stop messages 
> >resulting from Access-Reject packets.  This document is therefore 
> >requiring RADIUS accounting clients to generate accounting 
> records in 
> >circumstances where they would not otherwise do so.  This raises the 
> >question of why this particular set of attributes would 
> cause a special 
> >case modification to RFC 2866.  Here is what RFC 3576 has to 
> say about 
> >receipt of attributes in a CoA-Request:
> >
> >  If one or more authorization changes specified in a CoA-Request  
> > cannot be carried out, or if one or more attributes or attribute-  
> > values is unsupported, a CoA-NAK MUST be sent.
> >
> >On inclusion of Error-Cause attributes:
> >
> >     It is possible that the NAS cannot honor Disconnect-Request or
> >     CoA-Request messages for some reason.  The Error-Cause Attribute
> >     provides more detail on the cause of the problem.  It MAY be
> >     included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
> >     messages.
> >
> >Since inclusion of an Error-Cause attribute is generally 
> optional, the 
> >second paragraph mandates behavior not required by RFC 3576.
> >
> >
> >
> >--
> >to unsubscribe send a message to radiusext-request@ops.ietf.org with 
> >the word 'unsubscribe' in a single line as the message text body.
> >archive: <http://psg.com/lists/radiusext/>
> 
> 
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature