Today over on the Internet Society Internet Technology Matters blog, I wrote a piece about RFC 7908 being published. Most of us have heard the term “route leak,” but it was a vague term without an official, technical definition. RFC 7908 now provides that definition:
A route leak is the propagation of routing announcement(s) beyond their intended scope. That is, an announcement from an Autonomous System (AS) of a learned BGP route to another AS is in violation of the intended policies of the receiver, the sender, and/or one of the ASes along the preceding AS path. The intended scope is usually defined by a set of local redistribution/filtering policies distributed among the ASes involved. Often, these intended policies are defined in terms of the pair-wise peering business relationship between ASes (e.g., customer, transit provider, peer). For literature related to AS relationships and routing policies, see [Gao], [Luckie], and [Gill]. For measurements of valley-free violations in Internet routing, see [Anwar], [Giotsas], and [Wijchers]. The result of a route leak can be redirection of traffic through an unintended path that may enable eavesdropping or traffic analysis and may or may not result in an overload or black hole. Route leaks can be accidental or malicious but most often arise from accidental misconfigurations. The above definition is not intended to be all encompassing. Our aim here is to have a working definition that fits enough observed incidents so that the IETF community has a basis for developing solutions for route-leak detection and mitigation.
In my post, I went on to say that “This definition is an important milestone in the work to make routing more secure, and in particular on mitigating or preventing route leaks from happening. Because without a problem statement, how can you be sure you are providing the right solution?”
Here with MANRS, we’re working on creating solutions. In fact, we know that maintaining up-to-date filters for customer announcements could have mitigated some known cases of route leaks. That’s why it’s already embedded in one of the Actions required in MANRS.
If you’re already implementing this (along with some of the other Actions), you’re one step ahead of the game. Sign up as a MANRS participant today to show your support, or share this with your network operator colleagues to get them moving toward a safer, more secure Internet.