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

remove enforce_origin_in_as_set / enforce_prefix_in_as_set #22

Open
job opened this issue Mar 14, 2018 · 1 comment
Open

remove enforce_origin_in_as_set / enforce_prefix_in_as_set #22

job opened this issue Mar 14, 2018 · 1 comment

Comments

@job
Copy link
Contributor

job commented Mar 14, 2018

I see IXPs deploying arouteserver with the following config

cfg:
  filtering:
    irrd:   
      enforce_origin_in_as_set: False
      enforce_prefix_in_as_set: False

I think this defeats the entire purpose of using aroutserver. Both options shouldn't be user configurable - if people want to produce non-filtering route servers they can look elsewhere. By making it user configurable, two things happen: an entire exchange goes unfiltered, which is useless - and it enables exchanges to make exceptions per participant, an extremely unhealthy proposition.

I understand flexibility is a nice thing to have, but in this case the flexibility only offers poor choices and as such I'd argue that it is simply removed.

@job
Copy link
Contributor Author

job commented Mar 14, 2018

In comparison, IXP Manager purposefully doesn't even have configuration options to disable the filtering. This is very beneficial, because when you ask the IXP how they do filtering, all they need to say is "IXP Manager" and you know enough. It also ensures that people (both IXP operators and IXP participants) have a far lower chance of shooting themselves in the foot, because there is less ways to configure the program in an insecure way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant