Mark own ASN as transit-free (i.e. there's no upstream ASN)
johannesmoos opened this issue · comments
Hi PeeringDB team!
We at DE-CIX would be interested in filtering out routes containing transit-free networks in the BGP AS path, i.e. networks that do not obtain transit from other networks. This will apply to e.g. tier 1 networks but might apply to other networks as well. The assumption is that a transit free network does not show up in a position other than the leftmost in an AS path (i.e. when one peers with it). Otherwise the route can be considered as a leak. The arouteserver project also allows the generation of filters based on a static transit free ASN list.
The interesting/hard part is to come up with a list of transit-free networks that everyone agrees on and that is easy to maintain. My proposal is the following:
Let networks indicate on their own if it is legitimate that they show up in an AS path (except the leftmost position of course) because they should know best themselves. This would be achieved by checking a box in their Peering DB network object. Default: unchecked.
That way one can safely filter based on that list.
What do you think?
Best regards,
Johannes Moos
Excellent idea
I have to add that we should differentiate IPv4 and IPv6 as different peering policies/tier 1 classifications might exist for a given address family.
We could add a dropdown menu instead of a checkbox:
Transit-free
- no (default)
- IPv4
- IPv6
- IPv4+IPv6
In general I like this idea but perhaps instead of calling this a selection for being "transit free" the selection is instead "route server restricted" which is actually seems to be the intended use for the setting and would potentially open this up to non-transit free networks that do not want their prefixes seen via an RS at any IXP.
I think "transit free" would be like adding a "Tier 1" flag - something a lot of people would spend a lot of time wasting breath arguing about.
I agree with @stillwaxin that focusing on the route server use case makes a lot more sense and would be less contentious. We would definitely want a tooltip of some sort to explain what the field means (since it's not super obvious at first glance), so #228 should really get done first or at the same time.
I'd call the feature Never via routeservers - this way both IXPs and IXP participants can implement appropriate filters.
I'd start without differentiating between IPv4 and IPv6. Granularity can be added later, if is shown that it is actually required.
So if 2914 clicks the "Never via route servers", an IXP could use that information to block any BGP updates where the AS_PATH matches the regular expression _2914_.
I like the suggestion better regarding "never via routeservers", saying whether you are transitfree is a marketing rabbitshole that I don't want to jump into
This flag would appear useful to the handful of networks who actually have such a policy..
But the flip side of any route-servers deriving their policy from PDB is that it could be open to abuse, are we confident enough with the signup and new network validation that it would not be considered possible for a malicious actor to create a record for a network who has not (yet) created one themselves and then by setting the NVRS flag influence the traffic of victim network?
Additon of new networks is done along RIR data. A user only can become admin if their email address matches an address found in RIR data or when the request is ACKed by one of the address holders.
So I as head of the Admin Committee am confident enough that this attack vector is very small.
I agree the attack vector is small compared to some other sources of information are used to influence routing policy..
However as we move towards an increasingly automated ecosystem it seems prudent to remain mindful of the potential outcomes of introducing functionality which has the ability to influence traffic, particularly as the majority of route-servers perform some degree of validation and/or filtering it could become increasingly attractive for a malicious actor to divert traffic towards bilateral sessions which remain significantly less likely to be filtered.
I have a feeling that the approach outlined in this comment #394 (comment) has broader application and would be more useful for the community
The original idea was that the feature is generic enough to be used by every BGP speaker to build their filters, not just IXPs (on route servers). But I am fine with the current discussion progress as well as it still fits my route server application.
I'm usually in agreement with anything that helps networks programmatically build better filters, but there's something about "Transit Free" and "Tier 1" that makes any discussion around it an endless pissing contest, which I would really love to avoid...
I'm a bit torn here - is there any other preferred non-pdb data-source that can be relied on to build such filters?
@grrrrreg, networks would categorise themselves. So what's the problem then?
IDK, I'm mostly thinking about adverse networks not agreeing w/ the self-categorized status asking PDB to remediate... maybe I'm just paranoid...
@grrrrreg ... I'm not getting it. If they set the flag, they can also remove it. So what?
Isn't calling it Never via routeservers a bit misleading? One might assume that this ASN is never peering via routeservers.
Isn't calling it
Never via routeserversa bit misleading? One might assume that this ASN is never peering via routeservers.
I suspect that is @job 's intention, with the original use case being for networks who neither announce their prefixes to IX route-servers themselves or expect anyone else to do so on their behalf..
Perhaps a "never indirectly via route servers" might have a wider appeal as I suspect there are plenty of networks who do not claim to be transit-free but may feel that the only IX route-servers they wish their prefixes to be advertised to are the ones which they peer with directly..
Which although less ambiguous, is probably scope creep...
+1, no objections at all anymore
To summarize:
- We should add a new flag to the net object in peeringdb called "Never via route servers" that is a boolean. Default this value to false for all networks on day 1.
- On the backend we should expose this via the api.
- On the frontend we should expose this under "Protocols Supported"
- On the frontend we should add a tooltip to the field which describes it (leveraging code in #228):
"Indicates if this network will announce its routes via route servers or not"