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/ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
