• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
MANRS

MANRS

Mutually Agreed Norms for Routing Security

  • Home
  • About
    • About MANRS
    • History
    • Partners
    • Advisory Group
      • Description and Role
      • Members
    • Testimonials
    • Contact Us
  • Programmes
    • Network Operators
      • Network Operators Programme and Actions
      • Implementation Guide
      • Participants
      • Join MANRS
    • IXPs
      • IXP Programme and Actions
      • Participants
      • Join IXP Programme
    • CDN and Cloud Providers
      • CDN and Cloud Providers Programme and Actions
      • Participants
      • Join the Programme
  • MANRS Ambassadors
  • Resources
    • All Resources
      • Implementation Guide
      • Papers
    • Training
      • Workshops
      • Tutorials
    • Promote MANRS
  • Observatory
  • Blog
  • Join

RFC 7908 Defines “Route Leak”

June 23, 2016 by Andrei Robachevsky Leave a Comment

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.

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • More
  • Email
  • Print
  • Reddit
  • Tumblr

Category iconNews and Announcements,  Routing Security Incidents Tag iconIETF,  RFC

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Recent Posts

  • Feedback Requested: Chartering the MANRS Community
  • A Major BGP Hijack by AS55410-Vodafone Idea Ltd
  • 2 Security Issues with RPKI and How To Fix Them
  • Announcing the 2021 MANRS Fellows
  • Meet the 2021 MANRS Ambassadors
MANRS logo
Join MANRS
  • Sharing Our Content
  • Terms of Use
  • Privacy Policy
  • Contact
Follow us: Follow MANRS on Twitter Follow MANRS on Facebook Follow MANRS on LinkedIn Follow MANRS on YouTube

MANRS Document © 2016–2021

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.