[address-policy-wg] IXP peering lan reachability

Following up on Andrea's presentation earlier (for the record, ripe75,
apwg session #1, tuesday morning), there aren't compelling reasons for
the RIPE NCC to get involved in whether an IXP announces their peering
LAN prefix into the DFZ.  It's really a matter of local policy for the
ixp as to whether they want this to happen, and if a prefix is announced
into the dfz, this doesn't make any statement one way or another about
what the prefix is used for.  Lots of IXPs announce their peering lan
netblocks and many others choose not to.

The reasons for announcing relate mostly to debugging and problem
diagnosis, e.g. ping / traceroute.  We know of several IXP members at
various INEX LANs who use external reachability checking services to
monitor their service's uptime, which is a good thing to do and they see
a benefit from this, and they particularly don't want to see this
benefit going away.  Regarding traceroute, the udp/icmp replies can be
dropped if the network you're tracing from has uRPF enabled, which makes
problem diagnosis troublesome.

The reason most IXPs don't announce their peering LANs relates to
protecting against DDoS attacks.  Although we've had occasional DDoS
attacks launched against our infrastructures in the past, we have not
had service-affecting problems as a result.  If a service affecting
problem happens, we can announce the blocks with no-export or
no-announce, which would reduce the blast radius - or we could
completely drop the announcement, if that didn't work.

We're aware that the experience at other IXPs - especially larger IXPs -
can be different, but given that announcing the blocks provides useful
telemetry and diagnosis capabilities, and we've not had problems in the
last, we don't see any particular reason to stop announcing the range.
The risk/return ratio doesn't justify it.

The experiences of other IXPs may be different regarding ddos problems,
but many (most?) organisations connected to IXPs use "redistribute
connected" to inject the peering LAN prefix into their IGPs, and the
largest IXPs have visibility to most of the Internet prefixes, so in
practice, not announcing the blocks makes less difference to DDoS than
it might appear.

I'd politely suggest that this is an area that the RIPE NCC should not
get involved in, especially from the point of view of implicitly issuing
recommended practice by implying that there is a problem with doing
this.  The IXP associations are better placed to gather consensus for
creating best practices, and there is no general consensus in the IXP
community on this issue.

As regards using this as a metric for determining whether an ixp address
assignment is being used for legitimate purposes, I'd suggest that this
is of only marginal use at best.  By all means run a port scan to see if
there is any obvious mis-use (e.g. services listening on www/smtp/etc),
but the presence or absence of the route in the dfz doesn't mean
anything one way or another.

Nick
CTO, INEX