Perhaps s/bgp_path.last_nonaggregated/bgp_path.last/g #56
Conversation
bgp_path.last is consistent with RFC 6907 7.1.9-11 according to BIRD developers.
|
Thanks @job, merged. |
|
I don't think this RFC is is for the same thing that has changed here. This seems to discus RPKI roa validation. This is changing the checks if origin ASN is in IRRDB ASSET. This bgp_path.last attribute returns 0 for routes with atomic aggregate set. Unless behaviour has changed in BIRD we will have to tell people that using atomic aggregate on BGP isn't supported. This should at least be a configurable option. I suggested last_nonaggregated initially because a bunch of my participant routes were being dropped on VANIX routeserver(not in allowed as-sets - REJECTING). |
|
Can you share more about what was “dropped”? Need more details to understand
…On Thu, May 28, 2020, at 09:21, Chris wrote:
I don't think this RFC is is for the same thing that has changed here.
This seems to discus RPKI roa validation. This is changing the checks
if origin ASN is in IRRDB ASSET. This bgp_path.last attribute returns 0
for routes with atomic aggregate set. Unless behaviour has changed in
BIRD we will have to tell people that using atomic aggregate on BGP
isn't supported. This should at least be a configurable option. I
suggested last_nonaggregated initially because a bunch of my
participant routes were being dropped on VANIX routeserver.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFRWBTIBQQ63RGQKXQ2ELRTYGI3ANCNFSM4MMNDBJQ>.
|
|
Hi @s1sfa, could you share, even privately, some output from your BIRD instance? Here |
|
Here is a specific example of a route that is accepted now that would be rejected by this update. bgp_path.last == 0 for all aggregated routes. If bgp_path.last is the only variable used to check ASN in ASSETs it will always fail on these aggregated routes. `bird> show route 199.59.185.0/24 all bird> show route 199.59.185.0/24 where roa_check(RPKI, net, bgp_path.last) = ROA_INVALID |
|
It seems that I will try to setup a test scenario to validate this. Does anyone know if there's an easy way to forge and announce an atomic aggregate route using ExaBGP? I believe (not sure though) that's not possible doing it in BIRD. Worst case I'll try to play a bit with some BGP replay tool (bgpsimple maybe?), in order to read it from a bgpdump file and announce it to BIRD. |
|
I haven't done this in EXABGP before but google shows the options. |
|
Hey Chris, Thank you so much for sharing more details! I think you are right that this change broke something. I did a blanket replace on From a code development perspective, @pierky do you want me to |
|
Thanls @s1sfa, I'll try to use ExaBGP to inject a similar route into the integration testing environment and build a test case for this scenario.
@job my plan is to just push new commits into the "dev" branch (I'll recreate it on top of master), so that it will eventually trigger the test pipeline to validate that everything works as expected. I'll probably work on it during this weekend. |
|
@s1sfa, I've looked a bit into BOV and AS_SETs in the AS_PATH attributes, and my conclusion is that using Specifically, RFC6907 says
This matches the case of
So basically any route with an AS_SET in the AS_PATH for which a covering ROA exists should be treated as an INVALID. BCP172/RFC6472 also covers the topic of AS_SETs when it's up to origin validation:
I believe that in terms of origin validation (which is also the goal of the IRR-based check) using Along the line of BCP172/RFC6472, I'm inclined towards not changing the behaviour of the tool: of course, I'd love to hear more from you and @job. If you want to forcedly accept those routes, you can configure a client-level white list as mentioned here. white_list_route:
- prefix: 199.59.185.0
length: 24Please note the absence of the |
|
Accordingly to further tests, it seems that OpenBGPD implements different behaviours for RPKI BOV and "regular" origin validation against an AS set. A route with an AS_PATH like The OpenBGPD implementation of vanilla origin AS validation in presence of an AS_SET looks like the same that could be obtained in BIRD using On the basis of my findings, it seems that we can define the following cases:
The goal of both the mechanisms (RPKI BOV and IRR-based filtering) is to someway validate the origin of a route, and I see the implementation of how that is done in RPKI more oriented towards a possible "future" (worth mentioning draft-ietf-idr-deprecate-as-set-confed-set-03 on this topic besides BCP172/RFC6472 already mentioned in my previous comment) and more consistent with the idea of "origin". That said, I'm still inclined towards not reverting the implementation of BIRD back to the use of Any thoughts from the field? |
|
Small question of clarification: when you say “RPKI BOV” do you mean “RPKI ROV” (as in RFC 6811 Route Origin Validation)?
|
Yes, that. |
|
Ok, thanks for the detailed look into this @pierky and @job . It looks like the answer is that AS_SET isn't intended to be supported on the internet and it's use is discouraged as per RFC6472. https://tools.ietf.org/html/rfc6472. I think a tool like this used by many organizations has an obligation to abide by RFC's. |
|
What’s really confusing in all of this is that there are |
This commit adds test cases related to the way AS_PATHs whose origin
is an AS_SET are treated with regards to RPKI origin validation and
IRR checks.
RFC6907:
> Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost
> position in the AS_PATH}
>
> ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
>
> Recommended RPKI prefix-origin validation interpretation: Route is
> Invalid.
> In the spirit of [RFC6472], any route with an AS_SET in it
> should not be considered valid (by ROA-based validation). If the
> route contains an AS_SET and a covering ROA prefix exists for the
> route prefix, then the route should get an Invalid status.
> (Note: AS match or mismatch consideration does not apply.)
So basically any route with an AS_SET in the AS_PATH for which a
covering ROA exists should be treated as an INVALID.
With this commit a test case to validate this is introduced.
Even though such test case is not strictly related to verify the
behaviour of ARouteServer but rather the implementation of the
BGP speakers, it was useful to deal with PR #56.
Two more test cases cover the way IRR checks are performed when the
AS_PATH ends with an AS_SET.
BIRD and OpenBGPD behave differently under that circumstance.
In BIRD, comparing a list of valid origin ASNs (generated from info
fetched from IRRs) against `bgp_path.last` leads to a mismatch,
regardless of the content of the AS_SET
In OpenBGPD, the vanilla origin AS validation in presence of an
AS_SET looks like the same that could be obtained in BIRD using
`bgp_path.last_nonaggregated`. A route with an AS_PATH like
222 333 { 444 555 } fails the BOV validation against a ROA whose
AS is 333, as wanted by RFC6907 7.1.9, but then a match like the
following one succeeds:
as-set "AS_SET_AS_AS222_asns" {
333
}
match ... source-as as-set AS_SET_AS_AS222_asns
The goal of both the mechanisms (RPKI OV and IRR-based filtering)
is to someway validate the origin of a route, and I see the
implementation of how that is done in RPKI more oriented towards a
possible "future" (worth mentioning
draft-ietf-idr-deprecate-as-set-confed-set-03 on this topic, and
BCP172/RFC6472 too) and more consistent with the idea of "origin".
The BIRD implementation of IRR-based checks using `bgp_path.last`
is consistent with the RPKI OV behaviour, and the one I also
personally prefer and see more future-oriented. The OpenBGPD one
is more "relaxed". This will lead to an inconsistency of how
route-servers configured with the same ARouteServer configuration
but running different BGP speakers will behave when it's up to
IRR-based checks of AS_PATH ending with AS_SET.
This commit adds test cases related to the way AS_PATHs whose origin
is an AS_SET are treated with regards to RPKI origin validation and
IRR checks.
RFC6907:
> Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost
> position in the AS_PATH}
>
> ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
>
> Recommended RPKI prefix-origin validation interpretation: Route is
> Invalid.
> In the spirit of [RFC6472], any route with an AS_SET in it
> should not be considered valid (by ROA-based validation). If the
> route contains an AS_SET and a covering ROA prefix exists for the
> route prefix, then the route should get an Invalid status.
> (Note: AS match or mismatch consideration does not apply.)
So basically any route with an AS_SET in the AS_PATH for which a
covering ROA exists should be treated as an INVALID.
With this commit a test case to validate this is introduced.
Even though such test case is not strictly related to verify the
behaviour of ARouteServer but rather the implementation of the
BGP speakers, it was useful to deal with PR #56.
Two more test cases cover the way IRR checks are performed when the
AS_PATH ends with an AS_SET.
BIRD and OpenBGPD behave differently under that circumstance.
In BIRD, comparing a list of valid origin ASNs (generated from info
fetched from IRRs) against `bgp_path.last` leads to a mismatch,
regardless of the content of the AS_SET
In OpenBGPD, the vanilla origin AS validation in presence of an
AS_SET looks like the same that could be obtained in BIRD using
`bgp_path.last_nonaggregated`. A route with an AS_PATH like
222 333 { 444 555 } fails the BOV validation against a ROA whose
AS is 333, as wanted by RFC6907 7.1.9, but then a match like the
following one succeeds:
as-set "AS_SET_AS_AS222_asns" {
333
}
match ... source-as as-set AS_SET_AS_AS222_asns
The goal of both the mechanisms (RPKI OV and IRR-based filtering)
is to someway validate the origin of a route, and I see the
implementation of how that is done in RPKI more oriented towards a
possible "future" (worth mentioning
draft-ietf-idr-deprecate-as-set-confed-set-03 on this topic, and
BCP172/RFC6472 too) and more consistent with the idea of "origin".
The BIRD implementation of IRR-based checks using `bgp_path.last`
is consistent with the RPKI OV behaviour, and the one I also
personally prefer and see more future-oriented. The OpenBGPD one
is more "relaxed". This will lead to an inconsistency of how
route-servers configured with the same ARouteServer configuration
but running different BGP speakers will behave when it's up to
IRR-based checks of AS_PATH ending with AS_SET.
|
I've added to the doc a mention about the different way in which BIRD and OpenBGPD handle IRR checks for routes whose AS_PATH ends with an AS_SET. Going to close this for now. |
bgp_path.last is consistent with RFC 6907 7.1.9-11 according to BIRD
developers.
I think I misunderstood what
last_nonaggregateddoes when I recommended it, what do you think?