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