Subject: [Sidrops] as23456 in ROAs

From: Jay Borkenhagen <[email-masked]>
Date: Sun, 31 Mar 2019 15:16:08 -0400

Hi Ruediger,
Hi SIDROps,

With respect to Ruediger's second presentation at IETF104 last week,
in which he mentioned (among other things) finding as23456 as the
authorized ASN in some published ROAs:

I checked those ROAs (well, actually their VRPs) and found that in
each current case, the same prefix has been authorized also to
originate in an autonomous system number greater than 65535.  Details
below.

Interestingly, each of these instances comes from the LACNIC region.
Perhaps there exists some documentation or folklore in that region
that has led some operators there to publish an additional ROA
authorizing AS23456 if they hold an ASN > 65535.  Maybe SIDROps
friends at lacnic.net can investigate and report back?

[
FWIW, I can imagine some tortuous logic that might lead someone to
publish such a ROA:

 Resource Holder: Hey ISP, if you look here (some RPKI vantage point)
   you'll see that my prefix is to originate only in [huge ASN].

 ISP: Sure, but when I look in the routing tables in my [ancient] kit,
   I see your prefix originating in as23456.  So I blocked it
   manually. 

 Resource Holder: Umm, wait just a sec, and you'll soon see my new ROA
   authorizing as23456, too.  Then please accept it.

Not saying I like it or would recommend taking steps to work around
networks that still do not grok 4B-ASNs in 2019, but perhaps an
as23456 ROA is not totally without motivation.
]

=== 138.185.76.0/22 ===
AS23456,138.185.76.0/22,24,lacnic
AS263824,138.185.76.0/22,24,lacnic

=== 170.84.108.0/22 ===
AS23456,170.84.108.0/22,24,lacnic
AS263248,170.84.108.0/22,24,lacnic

=== 170.254.16.0/22 ===
AS23456,170.254.16.0/22,24,lacnic
AS263824,170.254.16.0/22,24,lacnic

=== 190.2.17.0/24 ===
AS23456,190.2.17.0/24,24,lacnic
AS264638,190.2.17.0/24,24,lacnic

=== 190.210.206.0/24 ===
AS23456,190.210.206.0/24,24,lacnic
AS262264,190.210.206.0/24,24,lacnic
AS264638,190.210.206.0/24,24,lacnic

=== 191.102.48.0/21 ===
AS23456,191.102.48.0/21,21,lacnic
AS263177,191.102.48.0/21,21,lacnic

=== 200.68.114.0/24 ===
AS23456,200.68.114.0/24,24,lacnic
AS265807,200.68.114.0/24,24,lacnic
AS264638,200.68.114.0/24,24,lacnic

=== 200.192.236.0/22 ===
AS23456,200.192.236.0/22,24,lacnic
AS263248,200.192.236.0/22,22,lacnic
AS263248,200.192.236.0/22,24,lacnic

=== 2803:980::/32 ===
AS23456,2803:980::/32,32,lacnic
AS263248,2803:980::/32,48,lacnic
AS263248,2803:980::/32,32,lacnic

Thanks.

					Jay B.

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 31 Mar 2019 18:55:10 -0700

> originate in an autonomous system number greater than 65535.  Details

<snip>

> as23456 ROA is not totally without motivation.

So, I thought one of the requirements for doing BGPSEC (maybe not OV
though?) was: "must have 4-byte capability"
clearly signing a ROA for: "shared asn" is a poor plan :( but really
you shouldn't ever see 23456 in a secure path... (again, sure that's
BGPSEC not OV)

funny though.
-chris

---

From: Randy Bush <[email-masked]>
Date: Sun, 31 Mar 2019 20:26:19 -0700

> you shouldn't ever see 23456 in a secure path... (again, sure that's

do routers which do not support 4-byte asns support rpki policy to say
"mark announcements where the origin is as23456 as notfound?"

randy