Re: RTBH Support Across the Industry

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2029725453903772102==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------0f1fc44dfc45511fff8f66f5f1bd7dc3b90f8848ef7d87d5fc9c05bffce93312";
 charset=utf-8

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------0f1fc44dfc45511fff8f66f5f1bd7dc3b90f8848ef7d87d5fc9c05bffce93312
Content-Type: multipart/mixed;boundary=---------------------e3d4204d8dce10508ee638dab70c0b0b

-----------------------e3d4204d8dce10508ee638dab70c0b0b
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

On Wednesday, July 29th, 2026 at 11:37, Job Snijders via NANOG <nanog@list=
s.nanog.org> wrote:
>
> On Tue, Jul 28, 2026 at 12:57:42PM -0400, Bryton Herdes via NANOG wrote:
> > My number one problem with RTBH today is a lack of route origin
> > validation.
> =


> ... and then you outline a plan to bypass route origin validation??? :-)

I was formerly of the opinion that such a knob from vendors was a good ide=
a, but I've been thinking it over recently and I've changed my mind. I thi=
nk we shouldn't be going down this road. Sorry for the length, but to unde=
rstand why we have to go back to the start.

I think the important question is: what do we want to protect against?

1. Misconfigurations / misoriginations (the origin AS doesn't match the RO=
A)
2. Intentional origin hijacks (attacker fakes the origin AS to match the R=
OA)

I think this is important for two reasons:

A. ROAs validate who *MAY* originate a prefix, they don't validate who *IS=
* originating a prefix. ASPAs validate which ASNs *MAY* forward a BGP anno=
uncement, they don't validate which ASNs *ARE* forwarding it. Therefore RO=
As and ASPAs can only protect against (1). To protect against (2) we need =
something which cryptographically validates the AS_PATH attribute (like BG=
Psec or SCION or similar), but we don't have anything like that widely ava=
ilable today.

B. IMO >95% of the routing issues we want to stop are due to misconfigurat=
ions/accidents, whereas intentional hijacks only account for a fraction of=
 the issues. I'm not saying that intentional hijacks don't happen or aren'=
t important, I'm saying we don't have the tools to fight them yet, and the=
y are the exception. But we do have the tools to fight the common case, so=
 let's use those tools to fight the common case in the most effective way,=
 and not try to bend them to also fight the corner case.

A key argument for this knob is that a longer maxLength risks intentional =
hijacks. Because ROAs can't protect against intentional origin hijacks, we=
're only interested in whether the BGP route origin matches the ROA origin=
, if it doesn't match then the maxLength has no bearing here (only when th=
e two match). So the conventional wisdom of "a longer maxLength risks hija=
cks" is not true, because ROAs don't protect against intentional hijacks, =
only against misoriginations, and in this latter case the maxLength actual=
ly plays no role.

So if we're just protecting against misoriginations, then IMO the prefix o=
wner should be the one setting their ROA maxLength to include longer prefi=
xes, *iff* they are someone that uses RTBH or a similar service.

If we add a knob to ignore maxLength, several bad things happen, which don=
't happen if instead the prefix owner increases their maxLength iff requir=
ed:

* Every network which implements this knob now ignores my maxLength, even =
though I know best for my prefixes. And not just for my prefixes, for *the=
 entire DFZ*. The prefix length decision has been taken away from the very=
 people who know best.

* This is something which will be implemented opaquely; most networks don'=
t publicly document their BGP filtering policy, and most networks don't ha=
ve a public looking glass, but now that networks will start accepting pref=
ixes more specific than my ROA permits if the RTBH community is attached. =
But there is no way to see if this is happening, or know why it's happenin=
g, and I *explicitly signalled* in my ROA that this should not be happenin=
g. Troubleshooting this will be a nightmare.

* I'm a hijacker; I announce a more specific prefix than the ROA's maxLeng=
th, with a forged origin to match the ROA, with the RTBH community attache=
d; my hijack will be more widely accepted *because of this knob* than if i=
t didn't have the RTBH community attached, because without the RTBH commun=
ity it would fail the maxLength check. So this knob actually makes sub-pre=
fix origin hijacks attacks more damaging.

* Even if I announce someone else's prefix and fake the origin, but stick =
to the maxLength of their ROA, and the owner is also announcing the same p=
refix + length + origin (two competing routes); for most networks this wil=
l be absolutely devastating. The presence of a competing route doesn't pro=
vide protection against intentional origin hijacks that are ROA valid due =
to maxLength. The reason is that apart from the top ~20 most interconnecte=
d networks on bgp.tools, the average network is not that well connected an=
d thus my equal length intentional hijack will win in many networks (espec=
ially if I'm in a different part of the world to the victim, my route will=
 very likely win in all the networks in my region).


Now let's consider increasing the maxLength on ROAs to support RTBH:

* "Intentional origin hijacks are now easier"; no, there is no change here=
 due to the lack of verification of the AS_PATH attribute, also see my poi=
nt above about hijacks of an equal length prefix, you don't even need to h=
ijack a more specific to completely hijack the traffic for a prefix.

* We no longer have to skip ROA validation and fall back to IRR based vali=
dation (which helps with deprecating IRR based filters).

* We don't make more specific hijacks more effective when they are tagged =
as RTBH routes.

* As the ROA owner I remain in control of how my prefixes are validated.


I think the best way to validate RTBH routes might be maxLength + ASPA + R=
FC9234 (i.e., the same way as we plan to validate non-RTBH routes).

Cheers,
James.
(Again, sorry for the length)
-----------------------e3d4204d8dce10508ee638dab70c0b0b--

--------0f1fc44dfc45511fff8f66f5f1bd7dc3b90f8848ef7d87d5fc9c05bffce93312
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsG5BAEBCgBtBYJqai5sCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn+4Lh4n/MoMpaVm1ZAes8FKaYtB2HYG35olkf
Cd7rUwIWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAA3asP/3mLCaWEM2H6pjBL
7OfWZ6z1zxbS5SDmutTQFBiLkaAet7u4klGDI8PFLqyT/lQ2Jxl0tr2SqjWx
SQWfa4rF6xdd2UshbfvNhJQDiMQ+4HlE5PeBXhSHImF0T2CWMIkrlHRe6n9H
9jn+xQpuGkIME7R/668gKFCSOwkoYiYg3JS2ntroKlB+OtjeutYrwi+zY0rl
WRn/b4+YCOSmdTWeaeOU8eiXzDteRGAgq4Zxgvx6dOLFZRVt0hTawt8mtmxh
p45FIFLqv21TH4QXwJEkj0o/x46L+bVbp0sWlyXAfAWr7L+cM8oUzB9UMbuV
V4s7YP+GOgE1EKGNkwWs1Pyl1JH8mmTN7bjDaJhodDSNxwFc6yw16CRhqo+/
tZvmVaNsQwOjPczUdqKmndkqpbtRCbqULEgso9KyACCglzBAfnen16jrEeVi
FN3P1Hx6d5sRp2OLTA/Nm8YGthP/A7bHVsmmUrBWte8rVPhQt7J+mWaY7Xit
DLlULz3YGxMZxZveo/QlGYWaGK3lvPU9ozLY7dTPzzOcSLepngO5FDDsnWYU
p9JCGAMSALUna8CpNc31kmA18Hd/vDC8cCUgqx7YNMXbBNjGnX+M45gtrlQz
Tw/GuMjYEBW69HLsbFBQV3zU5MUbW60fHDUuad2mjtqSxyh67J0M9VPxdsyH
LyfZN1Ku
=ExG0
-----END PGP SIGNATURE-----


--------0f1fc44dfc45511fff8f66f5f1bd7dc3b90f8848ef7d87d5fc9c05bffce93312--


--===============2029725453903772102==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/[email protected]/message/Q2GYREV3ZGUIRHF7SHXUPRGFAKRP4WQ4/
--===============2029725453903772102==--