RFC 7908, “Problem Definition and Classification of BGP Route Leaks,” has been just published. While “route leak” was a known phenomenon, sometimes causing significant disruptions to Internet routing, it was a vague term meaning many things to many people. RFC 7908 provides a technical 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.”
One example of a route leak is when a multi-homed customer “leaks” an announcement from one upstream provider to another. Since customer announcements usually have the highest priority, that traffic can bypass the customer unless precautions are put in place. The customer effectively becomes a transit provider. That opens up potential for a staged man-in-the-middle (MITM) attack, or a Denial of Service (DoS) attack incurred on oneself.
Route leaks originally emerged as a problem in the IETF SIDR Working Group. None of the security solutions developed there protect against this type of attack, simply because BGP does not have the ability to signal relationships like customer-provider. The IETF GROW Working Group then fleshed out the definition of route leak and the problem statement, concluding with the publication of RFC 7908.
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?
So, what is the solution? It is being discussed in another IETF Working Group – Inter-Domain Routing (IDR) – since it will probably require modifications to the Border Gateway Protocol (BGP). A proposal is to enhance the BGP with a per-hop Route Leak Protection (RLP) flag, as documented in “Methods for Detection and Mitigation of BGP Route Leaks.” There are also other ideas, such as the one outlined in “Route Leak Detection and Filtering using Roles in Update and Open messages.” This proposal enhances the BGP Open message to establish an agreement about the relationship between two BGP neighboring speakers in order to enforce appropriate configuration on both sides. We hope the discussions will result in an agreed common approach.
But in the meantime, many route leaks can be prevented today, and many network operators are already taking action. Maintaining up-to-date filters for customer announcements could have mitigated some known cases of route leaks.
This practice is embedded in one of the Actions required in Mutually Agreed Norms for Routing Security (MANRS). It can be implemented with today’s tools, and future technologies will make it even easier. There is no need to delay your contribution to making the Internet better, and your customers less vulnerable to such misconfigurations.
The MANRS actions help define a new industry norm for routing security that will to a great extent prevent incidents like this and improve confidence in the routing system of the Internet.
Are you a network operator already implementing the MANRS actions? Sign up today to show your support for MANRS! Interested in learning more? Read the full MANRS document and its expected actions, or contact us with any questions.