On 4/3/21 13:57, Ondrej Zajicek wrote:
On Fri, Apr 02, 2021 at 03:30:17PM -0400, Matt Corallo wrote:
The match classifiers for flowspec (numbers-match bitmask-match and
fragmentation-type) don't appear to be exactly specified in the
documentation anywhere. eg

Hi

It is described in the article in 'Flowspec' section (although not using
formal grammar):

   Numbers matching is a matching sequence of numbers and ranges separated
   by a commas (,) (e.g. 10,20,30). Ranges can be written using double dots
   .. notation (e.g. 80..90,120..124). An alternative notation are sequence
   of one or more pairs of relational operators and values separated by
   logical operators && or ||. Allowed relational operators are =, !=, <,
   <=, >, >=, true and false.

I am not sure if you considered this insufficient or missed it. The syntax
is generally direct match to flowspec binary format and it is essentially
DNF where || and ',' are the same. We probably should add some formal
grammar for this as it may be a bit confusing. The documentation does not
mention that bitmask-match and fragmentation-type syntax can use logical
operators.

This appears to be violated for "tcp flags" (and possibly others). I have a rule added via one BIRD (2.0.7) instance with "tcp flags 0x02/0x17" (ie TCP-SYN, if I understand the match logic here correctly), but when I `birdc show route table flowspec4 primary all` on the same BIRD instance it shows up as "tcp flags 0x2/0x2,0x0/0x15;". I'm not sure if the flags are being decomposed incorrectly of if the display thereof is incorrect.

Matt

Reply via email to