Chinese BGP incident: was it a traffic hijack?

You’re probably familiar with the April fat fingers incident in which Chinanet (AS 23724) originated ~37.000 prefixes for about 15 minutes. The incident made it into the annual report of US Congress’ U.S.-China Economic and Security Review Commission (page 243 of this PDF) and the media was more than happy to pick it up (Andree Toonk has a whole list of links in his blog post). We might never know whether the misleading statements in the report were intentional or just a result of clueless technical advisors, but the facts are far away from what they claim:

The publicity of this incident might be a good thing if the lesson learned would be “we have to secure BGP routing”. Fat chance, we made no progress in over a decade. The reason we’re making no progress – people who would have to invest in the infrastructure (ISPs) are different from the people who would benefit most (content providers). Yet another failure of the current Internet business models that I’m describing in the Upcoming Internet Challenges webinar (register here).

2 comments:

  1. Actually the content providers are customers of the large interconnect ISPs, so there still might be something to do there ?

    Surely companies like level3, cogent, ... would be fans of secure bgp I think.

    The main problem, it seems to me, is agreeing
    (1) who signs IP address space requests, and therefore gets the option to knock anyone offline world-wide (this is going to be the American govt. probably, and too many nutcases shit themselves when they hear this)
    (2) getting pressure on router makers (ie. cisco, and juniper, if you have those behind you, you're pretty much done I think)

    ReplyDelete
  2. The problem is that secure BGP routing is not possible AT ALL with existing routing architecture - even if you magically implement sBGP or so-BGP. The main reason is hop-by-hop independence, where every node or AS performs routing/forwarding decision on its own. Thus, for example, even if you validate that AS X is responsible for prefix Y and does have Path Z to reach it, you cannot really be sure that AS X will use the path Z to reach Y. As soon as you hand your packet to AS X you lose control over forwarding.

    A possible change could be replacing existing distributed routing with source-based routing model, where ingress point enforces a given path across the internetwork. This is possible using cryptographic method, but obviously such solution will have scalability issues.

    The modern internet operates loosely based on "free market" principles, or in other words its behavior might be described by game theory. As long as all independent agents agree to some rules of "rational" behavior (e.g. I do not abuse TCP congestion rules.. or I do not engineer traffic to gain local avantage...), they all get some "fair" share of "benefits". However, there is no stable state of equilibrium in such complex system - one cannot be sure that all agents behave rationally and seek profit (e.g. government intervention may circumvent this assumption) plus you cannot avoid various temporary "coalitions" seeking better margins above their average share.

    One good example is the "best effort" QoS model we have in the internet now. It is assumed that every individual member follows some "honest" rules of congestion control behavior, resulting in more or less equilibrium state. However if multiple nodes start abusing those rules (e.g. opening multiple TCP sessions to overcome TCP slow start limitations) the global equilibrium could be broken.

    Once again, the problem of security could never be solved completely - just alleviated to some extent. Unless a group of agents is under common control you cannot enforce a security policy for the group. Just like real people, independent agents follow the rules of the "economy", resulting in complex dynamics, which could be classified as "secure" only to the extent we believe in "rational" behavior of each and every agent.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.