Re: maximum ipv4 bgp prefix length of /24 ?
Hi. On 06/10/2023 16:00, nanog-request@nanog.org wrote:
From: Matthew Petach<mpetach@netflight.com> [...]
The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system.
Were you expecting it to be lower than IPv4?
Mark.
I've dug through the mailman mirror on nanog.org, and there's currently no post by Geoff Huston saying that: https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest
I read (and send) NANOG emails through the digest emails sent once a day. I noticed the same thing . I assumed it was sent directly to Mark (or the mail will enter my next digest...)
But I'll play along.
There's significantly less pressure to deaggregate IPv6 space right now, because we don't see many attacks on IPv6 number resources. Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we'll see IPv6 deaggregation completely swamp IPv4 deaggregation.
How about we educate each other to not assume you must deaggregate your prefix especially with IPv6? I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course. A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix. -- Willy Manga @ongolaboy https://ongola.blogspot.com/
On 10/7/23 14:32, Willy Manga wrote:
How about we educate each other to not assume you must deaggregate your prefix especially with IPv6?
I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course.
A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix.
There are a number of operational reasons folk de-aggregate. I do agree that there is some behaviour around de-aggregating by default in IPv4 that transferred to IPv6. But the main issue is that most people only consider the state of their own FIB situation. They hardly consider the FIB state of other network operators around the world. As an operator, you have to consciously decide that you will not de-aggregate any of your allocations. Of course, there is a cost to that as well, so that cannot be ignored. We, for example, do not de-aggregate any of our allocations (AS37100), but we can afford to do so because we always ensure all peering and transit exit/entry points have the same bandwidth (TE being the main reason networks de-aggregate). Not all shops can afford that. Network operations workshops abound where we teach about de-aggregation, when it can be necessary, and why it should generally be avoided unless in the most extreme of circumstances. However, in real life, even engineers that have been through the workshop ringer tend to prefer to de-aggregate without caution to the FIB state of other autonomous systems. That said, I do agree that, perhaps, network operations workshops could emphasize the reluctance to unnecessarily de-aggregate in light of the increasing cost of having to maintain FIB's. Mark.
On Sat, Oct 7, 2023 at 9:27 AM Willy Manga <mangawilly@gmail.com> wrote:
Hi.
On 06/10/2023 16:00, nanog-request@nanog.org wrote:
From: Matthew Petach<mpetach@netflight.com> [...]
There's significantly less pressure to deaggregate IPv6 space right now, because we don't see many attacks on IPv6 number resources. Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we'll see IPv6 deaggregation completely swamp IPv4 deaggregation.
How about we educate each other to not assume you must deaggregate your prefix especially with IPv6?
If you're the victim of a prefix hijacking, you don't really have a choice. Right now, that's the only way to try to counteract a prefix hijacking; to advertise something at least as specific as the prefix being hijacked, or smaller if possible. I see 'some' (it's highly relative) networks on IPv4, they 'believe'
they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course.
A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix.
Absolutely. Right up the moment someone hijacks part of your IP space. And then you announce a bunch of more specifics to try to counteract the hijacking. If you're a good, responsible network, you remove the more specific prefixes once the hijacking is done. If you're most networks, you're overworked, understaffed, and cleanup is at the bottom of the priority list, so you just leave them being announced, just in case someone tries to hijack your space again. Most cases of deaggregation I've seen are the result of an event that took place that triggered it, not just because people don't know better. Now, RPKI can help a little bit, at least with protecting you from accidental route leaks and unintended hijacks; but it only validates the ASN originating the prefix, it doesn't validate the full pathway. So, being a determined hijacker, I'm going to set my router up to pretend to be the correct origin ASN, and announce more specifics, adjusting the AS-PATH to match what my neighbors and upstreams expect to see, and utter silent thanks that most networks use a relatively liberal "max length" for the prefixes in their ROAs (just in case *they* need to announce more specifics to counteract my hijacking effort). As we crack the BGP path validation nut, and put some means in place to validate BGP adjacencies, this attack vector will fade away, and the need to be able to announce more specifics willy-nilly will slowly go by the wayside. But for the moment, it's just as necessary in IPv6 as it is in IPv4, though the resulting impact is less, because wise networks allocate their IPv6 prefixes in a sparse manner, meaning that during a hijack event, you only need to announce the matching /48s for the blocks carrying relevant traffic, which should be a small fraction of your overall v6 assignment. I completely agree that we should educate network engineers to only advertise the largest prefix possible that covers your space. But I also realize that in the world of non-secured BGP adjacencies and non-validatable BGP AS-PATHs, we cannot fault people for having to deaggregate during prefix hijacking events. Thanks! Matt
Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can specify the maximum prefix length allowed to be advertised within a shorter prefix and those (theoretically) block hijackers taking advantage of advertising more specifics to cut you off? While I recognize that RPKI is not ubiquitous, enough of the major backbones are dropping RPKI invalids that I think any sort of hijacking in violation of that wouldn’t be very effective today. YMMV of course, but that seems to me to be a far better solution (almost enough to make me rethink the questionable value of RPKI) than disaggregation. Owen
On Oct 7, 2023, at 05:32, Willy Manga <mangawilly@gmail.com> wrote:
Hi.
On 06/10/2023 16:00, nanog-request@nanog.org wrote:
From: Matthew Petach<mpetach@netflight.com> [...]
The IPv6 FIB is under the same pressure from more specifics. Its taken 20 years to get there, but the IPv6 FIB is now looking stable at 60% opf the total FIB size [2]. For me, thats a very surprising outcome in an essentially unmanaged system.
Were you expecting it to be lower than IPv4?
Mark.
I've dug through the mailman mirror on nanog.org, and there's currently no post by Geoff Huston saying that: https://community.nanog.org/search?q=geoff%20huston%20order%3Alatest
I read (and send) NANOG emails through the digest emails sent once a day. I noticed the same thing . I assumed it was sent directly to Mark (or the mail will enter my next digest...)
But I'll play along. There's significantly less pressure to deaggregate IPv6 space right now, because we don't see many attacks on IPv6 number resources. Once we start to see v6 prefix hijackings, /48s being announced over /32 prefixes to pull traffic, then I think we'll see IPv6 deaggregation completely swamp IPv4 deaggregation.
How about we educate each other to not assume you must deaggregate your prefix especially with IPv6?
I see 'some' (it's highly relative) networks on IPv4, they 'believe' they have to advertise every single /24 they have. And when they start with IPv6, they replicate the same mindset with a tons of /48 . You can imagine what will happen of course.
A better alternative IMHO is to take advantage to the large prefix range and advertise a sub-aggregate when necessary. But absolutely not each end-node or customer prefix.
-- Willy Manga @ongolaboy https://ongola.blogspot.com/
On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG <nanog@nanog.org> wrote:
Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can specify the maximum prefix length allowed to be advertised within a shorter prefix and those (theoretically) block hijackers taking advantage of advertising more specifics to cut you off?
While I recognize that RPKI is not ubiquitous, enough of the major backbones are dropping RPKI invalids that I think any sort of hijacking in violation of that wouldn’t be very effective today.
YMMV of course, but that seems to me to be a far better solution (almost enough to make me rethink the questionable value of RPKI) than disaggregation.
Owen
Owen, RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings. RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination. If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs protecting it, and AS YY has allowed more specifics to be announced within the prefix range covered by the ROA, I'm in like flynn, because I just need to configure my router with AS YY as the origin AS, then insert the expected ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the more specific prefix passes RPKI validation, and traffic comes flying my way. If AS YY doesn't allow longer prefixes within the scope of their ROA, then it's a bit dicier, because it comes down to AS-PATH length, but there's still a good chance you can suck in traffic from your adjacent neighbors. So yes, hijackings in violation of RPKI aren't as effective, but RPKI doesn't prevent intentional hijackings--it just protects against accidental misconfigurations and unintentional hijackings. Thus, deaggregation is still very much part of the defensive toolbox, even with RPKI in place. As a side note, it's also a really good reason why you shouldn't allow longer prefixes to be announced under your ROAs, except under very well understood conditions. ^_^; Thanks! Matt
On Oct 10, 2023, at 13:36, Matthew Petach <mpetach@netflight.com> wrote:
On Tue, Oct 10, 2023 at 12:58 PM Delong.com via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
Isn’t this supposed to be one of the few ACTUAL benefits of RPKI — You can specify the maximum prefix length allowed to be advertised within a shorter prefix and those (theoretically) block hijackers taking advantage of advertising more specifics to cut you off?
While I recognize that RPKI is not ubiquitous, enough of the major backbones are dropping RPKI invalids that I think any sort of hijacking in violation of that wouldn’t be very effective today.
YMMV of course, but that seems to me to be a far better solution (almost enough to make me rethink the questionable value of RPKI) than disaggregation.
Owen
Owen,
RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings.
OK, but at least they can help limit the extent of required desegregation in combat unless I misunderstand the whole MAXPREFIXLEN option.
RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination.
Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid.
If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs protecting it, and AS YY has allowed more specifics to be announced within the prefix range covered by the ROA, I'm in like flynn, because I just need to configure my router with AS YY as the origin AS, then insert the expected ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the more specific prefix passes RPKI validation, and traffic comes flying my way.
Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, then YY has indeed aimed a firearm squarely at their lower distal appendage and fired. However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
If AS YY doesn't allow longer prefixes within the scope of their ROA, then it's a bit dicier, because it comes down to AS-PATH length, but there's still a good chance you can suck in traffic from your adjacent neighbors.
Sure, but that’s true if the hijacker is willing to disaggregate down to whatever your MAXPREFIXLEN is, no matter what, even if that’s /48. At least this allows the AS owner to set some desegregation floor where the more specific battle ends short of /48.
So yes, hijackings in violation of RPKI aren't as effective, but RPKI doesn't prevent intentional hijackings--it just protects against accidental misconfigurations and unintentional hijackings.
Oh, you don’t have convince me on that one. I’ve long said “RPKI offers little more than a cryptographically signed hint as to what hijackers need to prepend to their announcements.”.
Thus, deaggregation is still very much part of the defensive toolbox, even with RPKI in place.
Yes, but RPKI properly used does allow one to limit the extent of the deaegregation battle.
As a side note, it's also a really good reason why you shouldn't allow longer prefixes to be announced under your ROAs, except under very well understood conditions. ^_^;
Right… AND add AS-0 ROAs for any more specifics you don’t want announced. Owen
On 11/10/2023 03:52, Delong.com wrote:
On Oct 10, 2023, at 13:36, Matthew Petach <mpetach@netflight.com> wrote: [...] Owen,
RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings.
OK, but at least they can help limit the extent of required desegregation in combat unless I misunderstand the whole MAXPREFIXLEN option.
Actually, RFC 9319 do recommend to "avoid using the maxLength attribute in ROAs except in some specific cases". But I recognise that this RFC is not yet implemented everywhere.
RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination.
Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”.
E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid.
Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1] 1. https://rpki.readthedocs.io/en/latest/rpki/securing-bgp.html#maximum-prefix-... -- Willy Manga @ongolaboy https://ongola.blogspot.com/
On Oct 10, 2023, at 22:44, Willy Manga <mangawilly@gmail.com> wrote:
On 11/10/2023 03:52, Delong.com wrote:
On Oct 10, 2023, at 13:36, Matthew Petach <mpetach@netflight.com> wrote: [...] Owen,
RPKI only addresses accidental hijackings. It does not help prevent intentional hijackings. OK, but at least they can help limit the extent of required desegregation in combat unless I misunderstand the whole MAXPREFIXLEN option.
Actually, RFC 9319 do recommend to "avoid using the maxLength attribute in ROAs except in some specific cases". But I recognise that this RFC is not yet implemented everywhere.
It’s a BCP, and may be worthy of reconsideration. The justification in section 1.0 paragraph 3 of that basically points out exactly what I said people _SHOULD_ be doing _IF_ they use max prefix and have failed to do in “84% were vulnerable…”.
RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination.
Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid.
Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1]
You completely ignored my statement of the need for appropriate AS-0 ROAs to block those. Owen
. On 11/10/2023 22:29, Delong.com wrote:
[...]
Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1]
You completely ignored my statement of the need for appropriate AS-0 ROAs to block those.
I did not want to comment because you can go down that path *and* you will assume everyone doing ROV will consider AS0 ROAs as well. IMHO the bare minimum is to cover your advertisements with a ROA as precise as possible. -- Willy Manga @ongolaboy https://ongola.blogspot.com/
On Oct 11, 2023, at 18:53, Willy Manga <mangawilly@gmail.com> wrote:
. On 11/10/2023 22:29, Delong.com wrote:
[...]
Yes, but in that scenario any advertisements between /32 and /36 from that prefix originated by AS65500 are *valid* . That's why "ROAs should be as precise as possible, meaning they should match prefixes as announced in BGP" [1] You completely ignored my statement of the need for appropriate AS-0 ROAs to block those.
I did not want to comment because you can go down that path *and* you will assume everyone doing ROV will consider AS0 ROAs as well.
Well, true, but AIUI, if you’re processing ROAs, one with AS0 must be considered as making every matching prefix “Invalid”. In fact, even if one doesn’t treat AS0 as a special case in an RPKI validator, AS0 isn’t going to match the origin AS for any route you see, or your router and all of the routers between you and the origin router are truly broken.
IMHO the bare minimum is to cover your advertisements with a ROA as precise as possible.
Agree, but in the case where you have to advertise some more specifics, as in the example I provided, then if I understand things correctly, you can’t be that precise and that’s why I provided the AS0 based solution for the invalid more specifics. Owen
Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 04:52:07PM -0700:
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Double check, but offhand I believe in this case you do not need all these AS0 ROA's. Any validated ROA payload fully matching should be all you need for it to be valid, and anything that is covered by a vrp but not matching is invalid. So, I think you can do 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 Dale
On Oct 11, 2023, at 11:50, Dale W. Carder <dwcarder@es.net> wrote:
Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 04:52:07PM -0700:
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Double check, but offhand I believe in this case you do not need all these AS0 ROA's. Any validated ROA payload fully matching should be all you need for it to be valid, and anything that is covered by a vrp but not matching is invalid.
So, I think you can do 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Dale
My understanding is that the 2001:db8::/32 max=32 would block the /36s from being considered valid (in order to prevent someone with trust anchor B overriding the policy of someone with trust anchor A). Since all the trust anchors are ::/0, I think that was deemed important. I could be wrong, like you, I would need to double check the details. Owen
Thus spake Delong.com (owen@delong.com) on Wed, Oct 11, 2023 at 12:44:35PM -0700:
On Oct 11, 2023, at 11:50, Dale W. Carder <dwcarder@es.net> wrote:
Thus spake Delong.com via NANOG (nanog@nanog.org) on Tue, Oct 10, 2023 at 04:52:07PM -0700:
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Double check, but offhand I believe in this case you do not need all these AS0 ROA's. Any validated ROA payload fully matching should be all you need for it to be valid, and anything that is covered by a vrp but not matching is invalid.
So, I think you can do 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=32 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
Dale
My understanding is that the 2001:db8::/32 max=32 would block the /36s from being considered valid (in order to prevent someone with trust anchor B overriding the policy of someone with trust anchor A).
Since all the trust anchors are ::/0, I think that was deemed important.
I could be wrong, like you, I would need to double check the details.
I found a working example from within our customer cone: https://rpki-validator.ripe.net/ui/2620%3A6a%3A%3A%2F48/3152 Dale
. On 11/10/2023 03:52, Delong.com wrote:
[...]
RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination.
Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”.
E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid.
If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs protecting it, and AS YY has allowed more specifics to be announced within the prefix range covered by the ROA, I'm in like flynn, because I just need to configure my router with AS YY as the origin AS, then insert the expected ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the more specific prefix passes RPKI validation, and traffic comes flying my way.
Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, then YY has indeed aimed a firearm squarely at their lower distal appendage and fired.
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why? 1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty. 2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them. 1. https://mailman.nanog.org/pipermail/nanog/2023-October/223676.html -- Willy Manga @ongolaboy https://ongola.blogspot.com/
On Oct 11, 2023, at 19:18, Willy Manga <mangawilly@gmail.com> wrote:
.
On 11/10/2023 03:52, Delong.com wrote:
[...]
RPKI only asserts that a specific ASN must originate a prefix. It does nothing to validate the authenticity of the origination. Nope… It ALSO asserts (or can assert) an attribute of “Maximum allowed prefix length”. E.g. if I have a ROA for AS65500 to originate 2001:db8::/32 with a “Maximum Length” attribute of /36, then any advertisement (even originated by 65500) that is longer than /36 should be considered invalid. If I am AS XX, and want to hijack a prefix from AS YY that has RPKI ROAs protecting it, and AS YY has allowed more specifics to be announced within the prefix range covered by the ROA, I'm in like flynn, because I just need to configure my router with AS YY as the origin AS, then insert the expected ASN for the neighbor adjacency with my upstreams, and bob's your uncle, the more specific prefix passes RPKI validation, and traffic comes flying my way. Yes, IF YY has allowed longer prefixes. If YY doesn’t allow longer prefixes and/or doesn’t supply AS0 ROAs for more specifics that should not be announced, then YY has indeed aimed a firearm squarely at their lower distal appendage and fired. However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why?
If that works, perhaps… OTOH, I’m not sure it does. I’m not sure the /32 MAXLEN 32 wouldn’t prevent effectiveness of the /36 ROAs.
1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty.
I can… It’s an Optional Field in the specification.
2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them.
Yes, but if I issue a /34 AS0 with no MAXLEN, that _SHOULD_ mark ALL more specifics as invalid. If that doesn’t work, then you’re right, the AS0 ROAs are essentially useless, but then one has to wonder what value any RIR issued AS0 ROAs would have as well, since they would obviously be less specific. Owen
. On 12/10/2023 10:00, Owen DeLong wrote:
[...]
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why?
If that works, perhaps… OTOH, I’m not sure it does. I’m not sure the /32 MAXLEN 32 wouldn’t prevent effectiveness of the /36 ROAs.
1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty.
I can… It’s an Optional Field in the specification.
For the _specification_ yes. But by "Implementation" I'm referring to whatever either the RIR (those using hosted mode) or your own RPKI Certificate Authority (those using the delegated mode) will allow.
2. If you want to follow that logic, what you are trying to accomplish with AS0 is basically the *complement* of what you are not advertising. I believe that will be much more work and you might miss a lot of specifics. e.g : under your 2001:db8::/32 , do not forget you have 16x/36, 2x/33,4x/34,... You will have to insert statement for every single of them.
Yes, but if I issue a /34 AS0 with no MAXLEN, that _SHOULD_ mark ALL more specifics as invalid.
If that doesn’t work, then you’re right, the AS0 ROAs are essentially useless, but then one has to wonder what value any RIR issued AS0 ROAs would have as well, since they would obviously be less specific.
I will let those with more experience than me provide clarifications here. -- Willy Manga @ongolaboy https://ongola.blogspot.com/
On Oct 12, 2023, at 01:42, Willy Manga <mangawilly@gmail.com> wrote:
.
On 12/10/2023 10:00, Owen DeLong wrote: [...]
However, IF YY is paying attention, and YY wants to advertise 2001:db8::/32 as well as allow 2001:db8:8000::/36 and 2001:db8:f000::/36, I would expect AS YY would generate ROAs for 2001:db8::/32 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:0::/33 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:8000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36 2001:db8:9000::/35 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:a000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:c000::/34 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:e000::/36 with ORIGIN-AS=0 (no MAXPREFIXLEN needed) 2001:db8:f000::/36 with ORIGIN-AS=YY MAXPREFIXLEN=36
As Dale suggested in another email[1], it's better to just cover ROAs for what you are advertising. Why? If that works, perhaps… OTOH, I’m not sure it does. I’m not sure the /32 MAXLEN 32 wouldn’t prevent effectiveness of the /36 ROAs.
1. I can't confirm at this stage that all the implementation allows you to leave the maxLength field empty. I can… It’s an Optional Field in the specification.
For the _specification_ yes. But by "Implementation" I'm referring to whatever either the RIR (those using hosted mode) or your own RPKI Certificate Authority (those using the delegated mode) will allow.
I don’t consider non-compliant implementations as something that needs to or even should be accommodated. Owen
participants (6)
-
Dale W. Carder -
Delong.com -
Mark Tinka -
Matthew Petach -
Owen DeLong
-
Willy Manga