RE: Issue 102: NAS/QoS Filter Rule

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

On the last point...
 
> > 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

Since these rules govern access policies, it is believed that a strong
hammer is better than simply ignoring things that aren't understood or
implemented.  These should apply equally for permit rules or deny rules.
If the NAS can't interpret the rule, it can't enforce the desired policy
either and still MUST terminate the session, so if it gets lost parsing
things, this rule should also apply. 

I agree that we need to make sure parsing is unambiguous.  I suppose we
need a line feed at the end of each rule and perhaps this needs to be
escaped as well for the tunnel-assignment-ID issue.

Paul
 

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