-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flowspec matches for unassigned protocols or imp types and codes #1156
Comments
Please provide a example packet if you can |
Thanks for looking, using a sample config like this:
Results in this packet going to the peer:
And on the peer this is the data received on the API:
|
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. |
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?
|
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.
The text was updated successfully, but these errors were encountered: