RE: Issue 102: NAS/QoS Filter Rule

[<Pasi.Eronen@nokia.com>]

paul.congdon@hp.com wrote:

> [pc] We can insert this if we can complete the TODO parts
> above.  Do we insert it before the current description or
> completely replace what is there with just the ABNF?  I'm
> assuming this would be inserted in front of the current
> descriptions and we would leave the existing text with fixes
> discussed below.  Can you help complete the TODOs or provide a
> good reference guide on ABNF somewhere?

Whatever we do, we should avoid having multiple descriptions that 
are in conflict with each other (currently we have two, and they 
don't completely match).

ABNF is described in RFC 2234.

> 4) Description of "ipno/bits" says "the IP number MUST NOT have
> bits set beyond the mask", but the example given, "1.2.3.4/24",
> does not follow this. Suggested change: use 192.0.2.0/24 as the
> example.
> 
> [pc] accept suggestion, maybe change the first 0 to something 
> else to further disambiguate.

No, we should use 192.0.2.0/24 since it's the block reserved
for documentation use (RFC 3330).

> 8) The document allows an IP tunnel rule with direction "out",
> but does not describe what such a rule means (the description
> seems to apply only to rules with direction "in")
> 
> [pc] Avi has written a great description of how the tunnel facility
> works and how the directions apply.  I've attached a version of this
> document - perhaps Avi has something more recent?  We probably want to
> consider how parts of his document are incorporated into an annex or
> some part of the document to make this clear.

Thanks, this explained things (but something along those lines
needs to be included in the document).

> 10) The document should explain why different types of rules
> must be given in exactly that order. Placing L2 rules before IP
> is understandable, but for some of the other cases it's not
> totally obvious why other orderings need to be forbidden.
> 
> [pc] We had considerable discussion about this early on in the
> document development.  If my memory serves me correctly, we
> decided upon this order to maximize interoperability and to
> address the fact that it didn't make sense to filter out
> packets before putting them into the tunnel.  Perhaps others
> can recall more detail - sorry.

Well, I think it could make sense in theory (e.g., first filter out
some bad traffic using "deny" rules, then put all the rest to a
tunnel)... but I'm OK with leaving in these restrictions.

> 13) If the NAS just concatenates all the NAS-Filter-Rule (or
> QoS-Filter-Rule) attributes together to overcome the 255-byte
> attribute length limit, then boundaries between individual
> rules are lost. This is not necessarily a big problem, as it
> looks like the syntax can be unambiguously parsed anyway, but
> should be mentioned explicitly (alternatively, we could delimit
> the individual rules somehow).
> 
> [pc] yes, this should not be a problem and implementations will
> split the string in different ways, but if they are following
> the rules of fragmentation and reassembly properly there is no
> issue.  We really don't need to say anything here as this is
> part of standard attribute parsing.  No action proposed.

There would be an issue if the grammar allowed ambiguous parsings.
For instance, if we had ICMP types "no" and "notunnel" (which we
don't), the following string could be parsed in two different ways
(where exactly does the first rule end and second rule start?)

  "deny in 1 from assigned to any icmptypes source quench,notunnel 
  permit in ip from assigned to any"

I don't think we have any such cases currently (running the grammar
through some kind of parser generator tool might verify this...), 
but it means that extending the syntax later has to be done with 
great care.

It also means that saying "A NAS that is unable to interpret or apply
a deny rule MUST terminate the session" is probably a bad idea, since
it seems to imply that ignoring a "permit" rule the NAS cannot
interpret is allowed... but if the NAS cannot interpret the rule, 
it cannot really know where one rule ends and the next rule starts.

Best regards,
Pasi

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