-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday, February 27th, 2026 at 15:38, Bryton Herdes <bryton@cloudflare.com> wrote: Hey Bryton
I don't want to de-rail, but two of these AS-SET use-cases are extremely frightening and need better solutions.
I am in agreement with you. I'm not saying they're fantastic, my intent was just to provide some use cases because nobody else has been. I don't like when people make statements without providing either real life use cases and/or real life data, I always try to provide one or the other or both.
https://iepg.org/2019-03-24-ietf104/blackholing_reconsidered_ietf104_snijder... is
Interesting read; maybe Job can clear it up for me... * Slide 8 -> do all these things need to be logically AND'ed together before the RTBH is accepted? * The summary on the last slide seems to suggest "yes" Again, a real world use case that we have... A customer has two connections to us in active/standby or primary/secondary, whatever you want to call it, but traffic always goes to one link. So all the DDoS traffic is going there, it's congested, maybe it's flapping up and down due to BGP timeouts, and the result is that they can't get a BGP update to us over this link to initiate RTBH. They can send us RTBH via the 2nd link, but it's not the best path to them, so in Job's design, would we accept the RTBH route?
2. TE;
I really dislike these. Are you bypassing origin lookup entirely for the announcements and not doing any ROV on a longer-prefix, just IRR filtering? Allowing this type of TE is a slippery slope. With the current tools we have, your customers need to just sign their /24 ROA along with the /22; we lack the internal vs. external distinction to do anything else. Again, these longer-prefix hijacks are also very real and extremely painful if accepted by a large enough AS.
I am in agreement that it's not pretty, but also: * How is this IRR filtering less effective than for prefixes which have no ROA? * The idea of creating ROAs for the longer /24s is exactly what people don't want, because that would allow others to hijack a more specific of the /22 (e.g. a /24) and that hijack would be RPKI valid! As far as I can see, the problem here is that with the current tooling we have there is no "optimal way"; one can optimse for A at the sacrifice of B, or one can optimise for B at the sacrifice of A. Cheers, James. -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsG5BAEBCgBtBYJposKGCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0 aW9ucy5vcGVucGdwanMub3JnQ4jCLc88wSiojK4+NW72afIJr1+jUIIT+x+U qmK/Hx4WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAHSAQAKHYygHn/6NF7G2f 8s9dFLc5XVmgw9klRi6l8+3E4glBqrcAf/jOmrnRST3C1RbEo+OQsAdJP5YO gMfmZQglJZwbcAMI4FMdvjWEvdxqiJyZouEe3zRQ6FF28qpHNf9njlia7ZSl 0aBkj6tctiW9VQCgAmz6piInZhBhslIDg1ycIxkZotwt93MjsKjntjwfgDdc n0yeEI+GnNsoi78V8FFvGgfBgJ7ne3H9ey4bSzV+MxjOiVT80Rc7D01eaJUf tYS0X/FEp27h43Xj33cIHRaT2paDJddS1yClHZ5M1bEESNFcoHEJjvye1NAv s4fPf2m1BKZBu+UODc4drO2wmKe8ohNF0ec+jtPq3cQA/aDoeibXiOm+pu4i qhUwWAz+8XWhDhv4556Ghf98YF/J4SmUCjgOYDEYFaHLPuxqlJoVx1n/ETFE k/RuQxSSXlH4nUFGNpEFMHUcabqDO6t2n53I+4WjmZuqe/diodqm0L3EZEnP cIw9YtemuJ7htwuiNyjp7tfcJekfNcKJ0I+NIwTEK846lZZcLMmMKtEESIoB VC86y7/+rRPVh42FMVfwbwc+ab1+4T95cvEs2QzDNwkLBj574qY/v6P2Ol9k 3hN6SGohIuisKS44IGdxSTLMNYc5m1H1Fo3OHzfWZS0Nw4mgGIxIDzedRISU fwE/igEW =Zyu2 -----END PGP SIGNATURE-----