well-known Anycast prefixes

Tue Mar 19 21:03:50 UTC 2019

> On Mar 19, 2019, at 1:55 PM, Frank Habicht <geier at geier.ne.tz> wrote:
> 
> Hi,
> 
> On 19/03/2019 23:13, Bill Woodcock wrote:
>> Generally, static lists like that are difficult to maintain when
>> they’re tracking multiple routes from multiple parties.
> 
> agreed.
> and on the other extreme, communities are very much prone to abuse.
> I guess I could set any community on a number of prefixes (incl anycast)
> right now....
> 
> So, I think a (moderated) BGP feed of prefixes a'la bogon from a trusted
> {cymru[1], pch[2], ...}  could be good [3].

Ok, so, just trying to flesh out the idea to something that can be usefully implemented…

1) People send an eBGP multi-hop feed of well-known-community routes to a collector, or send them over normal peering sessions to something that aggregates…

2) Because those are over BGP sessions, the counterparty is known, and can be asked for details or clarification by the “moderator,” or the sender could log in to an interface to add notes about the prefixes, as they would in the IXPdir or PeeringDB.

3) Known prefixes from known parties would be passed through in real-time, as they were withdrawn and restored.

4) New prefixes from known parties would be passed through in real-time if they weren’t unusual (large/overlapping something else/previously announced by other ASNs).

5) New prefixes from known parties would be “moderated” if they were unusual.

6) New prefixes from new parties would be “moderated” to establish that they were legit and that there was some documentation explaining what they were.

7) For anyone who really didn’t want to provide a community-tagged BGP feed, a manual submission process would exist.

8) Everything gets published as a real-time eBGP feed.

9) Everything gets published as HTTPS-downloadable JSON.

10) Everything gets published as a human-readable (and crawler-indexable) web page.

Does that sound about right?

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190319/d56eced5/attachment.sig>