[GROW] Route Server ASN stripping hiding considered harmful?

[Job Snijders <[e-mail]>]

Dear GROW,

After the gazillionth routing incident in which an IXP route server
amplified the problem, I think it is time we explore mechanisms to
improve accountability, auditability & make debugging easier.

It is common practise for route server operators to configure their
route server in such a way that the route server does not append its own
ASN to the AS_PATH attribute. Many IXPs view this practise as
justifiable because it gives them a competitive advantage over transit
providers.

RFC 7947 reasons "a route server does not participate in the process of
forwarding data between client routers", but meanwhile quite some IXPs
have more equipment and layer-2 hops as part of the forwarding path than
comparable IP networks for similar distances. [1] [2] [3] Does it even
matter that the route server device itself is not part of the
forwarding path? For all intents and purposes it is a BGP hop. The route
server is not under administrative control of the RS participants.

Whenever routing incidents occur, it takes considerable effort to
pinpoint which route server BGP speakers amplified the problem. Quite
some correlation & verification work is needed to reliably point out
which route server at what IXP contributed to the propagation of a
hijack or a route leak. If IXP route servers were visible in the
AS_PATH (just like normal IP networks), I think we'd see a lot more
responsible behavior and the implementations of route filters. 

Consider the following scenarios. When client A & client B at the same
IX have a bilateral session with each other, it doesn't matter whether
the route server injects its AS in the AS_PATH: the bilateral session
makes the route server control-plane path irrelevant. Since it is common
practise to assign a higher local preference to 'peering' routes
compared to 'transit' routes, in the case that client A & client B don't
have a bilateral session and only see each other via the route server,
padding the AS_PATH with the route servers ASN still won't have an
negative effect. It is only in corner cases that the AS_PATH becomes the
tie-breaker, and I find it hard to use those as justification to
sacrifice all of the route server's visibility.

Another benefit is that if route servers behave like normal BGP
speakers, client's dont need to disable safety checks such as "no bgp
enforce-first-as". Or that routing policy to match on prefixes coming
from the route server (on devices not connected to the IX) are simpler
if the ASN is vislble, and of course the same applies to analysis of MRT
dumps or use of BGP data in applications such as spam filtering. Or
think of hunting down announcements that became ghost routes, without
all ASNs visible in the AS_PATH as operator you'll be going through
severe pains to find the ghost route perpetrator.

Decades ago some argued that route servers should provide an experience
as close to bilateral peering as possible. But fast forward to 2017, we
see route servers with hundreds of thousands of paths, thousands of
sessions, in essence route servers became partial transit providers. I'd
argue that route server operators should assume their fiduciary duty and
stop hiding themselves. This will allow both operators & researchers to
more easily pinpoint issues, and help fix them.

In summary, I think RFC 7947 section 2.2.2.1 & 2.2.2.2 were misguided,
should be revisited, perhaps deleted. Thoughts?

Kind regards,

Job

[1]: https://ams-ix.net/technical/ams-ix-infrastructure
[2]: https://www.linx.net/tech-info-help/network-topology
[3]: https://www.nl-ix.net/network/projected-core-map-2017/