Exact Definition of numbers-match bitmask-match and fragmentation-type
The match classifiers for flowspec (numbers-match bitmask-match and fragmentation-type) don't appear to be exactly specified in the documentation anywhere. eg 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. 2) What are the full list of possible operators? From the examples there is at least <, <=, >, >=, &&, ||, ",", .., and !. 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? 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)? Thanks, Matt
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@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."
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.
Hi Matt, On Sun, Apr 04, 2021 at 12:18:53PM -0400, Matt Corallo wrote:
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.
Looks interesting.
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.
You can add the exetended communities via generic extended communitiy in bird: bgp_ext_community.add( (generic, 0x80060000, 0x00000000 ) ); the output in birdc will look like: flow4 { dst 203.0.113.53/32; src 198.51.100.10/32; } [S_FLOWSPEC_v4 07:48:34.659] * (200) Type: static univ BGP.ext_community: (generic, 0x80060000, 0x0) HTH, tim -- Tim Weippert http://weiti.org - weiti@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
Hello! On 4/4/21 6:18 PM, Matt Corallo wrote:
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.
Would you benefit from having Python API in BIRD, getting the flowspec rules as proper objects?
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.
I remember coding something around that, anyway I don't remember whether we actually merged it. Will look for that. Maria
Replies to both responses. On 4/5/21 05:04, Maria Matejka wrote:
Hello!
On 4/4/21 6:18 PM, Matt Corallo wrote:
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.
Would you benefit from having Python API in BIRD, getting the flowspec rules as proper objects?
Hmm, probably, I guess? Its not really that hard to parse the birdc output as long as I figure out the exact semantics to convert a X-match string into an AST. Putting in the work to write a whole Python API sounds like more work than its worth, but, hey, if you build it, I'll use it :)
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.
I remember coding something around that, anyway I don't remember whether we actually merged it. Will look for that.
See below from Tim - (generic, X, Y). I do not believe this is documented anywhere. On 4/5/21 03:49, Tim Weippert wrote:
You can add the exetended communities via generic extended communitiy in bird:
bgp_ext_community.add( (generic, 0x80060000, 0x00000000 ) );
the output in birdc will look like:
flow4 { dst 203.0.113.53/32; src 198.51.100.10/32; } [S_FLOWSPEC_v4 07:48:34.659] * (200) Type: static univ BGP.ext_community: (generic, 0x80060000, 0x0)
Thanks! Will update to at least do rate limiting by maps this week/weekend. Matt
Update: Went ahead and implemented the standard communities except redirect. The rate limiter could probably be faster, and could support more than a one-packet burst, but it all seems to work. One other comment, the NET_FLOW type docs (copied below) seem to indicate that I should be able to do net.src... or net.dst... in a filter importing a flowspec rule, but BIRD seems to refuse to allow that. Matt
NET_FLOW4 and NET_FLOW6 hold an IP prefix together with a flowspec rule. Filters currently do not support much flowspec parsing, only .src and .dst operators to get source and destination parts of the flowspec as separate NET_IP4 / NET_IP6 values.
On 4/5/21 14:45, Matt Corallo wrote:
Replies to both responses.
On 4/5/21 05:04, Maria Matejka wrote:
Hello!
On 4/4/21 6:18 PM, Matt Corallo wrote:
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.
Would you benefit from having Python API in BIRD, getting the flowspec rules as proper objects?
Hmm, probably, I guess? Its not really that hard to parse the birdc output as long as I figure out the exact semantics to convert a X-match string into an AST. Putting in the work to write a whole Python API sounds like more work than its worth, but, hey, if you build it, I'll use it :)
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.
I remember coding something around that, anyway I don't remember whether we actually merged it. Will look for that.
See below from Tim - (generic, X, Y). I do not believe this is documented anywhere.
On 4/5/21 03:49, Tim Weippert wrote:
You can add the exetended communities via generic extended communitiy in bird:
bgp_ext_community.add( (generic, 0x80060000, 0x00000000 ) );
the output in birdc will look like:
flow4 { dst 203.0.113.53/32; src 198.51.100.10/32; } [S_FLOWSPEC_v4 07:48:34.659] * (200) Type: static univ BGP.ext_community: (generic, 0x80060000, 0x0)
Thanks! Will update to at least do rate limiting by maps this week/weekend.
Matt
On Tue, Apr 06, 2021 at 12:48:07PM -0400, Matt Corallo wrote:
One other comment, the NET_FLOW type docs (copied below) seem to indicate that I should be able to do net.src... or net.dst... in a filter importing a flowspec rule, but BIRD seems to refuse to allow that.
That was added in the latest versin (2.0.8), not sure if you have that. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Ah, indeed, I have not upgraded. One more (hopefully last) question - it does seem that the order of the flowspec rules isn't 100% consistent on the far side of a BIRD<->BIRD BGP connection. Is that a known bug or reason for that, or should I try to dig more into why that might be? Matt On 4/6/21 13:04, Ondrej Zajicek wrote:
On Tue, Apr 06, 2021 at 12:48:07PM -0400, Matt Corallo wrote:
One other comment, the NET_FLOW type docs (copied below) seem to indicate that I should be able to do net.src... or net.dst... in a filter importing a flowspec rule, but BIRD seems to refuse to allow that.
That was added in the latest versin (2.0.8), not sure if you have that.
On Tue, Apr 06, 2021 at 04:55:16PM -0400, Matt Corallo wrote:
Ah, indeed, I have not upgraded.
One more (hopefully last) question - it does seem that the order of the flowspec rules isn't 100% consistent on the far side of a BIRD<->BIRD BGP connection. Is that a known bug or reason for that, or should I try to dig more into why that might be?
Not sure what 'order of flowspec rules' you mean. BGP just propagates a set of routes (or flowspec rules) to sync tables on both sides. No order is defined or preserved, as far as BGP is concerned. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Ah, I admit I hadn't read the RFC in enough detail, I was kinda hoping birdc was printing the rules in sorted order (see RFC 5575 5.1. Order of Traffic Filtering Rules), but looks like I'll need to sort them myself. Matt On 4/6/21 17:41, Ondrej Zajicek wrote:
On Tue, Apr 06, 2021 at 04:55:16PM -0400, Matt Corallo wrote:
Ah, indeed, I have not upgraded.
One more (hopefully last) question - it does seem that the order of the flowspec rules isn't 100% consistent on the far side of a BIRD<->BIRD BGP connection. Is that a known bug or reason for that, or should I try to dig more into why that might be?
Not sure what 'order of flowspec rules' you mean. BGP just propagates a set of routes (or flowspec rules) to sync tables on both sides. No order is defined or preserved, as far as BGP is concerned.
Hmm, actually, I take that back, sorting them would require re-serializing the wire format, which I've thus far entirely avoided. I suppose I could drop the whole birdc thing, spin up a BGP daemon and use that, but that's a lot more work. Is there an easy way/patch to get birdc to output flowspec rules sorted according to the RFC? Thanks, Matt On 4/6/21 17:52, Matt Corallo wrote:
Ah, I admit I hadn't read the RFC in enough detail, I was kinda hoping birdc was printing the rules in sorted order (see RFC 5575 5.1. Order of Traffic Filtering Rules), but looks like I'll need to sort them myself.
Matt
On 4/6/21 17:41, Ondrej Zajicek wrote:
On Tue, Apr 06, 2021 at 04:55:16PM -0400, Matt Corallo wrote:
Ah, indeed, I have not upgraded.
One more (hopefully last) question - it does seem that the order of the flowspec rules isn't 100% consistent on the far side of a BIRD<->BIRD BGP connection. Is that a known bug or reason for that, or should I try to dig more into why that might be?
Not sure what 'order of flowspec rules' you mean. BGP just propagates a set of routes (or flowspec rules) to sync tables on both sides. No order is defined or preserved, as far as BGP is concerned.
On Tue, Apr 06, 2021 at 07:26:39PM -0400, Matt Corallo wrote:
Hmm, actually, I take that back, sorting them would require re-serializing the wire format, which I've thus far entirely avoided. I suppose I could drop the whole birdc thing, spin up a BGP daemon and use that, but that's a lot more work. Is there an easy way/patch to get birdc to output flowspec rules sorted according to the RFC?
I see the issue. BIRD does not implement this sorting as it is just for flowspec rule execution (i.e. configuring firewall), it is not used in BGP session. You could perhaps patch BIRD to do that by adding a mode to 'show route' command that would copy all routes to a buffer, do qsort() on that, and then send them to birdc. We do not do that for regular routes, but it could be a reasonable approach for flowspec routes (as i would expect there is much lower number of them). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
Is such a patch something upstream would take? Don't know when I'll have a chance to work on such a thing, likely some time from now, but any tips on where to poke at to get started? I've never done any serious reading or modification of BIRD. Matt On 4/6/21 21:41, Ondrej Zajicek wrote:
On Tue, Apr 06, 2021 at 07:26:39PM -0400, Matt Corallo wrote:
Hmm, actually, I take that back, sorting them would require re-serializing the wire format, which I've thus far entirely avoided. I suppose I could drop the whole birdc thing, spin up a BGP daemon and use that, but that's a lot more work. Is there an easy way/patch to get birdc to output flowspec rules sorted according to the RFC?
I see the issue. BIRD does not implement this sorting as it is just for flowspec rule execution (i.e. configuring firewall), it is not used in BGP session. You could perhaps patch BIRD to do that by adding a mode to 'show route' command that would copy all routes to a buffer, do qsort() on that, and then send them to birdc. We do not do that for regular routes, but it could be a reasonable approach for flowspec routes (as i would expect there is much lower number of them).
hi Maria, On Mon, Apr 05, 2021 at 11:04:47AM +0200, Maria Matejka wrote:
Hello!
[ ... ]
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.
I remember coding something around that, anyway I don't remember whether we actually merged it. Will look for that.
Maybe you mean the show-route branch, this is what i had documented in my internal files: # branch show-route syntax route flow4 { src 198.51.100.11/32; dst 203.0.113.54/32; } action { rate 0 MBps; }; i tested it with 2.0.7 but it seems it wasn't merged yet. regards, tim -- Tim Weippert http://weiti.org - weiti@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
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
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@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."
On 5/17/21 19:44, Ondrej Zajicek wrote:
On Mon, May 17, 2021 at 01:48:19PM -0400, Matt Corallo wrote: 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.
Ha! right, yea, some documentation would be helpful. Just to double-check, fragmentation-type uses "," as ||, correct?
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.
Eh, don't care too much about recomposition, its kinda nice to see what was received on the wire. Thanks, Matt
On Mon, May 17, 2021 at 08:27:10PM -0400, Matt Corallo wrote:
On 5/17/21 19:44, Ondrej Zajicek wrote:
On Mon, May 17, 2021 at 01:48:19PM -0400, Matt Corallo wrote: 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.
Ha! right, yea, some documentation would be helpful. Just to double-check, fragmentation-type uses "," as ||, correct?
No, fragmentation-type is just a variant of bitmask. I think that a way out of this confusion is to deprecate ',' from bitmask (and fragmentation) and always show && or || (but keep ',' in parser for compatibility reasons). And leave ',' only for list of numerical values where the meaning is clear. I think that if i knew nothing about BIRD flowspec syntax, then expression "port 10,20,30..40" is clear to me, but "tcp flags 0x2/0x3,0x0/0x10" definitely is not (while "tcp flags 0x2/0x3 && 0x0/0x10" is a bit more comprehensible).
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.
Eh, don't care too much about recomposition, its kinda nice to see what was received on the wire.
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On 5/18/21 09:43, Ondrej Zajicek wrote:
On Mon, May 17, 2021 at 08:27:10PM -0400, Matt Corallo wrote:
On 5/17/21 19:44, Ondrej Zajicek wrote:
On Mon, May 17, 2021 at 01:48:19PM -0400, Matt Corallo wrote: 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.
Ha! right, yea, some documentation would be helpful. Just to double-check, fragmentation-type uses "," as ||, correct?
No, fragmentation-type is just a variant of bitmask.
Oof. Ok, thanks, updated my BIRD flowspec -> XDP converter.
I think that a way out of this confusion is to deprecate ',' from bitmask (and fragmentation) and always show && or || (but keep ',' in parser for compatibility reasons). And leave ',' only for list of numerical values where the meaning is clear.
I think that if i knew nothing about BIRD flowspec syntax, then expression "port 10,20,30..40" is clear to me, but "tcp flags 0x2/0x3,0x0/0x10" definitely is not (while "tcp flags 0x2/0x3 && 0x0/0x10" is a bit more comprehensible).
Yea, this seems reasonable. If the `,` stays in, it may still make sense to note it in the docs.
participants (4)
-
Maria Matejka -
Matt Corallo -
Ondrej Zajicek -
Tim Weippert