[db-wg] Route(6) objects

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 at wavecom.ee | +372 5685 0002 
Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ] 


From: "Nick Hilliard" <nick at foobar.org> 
To: "Kaupo Ehtnurm" <kaupo at wavecom.ee> 
Cc: "Kaupo Ehtnurm via db-wg" <db-wg at 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 at wavecom.ee | kaupo at 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 at ripe.net | <db-wg at ripe.net> ] To: "Kaupo Ehtnurm via db-wg" [ mailto:db-wg at ripe.net | <db-wg at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/db-wg/attachments/20230710/4c2208e8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo signatuur.png
Type: image/png
Size: 3077 bytes
Desc: not available
URL: </ripe/mail/archives/db-wg/attachments/20230710/4c2208e8/attachment.png>