Exact Definition of numbers-match bitmask-match and fragmentation-type

[Matt Corallo]

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.