Subject: [Dime] FW: Inclusion of Filter-Id and NAS-Filter-Rule AVPs

From: <[email-masked]>
Date: Thu, 23 Nov 2006 10:16:06 +0200

The RADEXT WG currently has the RADIUS Filter Rule document in WG last
all:
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-05.txt

One of the questions that has arisen is how a NAS should treat an
Access-Accept that contains both a Filter-Id attribute and a
NAS-Filter-Rule attribute. 

Currently Section 2 states:

      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 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.

RFC 4005 Section 6.7 states the following with respect to the Filter-Id
AVP: 

   In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter-
   Rule AVP be used instead.

However, since this is a recommendation, it appears possible that an RFC
4005 implementation could send a NAS-Filter-Rule AVP along with a
Filter-Id AVP.  Based on the Section 2 text above, such a message would
not be translatable to an equivalent RADIUS packet. 

Some questions:

a. Does the DIME WG have an opinion on the appropriate normative
language for the Section 2 text above?  For example, is the "MUST NOT"
too strict? 

b. Is there a situation in which both the NAS-Filter-Rule and Filter-Id
AVPs will need to be sent in a Diameter message?

c. If such a situation exists, how is a NAS to interpret such a message?

Does one AVP take precedence?  Or are the AVPs combined somehow? 

-----------------------------------------
To: Bernard Aboba
Subject: RE: Issue on filter-rules-01
From: David Nelson <[email-masked]>
Date: Sat, 11 Nov 2006 10:42:30 -0500

I think it ought to be MUST NOT.  I think the Diameter specification is
defective in that it allows both kinds of filtering attributes, but
fails to specify how to correctly apply them (i.e. a precedence order)
so as to allow interoperability.  I recommend that we not compound that
error in this draft.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Nov 2006 10:34:50 +0200

Comments inline..

> AVPs will need to be sent in a Diameter message?

I would assume that some inbound proxy could always add Filter-Id for 
admin domain internal default rules (as RFC4005 would allow this). This 
has been thought as a use case in some circumstances.

> c. If such a situation exists, how is a NAS to interpret such a message?

I would assume (again) that Filter-Id rules get applied first and then 
'patched' with NAS-Filter-Rule. But given the fact this has not been 
defined in RFC4005 all this is just assuming ;-)

> Does one AVP take precedence?  Or are the AVPs combined somehow? 

/Jouni