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

Ondrej Zajicek santiago at crfreenet.org
Tue May 18 01:44:39 CEST 2021


On Mon, May 17, 2021 at 01:48:19PM -0400, Matt Corallo wrote:
> 
> 
> 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.

Hi

You are right. My comment above is true for numeric ops, but for bitmask
ops the ',' is the same as '&&', i am not really sure why. This seems
confusing and it is undocumented. But it is consistent with both parser
and formatter. See net_format_flow_num(), net_format_flow_bitmask() and
conf/flowspec.Y for parser grammar.

Parser receives 0x02/0x17, decomposes it to 0x2/0x2 && 0x0/0x15 (as
flowspec allows just all-zero and all-one masks) and that is displayed
(just with ','). We should be probably smarter and compose it back to
0x02/0x17 during display.

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