For context, I'm currently writing a birdc-flowspec -> XDP parser/transpiler, so exact formal grammar and behavior is
important :). You can find it at https://github.com/TheBlueMatt/flowspec-xdp.
It currently only supports drop/pass, however, and doesn't parse the action communities as it doesn't appear BIRD
supports them? The RFC indicates extended community types in the 0x800X range, but BIRD appears to only support rt/ro. I
may be missing something entirely obvious here, though.
Matt
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.
Right, so to clarify, I should treat , and || as the same, match them first, followed by &&, then .. and relational
operators.
There are no examples that use true or false, though hopefully they're pretty
obvious.
I've updated the parse_ast function in genrules.py in the above repo to match the above, with some tests, hopefully its
right now.
The documentation does not
mention that bitmask-match and fragmentation-type syntax can use logical
operators.
Hmm, but bird has no problem with this -
route flow4 { fragment is_fragment, last_fragment; tcp flags 0x04/0x0f, 0x01/0x0f
&& 0x05/0x0f; };
Should that be disallowed, or is it just missing in the docs?
1) Based on the grouping in the examples, I'd think && and || are parsed
first, followed by , and .. ie 1 && 2,3 means 1 AND (two OR three) not (1
AND 2) or 3. Same would apply for fragmentation-type, which makes the
spacing in the flow4 example somewhat confusing, though obviously it doesn't
change the logic given its all ORs.
The spacing is confusing, we should add spaces after commas.
2) What are the full list of possible operators?
Described above
3) I can make a pretty good guess as to what each operator means, but it
doesn't seem to be written down anywhere.
Separately, the documentation seems to indicate dscp applies for both IPv4
flowspec as well as IPv6 flowspec as-is, however this is somewhat confusing
- is DSCP intended to match on v4 ECN bits as well, or is the expected
length of DSCP simply 8 bits instead for v6 and matched against the traffic
class?
IMHO it should match 6 bits of DSCP in both IPv4 and IPv6 (replacing TOS
byte in IPv4 and Traffic Class byte in IPv6). But the specification of
IPv6 flowspec does not relly cover this.
Heh, I guess I should read the RFCs more.
Finally, and I suppose this is an RFC question not a BIRD question, how does
the fragment field interact with the next header field in v6 - I assume a
router is expected to parse a fragment header before checking next header,
irrespective of the fragment bits (unless they require all bits unset)?
Not sure.
Heh, I guess I should read the RFCs more.
