[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 37: Merging of Filter Attributes
Per the team design meeting discussion on Jan. 4 2005, issue 37 was
dicussed with the tentative conclusion that Filter-ID and
NAS-Filter-Rule attributes should not appear in the same RADIUS message.
The primary reason is the lack of any simple methods to reconcile
differences that may arise when both are present. One may attribute may
say 'permit' while the other says 'deny'.
Suggested addition to description of section 2.7 NAS-Filter Rule would
be:
"Filter-ID and NAS-Filter-Rule both define how filters are to be applied
in the NAS. They both should not appear in the same message and only one
of them should be processed. If Filter-ID is present, it should take
precedence. Furthermore, multiple Filter-ID attributes may appear in the
same Radius message. It is unclear how implementations should process
these multiple attributes. Some implementation may append them to one
another; others may select only a single attribute to process. This
document recommends that all recognized Filter-ID attributes be appended
to one another in the order they appear in the message."
Cheers,
MS
-----Original Message-----
From: Congdon, Paul T (ProCurve)
Sent: Tuesday, December 14, 2004 3:08 PM
To: 'Bernard Aboba'; radiusext@ops.ietf.org
Subject: RE: Issue 37: Merging of Filter Attributes
I agree that if both of these attributes appear in the packet, they
should append one another. Given that order is important (as seen in
Issue 38), why wouldn't we want to indicate that a NAS-Filter-Rule can
also pre-pend the Filter-ID if it appears before the Filter-ID? It
seems kind of limiting to only allow NAS-Filter-Rule to follow the
Filter-ID.
Consider the following text...
"If both Filter-ID and NAS-Filter-Rule attributes are included within an
Access-Request or Access-Accept packet, the filters are appended to one
another. If the filter specified by the NAS-Filter-Rule attribute
appears after the filter list specified by the Filter-ID attribute, the
filter is considered to be appended to the end of the filter list. If
the filter specified by the NAS-Filter-Rule attribute appears before the
filter list specified by the Filter-ID attribute, the filter is
pre-pended to the filter list.
As a result, if either of the filters specify that a packet is to be
discarded, then the filter(s) specified by the other attribute can have
no effect on the processing of that packet."
Paul
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Monday, December 13, 2004 6:46 PM
> To: radiusext@ops.ietf.org
> Subject: Issue 37: Merging of Filter Attributes
>
> Issue 37: Merging of Filter Attributes Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com Date first
> submitted: December 13, 2004
> Reference:
> Document: Congdon-02
> Comment type: T
> Priority: S
> Section: 2.7
> Rationale/Explanation of issue:
> Section 2.7 does not state what happens if both Filter-ID and
> NAS-Filter-Rule attributes are included in an Access-Accept.
> How are the filters merged?
>
> Suggest the addition of the following text:
>
> "If both Filter-ID and NAS-Filter-Rule attributes are included within
> an Access-Request or Access-Accept packet, the filter specified by the
> NAS-Filter-Rule attribute is considered to be appended to the end of
> the filter list specified by the Filter-ID attribute.
>
> As a result, if the Filter-ID attribute specifies that a packet is to
> be discarded, then the filter specified by NAS-Filter-Rule can have no
> effect on the processing of that packet, since it will have already
> been discarded prior to examination by the filter specified in
> NAS-Filter-Rule."
>
>
> --
> 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/>