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

Issue: WGLC comments about NAS/QoS-Filter-Rule



WGLC comments about NAS/QoS-Filter-Rule
Submitter name: Pasi Eronen
Submitter email address: pasi.eronen@nokia.com
Date first submitted: July 14, 2005
Reference: 
Document: draft-ietf-radext-ieee802-00
Comment type: T/E
Priority: 1
Section: 
Rationale/Explanation of issue:

1) Section 3.5 is currently quite difficult to follow since it
mixes L2, IP, tunneling and HTTP redirect rules... It's not
always even clear when some element is just a name for a rule
(like "ipno") and when it's a literal string (like "from").  
So some editing work is needed here. Maybe describing the L2, 
IP filtering, IP tunneling and HTTP rules one-by-one
(instead of mixing their descriptions) would make this more
understandable.

(The IPFilterRule description in RFC3588 isn't nearly as
complicated as this, since it doesn't have the L2, tunneling 
or HTTP rules.)


2) Or would using ABNF be of any help? Here's a first sketch 
(probably buggy..)
       
   rule           =  flush-rule /
                     l2-filter-rule / 
                     ip-filter-rule / 
                     ip-tunnel-rule /
                     http-redirect-rule 

   flush-rule     =  "flush"

   l2-filter-rule =  ("permit" / "deny") " " ("in" / "out" / "inout") 
                     " " l2-filter [" Cnt"]
   l2-filter      =  l2-proto " from " l2-address " to " l2-address
   l2-filter      =/ l2-rmon-str
   l2-proto       =  "l2:ether2" [":0x" 1*4HEXDIG]   
   l2-rmon-str    =  "l2:" 1*DIGIT *("." 1*DIGIT)
   l2-address     =  ["!"] (macaddr / (macaddr "/" mask) / "any")
   macaddr        =  2HEXDIG 5("-" 2HEXDIG)
   mask           =  1*2DIGIT

   ip-filter-rule =  ("permit" / "deny") " " ("in" / "out" / "inout") 
                     " " ip-filter
   ip-filter      =  ("ip" / ip-proto) 
                     " from " ip-address [" " ip-ports]
                     " to " ip-address [" " ip-ports]
                     *(" " ip-option)
   ip-proto       =  1*3DIGIT
   ip-address     =  ["!"] (ipv4-address ["/" bits] / 
                            ipv6-address ["/" bits] /
                            "any" / 
                            "assigned") 
   ipv4-address   = 1*3DIGIT 3("." 1*3DIGIT)
   ipv6-address   = ;; TODO
   bits           =  1*3DIGIT
   ip-ports       =  ip-port *("," ip-port)
   ip-port        =  1*5DIGIT / (1*5DIGIT "-" 1*5DIGIT)

   ip-option      =  "Cnt"
   ip-option      =  "frag"
   ip-option      =/ "ipoptions " ["!"] ipopt *("," ["!"] ipopt)
   ip-option      =/ "tcpoptions " ["!"] tcpopt *("," ["!"] tcpopt)
   ip-option      =/ "established"
   ip-option      =/ "setup"
   ip-option      =/ "tcpflags " ["!"] tcpflag *("," ["!"] tcpflag)
   ip-option      =/ "icmptypes " icmptype *("," icmptype)

   ipopt          =  "ssrr" / "lsrr" / "rr" / "ts"
   tcpopt         =  "mss" / "window" / "sack" / "ts" / "cc"
   tcpflag        =  "fin" / "syn" / "rst" / "psh" / "ack" / "urg"
   icmptype       =  1*3DIGIT
   icmptype       =/ 1*3DIGIT "-" 1*3DIGIT
   icmptype       =/ ;; TODO (names)

   ip-tunnel-rule =  "tunnel " tunnel-id " in " ip-filter
   tunnel-id      =  ;; TODO

   http-redirect-rule =  "redirect " [redir-cnt " "] 
                     redir-url " in " ip-filter
   redir-cnt      =  1*DIGIT
   redir-url      =  ;; TODO

(Ok, maybe this is not so clear either... but at least it's
unambiguous when something is just a rule name and when it's 
a literal string )


3) Example of "macaddr/mask": The example should use some other
width than /24 to make it clearer how the counting works. Also,
the example given is an invalid one, since it does not meet the
"The MAC address MUST NOT have bits set beyond the mask"
requirement. Suggested change: use 00-10-A4-23-00-00/32 as the
example.


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.


5) Description of tunnel_id: according to RFC 2868, there are no
restrictions on the format of the Tunnel-Assignment-ID.
Currently it's not clear if the NAS-Filter-Rule syntax supports
correctly parsing arbitrary IDs (what happens if the ID
includes spaces, for instance?)


6) Near the end of Section 3.5: The "concise syntax statements"
don't exactly match the definitions earlier. I catched
at least these:

- IP rule is missing "[ports]" before "to"
- IP rule is missing "|" after "redirect"
- HTTP redirect rule is missing the "proto" part after the direction
- HTTP redirect rule does not have "[ports]"


7) The document does not seem to describe what HTTP filter rules
are or how they work (HTTP redirect rules are explained, but not
HTTP filter rules).


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")


9) Currently the text says "A flush rule MUST appear before all
other rule types." I first read this to mean that a flush rule
must always be present, but I guess that was not what was
meant. Furthermore, it's not easy to parse the ordering
requirements.

Suggested change: Rewrite that paragraph to "Furthermore, if the
list contains different types of rules, they MUST appear in the
following order: flush rules, base encapsulation filter rules,
IP tunnel rules, HTTP redirect rules, IP filter rules, and HTTP
filter rules."


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.


11) The document should have some examples of NAS filter rules,
preferably showing most of the different features at least once.


12) The document should somewhere describe the differences to
Diameter's NAS-Filter-Rule syntax.


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


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