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

Ondrej Zajicek santiago at crfreenet.org
Sat Apr 3 19:57:26 CEST 2021


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.


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


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

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


More information about the Bird-users mailing list