Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark own ASN as transit-free (i.e. there's no upstream ASN) #394

Closed
johannesmoos opened this issue Nov 29, 2018 · 20 comments
Closed

Mark own ASN as transit-free (i.e. there's no upstream ASN) #394

johannesmoos opened this issue Nov 29, 2018 · 20 comments
Assignees
Milestone

Comments

@johannesmoos
Copy link

@johannesmoos johannesmoos commented Nov 29, 2018

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

@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Nov 29, 2018

Excellent idea

@johannesmoos

This comment has been minimized.

Copy link
Author

@johannesmoos johannesmoos commented Dec 1, 2018

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
@stillwaxin

This comment has been minimized.

Copy link

@stillwaxin stillwaxin commented Dec 14, 2018

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.

@mcmanuss8

This comment has been minimized.

Copy link
Contributor

@mcmanuss8 mcmanuss8 commented Jan 11, 2019

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.

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Jan 29, 2019

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_.

@eloos

This comment has been minimized.

Copy link

@eloos eloos commented Jan 31, 2019

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

@as44980

This comment has been minimized.

Copy link

@as44980 as44980 commented Mar 27, 2019

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?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Mar 27, 2019

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.

@as44980

This comment has been minimized.

Copy link

@as44980 as44980 commented Mar 27, 2019

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.

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Apr 1, 2019

I have a feeling that the approach outlined in this comment #394 (comment) has broader application and would be more useful for the community

@johannesmoos

This comment has been minimized.

Copy link
Author

@johannesmoos johannesmoos commented Apr 6, 2019

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.

@grrrrreg

This comment has been minimized.

Copy link

@grrrrreg grrrrreg commented Apr 23, 2019

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?

@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Apr 23, 2019

@grrrrreg, networks would categorise themselves. So what's the problem then?

@grrrrreg

This comment has been minimized.

Copy link

@grrrrreg grrrrreg commented Apr 23, 2019

IDK, I'm mostly thinking about adverse networks not agreeing w/ the self-categorized status asking PDB to remediate... maybe I'm just paranoid...

@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Apr 23, 2019

@grrrrreg ... I'm not getting it. If they set the flag, they can also remove it. So what?

@job

This comment has been minimized.

Copy link
Contributor

@job job commented Apr 23, 2019

@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Apr 24, 2019

Isn't calling it Never via routeservers a bit misleading? One might assume that this ASN is never peering via routeservers.

@as44980

This comment has been minimized.

Copy link

@as44980 as44980 commented Apr 24, 2019

Isn't calling it Never via routeservers a 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...

@fhibler fhibler self-assigned this Jun 24, 2019
@arnoldnipper

This comment has been minimized.

Copy link
Contributor

@arnoldnipper arnoldnipper commented Oct 8, 2019

+1, no objections at all anymore

@mcmanuss8

This comment has been minimized.

Copy link
Contributor

@mcmanuss8 mcmanuss8 commented Oct 23, 2019

To summarize:

  1. 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.
  2. On the backend we should expose this via the api.
  3. On the frontend we should expose this under "Protocols Supported"
  4. 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"
@grizz grizz mentioned this issue Jan 8, 2020
grizz added a commit that referenced this issue Jan 8, 2020
* use new peeringdb client (1.0.0) for pdb_load_data sync (#599)

* drop django-mobi for lack of py3/dj2 support (#492)
remove django-forms-bootstrap for lack of py3/dj2 support (#492)

* black formatted

* django2.2 and py3 upgrade (#492)

* drop ixlans (#21) ui and api changes

* drop local_asn (#168)

* org search (#193)

* phone number validation (#50)

* implement help text tooltips (#228)

* Mark own ASN as transit-free (#394)

* py3 fix for `pdb_migrate_ixlans` command when writing migration report

* pdb_migrate_ixlans: properly handle py3 Runtime error if ixlan dict changes during iteration

* set rest DEFAULT_SCHEMA_CLASS to coreapi to fix swagger apidocs
fix migration 0027 missing from facsimile manifest

* fix swagger doc strings

* fix tests that were broken from api doc fixes

* fix UniqueFieldValidator for netixlan ipaddress validation that broke during django/drf upgrade

* fix org merge tool layout issues

* travis config

* update pipfile and lock

* black formatting

* update travis dist

* beta mode banner (#411)

* add beta banner template (#411)

* automatically scheduled sync may not always be on, add a flag that lets us reflect that state in the beta banner message
clean up beta banner implementation (#411)

* add tests for beta banner (#411)
@grizz grizz closed this Jan 8, 2020
@koalafil koalafil added the In a Quote label Jan 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.