Hello For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: " 2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: " 2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare. If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have? Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]
you can do it yourself announce the more specifics to the provider who gives ddos mediation, and the less specific, /32, to the non-protecting provider be sure that any IRR and RPKI data are good for both the aggregate and the specifics randy
Hello By doing this the internet will always (also under normal circumstances) prefer that one provider. My goal is for internet only prefer the traffic via this provider only when there is DDoS attack. And if I would have to do this manually, then it beats the purpose of automatic DDoS protection service. And in this case I would still have to create all the 65536 /48 route6 objects but instead of pointing to provider AS they would be pointing to my AS. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Randy Bush via db-wg" <db-wg@ripe.net> To: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Thursday, July 6, 2023 8:28:24 PM Subject: Re: [db-wg] Route(6) objects you can do it yourself announce the more specifics to the provider who gives ddos mediation, and the less specific, /32, to the non-protecting provider be sure that any IRR and RPKI data are good for both the aggregate and the specifics randy -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
By doing this the internet will always (also under normal circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer defensive prefixes 1 - announce only aggregates to both providers 2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider 3 - when ddos ends, return to state 1 randy
Hello Here the problem is "for longer defensive prefixes" For example in normal situation I advertise /32 to my ip transit providers. When DDoS happens then one of my providers will start advertisin 1x/48 of my /32 prefix to hi-jack the route from us and filter it. But in order for that provider to be able to do that I need ROA records and route6 objects pointing that all of the /48s that fit into my /32 would be originated from that provider. There is no issue with ROA records, because I can say that maximum prefix that this provider can advertise is /48 of my /32. But as far as I know I cannot do the same with route6 objects, I need to create all the /48 route6 objects pointing to that provider(65535 objects). But in ripe as far as I know there is 1000 objects per day limitation that I can create. With this rate I will create more than 2 months these objects only for 1x/32. What If I need to protect 5x/32? :) In my opinion managing these is a nightmare and it also creates unnecessary amount of objects to IRR db. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Friday, July 7, 2023 5:36:19 PM Subject: Re: [db-wg] Route(6) objects
By doing this the internet will always (also under normal circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer defensive prefixes 1 - announce only aggregates to both providers 2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider 3 - when ddos ends, return to state 1 randy
Here the problem is "for longer defensive prefixes" For example in normal situation I advertise /32 to my ip transit providers. When DDoS happens then one of my providers will start advertisin 1x/48 of my /32 prefix to hi-jack the route from us and filter it.
i did not say that your provider advertised, did i?
By doing this the internet will always (also under normal circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer defensive prefixes
1 - announce only aggregates to both providers
2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider
3 - when ddos ends, return to state 1
randy
Hello Sorry, you didn't say. But starting to manually advertise /48 to my DDoS protection provider beats the purpose of automatic DDoS protection. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Randy Bush via db-wg" <db-wg@ripe.net> To: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Friday, July 7, 2023 6:05:53 PM Subject: Re: [db-wg] Route(6) objects
Here the problem is "for longer defensive prefixes" For example in normal situation I advertise /32 to my ip transit providers. When DDoS happens then one of my providers will start advertisin 1x/48 of my /32 prefix to hi-jack the route from us and filter it.
i did not say that your provider advertised, did i?
By doing this the internet will always (also under normal circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer defensive prefixes
1 - announce only aggregates to both providers
2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider
3 - when ddos ends, return to state 1
randy -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Did your ddos provider say that their upstreams required exact route6 matches for your announcements? The bgp session between you and your DDOS provider definitely won't require this, and the likelihood is that a covering /32 route6: object will be sufficient in many cases for your provider's providers. I.e. you won't have serious connectivity problems if there aren't exact matches for your /48s. In any event, this isn't really catered for in RPSL. Some organisations implement strict filtering on route objects; others loose. RPKI might be a better option, as it allows you to specify a prefix length range. See RFC 9319 for some suggestions. Nick Kaupo Ehtnurm via db-wg wrote on 07/07/2023 16:11:
Hello
Sorry, you didn't say. But starting to manually advertise /48 to my DDoS protection provider beats the purpose of automatic DDoS protection.
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]
----- Original Message ----- From: "Randy Bush via db-wg" <db-wg@ripe.net> To: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Friday, July 7, 2023 6:05:53 PM Subject: Re: [db-wg] Route(6) objects
Here the problem is "for longer defensive prefixes" For example in normal situation I advertise /32 to my ip transit providers. When DDoS happens then one of my providers will start advertisin 1x/48 of my /32 prefix to hi-jack the route from us and filter it. i did not say that your provider advertised, did i?
By doing this the internet will always (also under normal circumstances) prefer that one provider.
0 - register irr and rpki objects for aggregates and for longer defensive prefixes
1 - announce only aggregates to both providers
2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider
3 - when ddos ends, return to state 1 randy
Hello Did your ddos provider say that their upstreams required exact route6 matches for your announcements? --- No, but I was wondering what do other AS-s do with my ipv6 prefix, if they are using IRR filtering in bgp. I am not talking only about providers and providers providers. I am talking about all the AS-s in that participate in the global table and accept the full bgp table and filter it based on the IRR and/or ROA record. How can I be sure that they won't just drop my prefixes only because of the incorrect route6 object values? To eliminate the risk of my prefix getting blocked in some third party AS I would like to have correct route(6) objects, not almost correct (which technically are incorrect). In 99% cases you must have route(6) objects and it is good to also have ROA record to announce prefix to higher tier transit providers. But as far as I know you can't add "max length" to route6 object. Since route6 object is a must and ROA is a should and they ultimately fill the same purpose, than why isn't there a "max length" in route6 object? Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] From: "Nick Hilliard" <nick@foobar.org> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Friday, July 7, 2023 7:25:20 PM Subject: Re: [db-wg] Route(6) objects Did your ddos provider say that their upstreams required exact route6 matches for your announcements? The bgp session between you and your DDOS provider definitely won't require this, and the likelihood is that a covering /32 route6: object will be sufficient in many cases for your provider's providers. I.e. you won't have serious connectivity problems if there aren't exact matches for your /48s. In any event, this isn't really catered for in RPSL. Some organisations implement strict filtering on route objects; others loose. RPKI might be a better option, as it allows you to specify a prefix length range. See RFC 9319 for some suggestions. Nick Kaupo Ehtnurm via db-wg wrote on 07/07/2023 16:11: Hello Sorry, you didn't say. But starting to manually advertise /48 to my DDoS protection provider beats the purpose of automatic DDoS protection. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud [ mailto:kaupo@wavecom.ee | kaupo@wavecom.ee ] | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ [ http://www.wavecom.ee/ | http://www.wavecom.ee/ ] | [ http://www.wavecom.ee/ | www.wavecom.ee ] ] ----- Original Message ----- From: "Randy Bush via db-wg" [ mailto:db-wg@ripe.net | <db-wg@ripe.net> ] To: "Kaupo Ehtnurm via db-wg" [ mailto:db-wg@ripe.net | <db-wg@ripe.net> ] Sent: Friday, July 7, 2023 6:05:53 PM Subject: Re: [db-wg] Route(6) objects BQ_BEGIN Here the problem is "for longer defensive prefixes" For example in normal situation I advertise /32 to my ip transit providers. When DDoS happens then one of my providers will start advertisin 1x/48 of my /32 prefix to hi-jack the route from us and filter it. i did not say that your provider advertised, did i? BQ_BEGIN BQ_BEGIN By doing this the internet will always (also under normal circumstances) prefer that one provider. 0 - register irr and rpki objects for aggregates and for longer defensive prefixes 1 - announce only aggregates to both providers 2 - when ddosed, - do not change announcement of aggregate to non-mediating - deaggregate announcement to mediating provider 3 - when ddos ends, return to state 1 BQ_END BQ_END randy BQ_END
Dear Kaupo, others, (Speaking as individual working group contributor.) On Mon, Jul 10, 2023 at 10:06:30AM +0300, Kaupo Ehtnurm via db-wg wrote:
Since route6 object is a must and ROA is a should and they ultimately fill the same purpose, than why isn't there a "max length" in route6 object?
That's a good question! The specification of IRR 'route6:' objects pre-dates the specification of RPKI ROAs by a number of years. One explanation might be that the designers of RPSL-NG simply didn't think of it. Another aspect is that RPKI ROAs are used as an input into the RFC 6811 Origin Validation procedure (which yields invalid/valid/not-found as outcomes), but no such algorithm existed when RPSL-NG route/route6 objects were defined. I can see how RPKI ROAs and RPSL-NG route/route6 objects look kind of similar from a high level, but the devil is in the details: they do fulfill slightly different purposes. It's important to note that in recent years new insights arose how to make the best use of RPKI ROAs: last year's BCP 185 / RFC 9319 recommends to avoid using the maxLength attribute in RPKI ROAs. Porting 'maxLength' functionality to RPSL-NG route/route6 objects would represent a significant community effort: people would need to write an Internet-Draft to specify what the field really means, and lots of software toolchains would need updating. Given that maxLength in RPKI ROAs was not universially perceived as a good idea, I'm not very optimistic that porting such functionality to the 'legacy' IRR system is worth the effort. Kind regards, Job
Hello Thank you very much for the explanation. But I think we have steered away a little bit from my original question. As I can conclude from all the answers earlier, then still my only option if I want my ip transit provider to be able to advertise some /48 within my /32 at random times and for random durations is using /32 as route6 object and hope that everyone in the internet filters "2001:1234::/32 le 48 permit" or "2001:1234::/32 eq 48 permit" instead of "2001:1234::/32 permit"? Or actually make the 65536 route6 objects (for each of the /48 that fits into that /32)? Or is there a third possibility instead hoping that AS-s from all over the internet are familiar with this kind of issue and allow /48 prefixes into their routers instead of exact /32 prefix (although the route6 object states that our provider should advertise only /32) or making unnecessary amount(65536 objects for 1x/32) of route6 objects? I ultimatelly want my ip transit provider to be able to advertise different /48 prefixes at random times for random durations. And want it to pass IRR filtering also, not just rpki filtering in different ASs across the globe. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Job Snijders" <job@sobornost.net> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Nick Hilliard" <nick@foobar.org>, "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Monday, July 10, 2023 2:18:57 PM Subject: Re: [db-wg] Route(6) objects Dear Kaupo, others, (Speaking as individual working group contributor.) On Mon, Jul 10, 2023 at 10:06:30AM +0300, Kaupo Ehtnurm via db-wg wrote:
Since route6 object is a must and ROA is a should and they ultimately fill the same purpose, than why isn't there a "max length" in route6 object?
That's a good question! The specification of IRR 'route6:' objects pre-dates the specification of RPKI ROAs by a number of years. One explanation might be that the designers of RPSL-NG simply didn't think of it. Another aspect is that RPKI ROAs are used as an input into the RFC 6811 Origin Validation procedure (which yields invalid/valid/not-found as outcomes), but no such algorithm existed when RPSL-NG route/route6 objects were defined. I can see how RPKI ROAs and RPSL-NG route/route6 objects look kind of similar from a high level, but the devil is in the details: they do fulfill slightly different purposes. It's important to note that in recent years new insights arose how to make the best use of RPKI ROAs: last year's BCP 185 / RFC 9319 recommends to avoid using the maxLength attribute in RPKI ROAs. Porting 'maxLength' functionality to RPSL-NG route/route6 objects would represent a significant community effort: people would need to write an Internet-Draft to specify what the field really means, and lots of software toolchains would need updating. Given that maxLength in RPKI ROAs was not universially perceived as a good idea, I'm not very optimistic that porting such functionality to the 'legacy' IRR system is worth the effort. Kind regards, Job
Look, you can never be certain that 100% of networks are going to accept your prefixes but for DDoS that shouldn't matter as others have pointed out. What I can say is please don't create 65536 route6 objects or otherwise I feel like we are going to have to start discussion about a policy to prevent people doing that. Also why do you need them to be advertised as /48s? If you just need them to be more specific than a /32 couldn't you just do /33s, /34s, /35s, /36s, or something like that? -Cynthia On Mon, Jul 10, 2023 at 2:13 PM Kaupo Ehtnurm via db-wg <db-wg@ripe.net> wrote:
Hello
Thank you very much for the explanation. But I think we have steered away a little bit from my original question.
As I can conclude from all the answers earlier, then still my only option if I want my ip transit provider to be able to advertise some /48 within my /32 at random times and for random durations is using /32 as route6 object and hope that everyone in the internet filters "2001:1234::/32 le 48 permit" or "2001:1234::/32 eq 48 permit" instead of "2001:1234::/32 permit"? Or actually make the 65536 route6 objects (for each of the /48 that fits into that /32)? Or is there a third possibility instead hoping that AS-s from all over the internet are familiar with this kind of issue and allow /48 prefixes into their routers instead of exact /32 prefix (although the route6 object states that our provider should advertise only /32) or making unnecessary amount(65536 objects for 1x/32) of route6 objects?
I ultimatelly want my ip transit provider to be able to advertise different /48 prefixes at random times for random durations. And want it to pass IRR filtering also, not just rpki filtering in different ASs across the globe.
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]
----- Original Message ----- From: "Job Snijders" <job@sobornost.net> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Nick Hilliard" <nick@foobar.org>, "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Monday, July 10, 2023 2:18:57 PM Subject: Re: [db-wg] Route(6) objects
Dear Kaupo, others,
(Speaking as individual working group contributor.)
On Mon, Jul 10, 2023 at 10:06:30AM +0300, Kaupo Ehtnurm via db-wg wrote:
Since route6 object is a must and ROA is a should and they ultimately fill the same purpose, than why isn't there a "max length" in route6 object?
That's a good question!
The specification of IRR 'route6:' objects pre-dates the specification of RPKI ROAs by a number of years. One explanation might be that the designers of RPSL-NG simply didn't think of it.
Another aspect is that RPKI ROAs are used as an input into the RFC 6811 Origin Validation procedure (which yields invalid/valid/not-found as outcomes), but no such algorithm existed when RPSL-NG route/route6 objects were defined. I can see how RPKI ROAs and RPSL-NG route/route6 objects look kind of similar from a high level, but the devil is in the details: they do fulfill slightly different purposes.
It's important to note that in recent years new insights arose how to make the best use of RPKI ROAs: last year's BCP 185 / RFC 9319 recommends to avoid using the maxLength attribute in RPKI ROAs.
Porting 'maxLength' functionality to RPSL-NG route/route6 objects would represent a significant community effort: people would need to write an Internet-Draft to specify what the field really means, and lots of software toolchains would need updating. Given that maxLength in RPKI ROAs was not universially perceived as a good idea, I'm not very optimistic that porting such functionality to the 'legacy' IRR system is worth the effort.
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hello I have never said that I want 100% of the world to accept my ipv6 /48 prefixes. I am sorry if I haven't been clear enough. But again I will try to explain my situation. I am about 10% certain that ASs that filter their BGP table according to IRR info would accept the /48 prefixes that have /32 route6 object(In good conscience and bearing in mind BGP security risks I wouldn't accept these prefixes). But I would be 90% certain that with /48 route6 object the /48 prefixes get accepted. Do you see the difference here? I am talking about if some AS-s filter their bgp table according to IRR info, then how does plain /32 route6 object cover all the /48s within that /32 prefix? If theoretically it would be possible then I would just configure "::/0 AS1234" and that would cover everything right? As I am trying to explain then correct records in my opinion greatly increases the odds of my prefix being accepted world wide. Maybe they can, maybe they can't advertise /33, /34 etc... I would like the provider to hijack most specific prefix in order to avoid the unnecessary redirection of other customers traffic that fit into that /33 or /34 etc. But no need to further discuss this subject. I will just use /32 route6 object for all the /48 that fit that /32. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Cynthia Revström" <me@cynthia.re> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "DB-WG" <db-wg@ripe.net> Sent: Monday, July 10, 2023 3:36:42 PM Subject: Re: [db-wg] Route(6) objects Look, you can never be certain that 100% of networks are going to accept your prefixes but for DDoS that shouldn't matter as others have pointed out. What I can say is please don't create 65536 route6 objects or otherwise I feel like we are going to have to start discussion about a policy to prevent people doing that. Also why do you need them to be advertised as /48s? If you just need them to be more specific than a /32 couldn't you just do /33s, /34s, /35s, /36s, or something like that? -Cynthia On Mon, Jul 10, 2023 at 2:13 PM Kaupo Ehtnurm via db-wg <db-wg@ripe.net> wrote:
Hello
Thank you very much for the explanation. But I think we have steered away a little bit from my original question.
As I can conclude from all the answers earlier, then still my only option if I want my ip transit provider to be able to advertise some /48 within my /32 at random times and for random durations is using /32 as route6 object and hope that everyone in the internet filters "2001:1234::/32 le 48 permit" or "2001:1234::/32 eq 48 permit" instead of "2001:1234::/32 permit"? Or actually make the 65536 route6 objects (for each of the /48 that fits into that /32)? Or is there a third possibility instead hoping that AS-s from all over the internet are familiar with this kind of issue and allow /48 prefixes into their routers instead of exact /32 prefix (although the route6 object states that our provider should advertise only /32) or making unnecessary amount(65536 objects for 1x/32) of route6 objects?
I ultimatelly want my ip transit provider to be able to advertise different /48 prefixes at random times for random durations. And want it to pass IRR filtering also, not just rpki filtering in different ASs across the globe.
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]
----- Original Message ----- From: "Job Snijders" <job@sobornost.net> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Nick Hilliard" <nick@foobar.org>, "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Monday, July 10, 2023 2:18:57 PM Subject: Re: [db-wg] Route(6) objects
Dear Kaupo, others,
(Speaking as individual working group contributor.)
On Mon, Jul 10, 2023 at 10:06:30AM +0300, Kaupo Ehtnurm via db-wg wrote:
Since route6 object is a must and ROA is a should and they ultimately fill the same purpose, than why isn't there a "max length" in route6 object?
That's a good question!
The specification of IRR 'route6:' objects pre-dates the specification of RPKI ROAs by a number of years. One explanation might be that the designers of RPSL-NG simply didn't think of it.
Another aspect is that RPKI ROAs are used as an input into the RFC 6811 Origin Validation procedure (which yields invalid/valid/not-found as outcomes), but no such algorithm existed when RPSL-NG route/route6 objects were defined. I can see how RPKI ROAs and RPSL-NG route/route6 objects look kind of similar from a high level, but the devil is in the details: they do fulfill slightly different purposes.
It's important to note that in recent years new insights arose how to make the best use of RPKI ROAs: last year's BCP 185 / RFC 9319 recommends to avoid using the maxLength attribute in RPKI ROAs.
Porting 'maxLength' functionality to RPSL-NG route/route6 objects would represent a significant community effort: people would need to write an Internet-Draft to specify what the field really means, and lots of software toolchains would need updating. Given that maxLength in RPKI ROAs was not universially perceived as a good idea, I'm not very optimistic that porting such functionality to the 'legacy' IRR system is worth the effort.
Kind regards,
Job
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi, On Mon, Jul 10, 2023 at 03:13:16PM +0300, Kaupo Ehtnurm via db-wg wrote:
As I can conclude from all the answers earlier, then still my only option if I want my ip transit provider to be able to advertise some /48 within my /32 at random times and for random durations is using /32 as route6 object and hope that everyone in the internet filters "2001:1234::/32 le 48 permit" or "2001:1234::/32 eq 48 permit" instead of "2001:1234::/32 permit"? Or actually make the 65536 route6 objects (for each of the /48 that fits into that /32)? Or is there a third possibility instead hoping that AS-s from all over the internet are familiar with this kind of issue and allow /48 prefixes into their routers instead of exact /32 prefix (although the route6 object states that our provider should advertise only /32) or making unnecessary amount(65536 objects for 1x/32) of route6 objects?
I think you missed my point that there is no way you can ensure that A Random Network out there will accept any/all /48s from your /32. Router memory is costly, and deaggregation eats up costly memory to the point that people are forced to decide between "I need to buy a new router, to carry someone else's deaggreated prefixes, which I'm not paid for" or "just drop /48s, lots of money saved". Your transit ISPs are paid by you to accept and propagate what you agree between each other. Most other parties are not contractually bound, and as such, free to do what is reasonable for them. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi,
Your transit ISPs are paid by you to accept and propagate what you agree between each other. Most other parties are not contractually bound, and as such, free to do what is reasonable for them.
In many cases, the traffic will hit one of the parties that do carry the more specifics, and will follow that path anyway. The edge network may only see the /32, but as long as the transit networks have the /48s, that’s where the traffic will end up. Cheers, Sander
there is no way you can ensure that A Random Network out there will accept any/all /48s from your /32.
there is no way to ensure that a random network out there will accept X for all values of X randy
Kaupo Ehtnurm wrote on 10/07/2023 08:06:
No, but I was wondering what do other AS-s do with my ipv6 prefix, if they are using IRR filtering in bgp. I am not talking only about providers and providers providers. I am talking about all the AS-s in that participate in the global table and accept the full bgp table and filter it based on the IRR and/or ROA record. How can I be sure that they won't just drop my prefixes only because of the incorrect route6 object values? To eliminate the risk of my prefix getting blocked in some third party AS I would like to have correct route(6) objects, not almost correct (which technically are incorrect).
Most transit providers accept <= the route/route6 prefix length. Some IXPs filter strictly. The best thing to do is to test this out and see if announcing an upstream /48 works. You can use e.g. ripe atlas or other measurement networks to test connectivity paths while upstream mitigation is in place, both with a /48 IRRDB entry for the announcement in question, and without. This should give you a clear idea about whether using individual /48s is worth the effort (I suspect the answer is probably not). Nick
Hello I was hoping that somebody is experienced with this situation and could advise me, what the correct way by-the-book would be. But I will just accept creating /32 route6 object and hope that the /48s won't be filtered out only because of the inaccuracy of route6 object in different ASs across the globe. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] From: "Nick Hilliard" <nick@foobar.org> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> Sent: Wednesday, July 12, 2023 3:51:00 PM Subject: Re: [db-wg] Route(6) objects Kaupo Ehtnurm wrote on 10/07/2023 08:06: No, but I was wondering what do other AS-s do with my ipv6 prefix, if they are using IRR filtering in bgp. I am not talking only about providers and providers providers. I am talking about all the AS-s in that participate in the global table and accept the full bgp table and filter it based on the IRR and/or ROA record. How can I be sure that they won't just drop my prefixes only because of the incorrect route6 object values? To eliminate the risk of my prefix getting blocked in some third party AS I would like to have correct route(6) objects, not almost correct (which technically are incorrect). Most transit providers accept <= the route/route6 prefix length. Some IXPs filter strictly. The best thing to do is to test this out and see if announcing an upstream /48 works. You can use e.g. ripe atlas or other measurement networks to test connectivity paths while upstream mitigation is in place, both with a /48 IRRDB entry for the announcement in question, and without. This should give you a clear idea about whether using individual /48s is worth the effort (I suspect the answer is probably not). Nick
Kaupo Ehtnurm wrote on 12/07/2023 14:43:
I was hoping that somebody is experienced with this situation and could advise me, what the correct way by-the-book would be.
a /32 will work just fine. The IRRDB design is too simplistic to model even basic inter-domain routing policies properly, so there is no "by the book" option which will work without breaking something else, badly. 65k /48 entries will break things on the internet. If you have a /29, then that's 512k entries, which will cause even more trouble. Transit providers and DDOS mitigation companies understand this, and take it into account. Your only concern in this situation should be whether your DDOS mitigation provider will accept more-specifics, and this will depend on the relationship they have with their upstreams. I.e. it's not RIPE DB-WG you need to check this out with, it's your DDOS provider. Nick
But I will just accept creating /32 route6 object and hope that the /48s won't be filtered out only because of the inaccuracy of route6 object in different ASs across the globe.
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | www.wavecom.ee <http://www.wavecom.ee/>
------------------------------------------------------------------------ *From: *"Nick Hilliard" <nick@foobar.org> *To: *"Kaupo Ehtnurm" <kaupo@wavecom.ee> *Cc: *"Kaupo Ehtnurm via db-wg" <db-wg@ripe.net> *Sent: *Wednesday, July 12, 2023 3:51:00 PM *Subject: *Re: [db-wg] Route(6) objects
Kaupo Ehtnurm wrote on 10/07/2023 08:06:
No, but I was wondering what do other AS-s do with my ipv6 prefix, if they are using IRR filtering in bgp. I am not talking only about providers and providers providers. I am talking about all the AS-s in that participate in the global table and accept the full bgp table and filter it based on the IRR and/or ROA record. How can I be sure that they won't just drop my prefixes only because of the incorrect route6 object values? To eliminate the risk of my prefix getting blocked in some third party AS I would like to have correct route(6) objects, not almost correct (which technically are incorrect).
Most transit providers accept <= the route/route6 prefix length. Some IXPs filter strictly.
The best thing to do is to test this out and see if announcing an upstream /48 works. You can use e.g. ripe atlas or other measurement networks to test connectivity paths while upstream mitigation is in place, both with a /48 IRRDB entry for the announcement in question, and without. This should give you a clear idea about whether using individual /48s is worth the effort (I suspect the answer is probably not).
Nick
Peace, On Thu, 6 Jul 2023, 8:28 pm Randy Bush via db-wg, <db-wg@ripe.net> wrote:
you can do it yourself
announce the more specifics to the provider who gives ddos mediation, and the less specific, /32, to the non-protecting provider
In doing so, please keep in mind that a small portion of the inbound traffic could/would still flow through the non-protecting provider, because it is not guaranteed that the entire Internet would prefer the more specific. Most of the time, it's not an issue, at times though, this is a source of big problems. -- Töma
Hey Kaupo, Typically there are two ways of handling route/route6 objects, (1) A provider/peer will take them literally and won't allow smaller prefixes (for example if I was to do a /22, then the provider who is building the filters may not allow a /24 from that /22). (However this practice seems to be less common) (2) The provider/peer will implicitly allow from that /22 all the way to a /24. (or on IPv6 /32 to /48). In this case you just need to create a matching /32 route6 and almost all peers and providers will allow more specifics of that /32 to be originated from that ASN as well. IRR does not really have a way to limit the "more specific" risk. However with RPKI adoption increasingly being deployed, a RPKI Invalid (due to max-length) won't get that far anyway, at least in transit carriers. tl;dr just make another route6 for your DDoS mitigation providers ASN and you should be fine for almost all cases. On Thu, Jul 6, 2023 at 8:14 AM Kaupo Ehtnurm via db-wg <db-wg@ripe.net> wrote:
Hello
For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: "2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: "2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare.
If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have?
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | www.wavecom.ee --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hello "you should be fine for almost all cases" - the "should" part is my problem. I cannot be certain that all the AS-s in the global internet will accept all the /48 routes of that /32 route6 object. Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] ----- Original Message ----- From: "Ben Cartwright-Cox" <ripencc@benjojo.co.uk> To: "Kaupo Ehtnurm" <kaupo@wavecom.ee> Cc: "db-wg" <db-wg@ripe.net> Sent: Friday, July 7, 2023 4:54:59 PM Subject: Re: [db-wg] Route(6) objects Hey Kaupo, Typically there are two ways of handling route/route6 objects, (1) A provider/peer will take them literally and won't allow smaller prefixes (for example if I was to do a /22, then the provider who is building the filters may not allow a /24 from that /22). (However this practice seems to be less common) (2) The provider/peer will implicitly allow from that /22 all the way to a /24. (or on IPv6 /32 to /48). In this case you just need to create a matching /32 route6 and almost all peers and providers will allow more specifics of that /32 to be originated from that ASN as well. IRR does not really have a way to limit the "more specific" risk. However with RPKI adoption increasingly being deployed, a RPKI Invalid (due to max-length) won't get that far anyway, at least in transit carriers. tl;dr just make another route6 for your DDoS mitigation providers ASN and you should be fine for almost all cases. On Thu, Jul 6, 2023 at 8:14 AM Kaupo Ehtnurm via db-wg <db-wg@ripe.net> wrote:
Hello
For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: "2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: "2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare.
If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have?
Lugupidamisega / Best regards,
Kaupo Ehtnurm
Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo@wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | www.wavecom.ee --
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi, On Fri, Jul 07, 2023 at 05:35:40PM +0300, Kaupo Ehtnurm via db-wg wrote:
"you should be fine for almost all cases" - the "should" part is my problem. I cannot be certain that all the AS-s in the global internet will accept all the /48 routes of that /32 route6 object.
You certainly can't be certain of that, ever. I, for one, might decide that I will never ever accept /48s out of /32 allocations, and there is nothing you can do - except give me money - to make me change my mind. ... but this is highly non-relevant for "you will be DDoSed by many many networks out in the world" (D = distributed), as long as *enough* networks high enough in the routing food chain will accept the /48. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (9)
-
Ben Cartwright-Cox -
Cynthia Revström -
Gert Doering -
Job Snijders -
Kaupo Ehtnurm -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Töma Gavrichenkov