Flowspec matches for unassigned protocols or imp types and codes

[adrian62]

We use flowspec mostly for blocking or mitigating various kinds of attacks. As such, often we want to match traffic whose header fields may not always be 'valid' in the sense that a specific meaning is not assigned to them. Attackers don't necessarily follow standards :) Take for example protocols: there are many values that are not assigned. Exabgp allows us to specify the protocol (or ICMP types and codes) by value (in my example 15), but when we receive such a route from the api we get something like =unknown protocol type 15.

While this is useful for a user interface or human reading logs, it requires exception code to handle the unassigned values.

Describe the solution you'd like I am asking for guidance for creating a patch to eliminate the unknown ... type text and just leaving the expression, in the example above =15 meaning to match exactly protocol 15.

Describe alternatives you've considered Exception code receiving from the exabgp API can look for unknown ... and remove it, leaving just the operator(s) and value.

Additional context If others would have interest maybe this could be made a configurable option.

[thomas-mangin]

Please provide a example packet if you can

[adrian62]

Thanks for looking, using a sample config like this:

 flow {
        route test_RL {
               rd 0:0;
               match {
                     protocol =15;
               then {
                     discard;
               }
         }
}

Results in this packet going to the peer:

23:50:57 | 10     | outgoing-1      | sending TCP payload (  68) FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0044 0200 0000 2D40 0101 0040 0200 4005 0400 0000 64C0 1008 8006 0000 0000 0000 800E 1100 0186 0000 0B00 0000 0000 0000 0003 810F

And on the peer this is the data received on the API:

INFO:  jsonUpdate:b'{ "exabgp": "4.0.1", "time": 1682121456.9856453, "host" : "BRID2", "pid" : 10, "ppid" : 7, "counter": 24, "type": "update", "neighbor": { "address": { "local": "198.18.21.62", "peer": "198.18.21.30" }, "asn": { "local": 100, "peer": 100 } , "direction": "receive", "message": { "update": { "attribute": { "origin": "igp", "local-preference": 100, "extended-community": [ { "value": 9225060886715039744, "string": "rate-limit:0" } ] }, "announce": { "ipv4 flow-vpn": { "no-nexthop": [ { "protocol": [ "=unknown protocol type 15" ], "rd": "0:0", "string": "flow protocol =unknown protocol type 15 rd 0:0" } ] } } } } } }\n'

[thomas-mangin]

https://github.com/Exa-Networks/exabgp/commit/cb244de3760e75a0a07a7cb4cb4ed87174c253af

I am not sure if we should backport to 4.2 as some users may rely on the string as it is (even if it is bad).

Also need to add a test.

[adrian62]

Thank you, I guess I'll have to try the main branch (5.x?) but pardon my ignorance: in previous versions I passed the environment file with --env but I don't see that option, how do I specify an env file not in the standard location?

M-GQ69FQP39W:exabgp-5 ac1471$ ./sbin/exabgp server --env ~/myenvfile.env ~/myconfig.conf
usage: main.py [-h] {version,cli,healthcheck,env,decode,server,validate} ...
main.py: error: unrecognized arguments: --env