this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation.
I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter?
this might be a stupid question but today I was discussing with a colleague if Peering-LAN prefixes should be re-distributed/announced to direct customers/peers. My standpoint is that in any case, Peering-LAN prefixes should be filtered and not announced to peers/customers because a Peering-LAN represents some sort of DMZ and there is simply no need for them to be reachable by third-parties not being physically connected to an IXP themselves. Also from a security point of view, a lot of new issues might occur in this situation.
I’ve been seeing a few transit providers lately announcing (even reachable) Peering-LAN prefixes (for example DE-CIX Peering LAN) to their customers. I’m wondering if there is any document or RFC particularly describing this matter?
It is NTT's policy to reject Peering LAN prefixes (and any
more-specifics) of any IXPs NTT is connected; on both our ingress EBGP
and egress EBGP policies.
We don't see a need for NTT to attempt to make such peering lan
networks reachable for third parties. Such reachability may negatively
impact operations, especially when more-specifics of Peering LAN
prefixes are distributed through the default-free zone.
As a consequence, for IXPs this policy suggests that it is a necessity
to host their own infrastructure (IXP website, mail server, etc)
outside the peering lan prefix.
Dear Job, Michael, Ross,
thank you very much for sharing your opinion, the detailed info and references. That’s pretty much what I excpected.
Just wondered because I couldn’t find any IXP Conection Agreement stating this „issue“ explicitly yet.
Maybe MANRS IXP actions has some recommendations regarding this, checking that now.
Dear Job, Michael, Ross,
thank you very much for sharing your opinion, the detailed info and
references. That’s pretty much what I excpected.
Just wondered because I couldn’t find any IXP Conection Agreement
stating this „issue“ explicitly yet.
Maybe MANRS IXP actions has some recommendations regarding this,
checking that now.
We don't have it in our connection agreement as such, but it is in
section 3.2 of our (admittedly aged) Configuration Guide:
3.2. Peering LAN Prefix
The IPv4 prefix for the AMS-IX peering LAN (80.249.208.0/21) is part
of AS1200, and is not supposed to be globally routable. This means
the following:
1. Do not configure "network 80.249.208.0/21" in your router's
BGP configuration (seriously, we have seen this happen!).
2. Do not redistribute the route, a supernet, or a more specific
outside of your AS. We (AS1200) announce it with a no-export
attribute, please honour it.
In short, you can take the view that the Peering LAN is a link-local
address range and you may decide to not even redistribute it
internally (but in that case you may want to set a static route for
management access so you can troubleshoot peering, etc.).
AFAIK, pretty much all IXP operators take this view.
Running a few exchange points in Africa since 2002, the news was that
the exchange point LAN should not be visible anywhere on the Internet.
It would be interesting to know that this wasn't the case in other parts
of the world.
Some IX’s use a globally reachable peering lan prefix as a convenience for their participants as “poor man’s out-of-band”, or can’t designate a separate /24 for the IXP’s website / public services.
I can see some use cases, but in today’s internet landscape the practice just increases the attack surface, so it’s not the Best Current Practise.
Either AS 0, or the ASN of the IXP’s service network are valid options. Whatever ASN is listed in the RPKI ROA, should simply never announce the prefix.
IXPs should make sure to not set MaxLength to allow anything more-l specific, it should be equal to the prefix length.
Running a few exchange points in Africa since 2002, the news was that
the exchange point LAN should not be visible anywhere on the Internet.
It would be interesting to know that this wasn't the case in other parts
of the world.
This wasn't a popular service when I left Team Cymru, but it seems to
still be available if anyone wants to consider using that.
For more on the historical record, about 10 years after Randy, and from
my own experience, this was briefly touched on this in a lightning talk
at NANOG 41, "Explorations in the Public Peering Address Space". As
part of a project looking at peering discovery, in the Q&A Louie Lee as
I recall provided a partial answer to the announcement question raised.
It might be worth watching the video for those interesting in this.
Scroll to the bottom to see the deck and video here: