RFC 7908 Defines “Route Leak”

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.