> On Mar 19, 2019, at 1:55 PM, Frank Habicht <ge...@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
signature.asc
Description: Message signed with OpenPGP
