Avoiding Un-trusted AS thru inter-AS TE-LSPs constructed using Clipping

Document Type Expired Internet-Draft (individual)
Authors Shankar Raman  , Balaji Venkataswami  , Gaurav Raina  , Bhargav Bhikkaji
Last updated 2013-02-20 (latest revision 2012-08-19)
Stream (None)
Intended RFC status (None)
Expired & archived
plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


For a short time sometime in the recent past , internet traffic sent between a well known site and subscribers to an internet service provider A passed through hardware belonging to a Telecom provider B other than the ISP A to which the customers were attached before reaching its final destination. Telecom Provider B was found to be many AS hops away from the well known site and ISP A. It was assumed that this was an an innocent routing error (which is the most likely explanation for the highly circuitous route that the traffic was taking), but it was troubling nonetheless. During a window that lasted 30 minutes to an hour, all unencrypted traffic passing between the victimised ISP's customers and the well known site might have been open to monitoring. Though there was no evidence any data was in fact snarfed, but it was felt that the potential for that is certainly there because the hardware belonged to the untrusted Telecom provider B. Many such incidents have occurred in the past where the traffic has been diverted through such providers that either erroneously have let loose BGP routes or otherwise. At least one of those incidents was the result of erroneous BGP, or Border Gateway Protocol, routes that were quickly corrected. The above is a hypothetical headline that might occur in the near future if the BGP protocol is subject to such circuitous routing attacks either by mis-configuration or through purposeful intent. This is primarily owing to the fact that the BGP protocol accepts updates from providers and there exists no mechanism to figure out whether the updates for prefixes received was due to mal-intent, mis-configuration or indeed correct configuration. So there is a big blind spot that will have to be rectified. Doing the rectification through BGP would only complicate matters more. The proposal in the scheme in this draft, warrants the use of MPLS- based inter-AS Traffic Engineered Label Switched Paths that are constructed out of a derived inter-AS topology that help to impose policy decisions that for eg, obviate or prevent such LSPs from actually going through certain specific AS or set of ASes. Using methods like Graph construction from AS-PATH-INFO data and methods like policy based clipping of edges and nodes from such a inter-AS topology, the solution is made simple. The use of PCE (Path Computation Elements) is advised to compute such inter-AS paths that avoid ASes. Regular routing would have followed BGP updates and regular IP based forwarding. Using the TE-LSPs we can in fact set out the explicit route from AS to AS from the head-end to the tail-end avoiding specific set of ASes which dictated by policy have to be avoided.


Shankar Raman (mjsraman@cse.iitm.ac.in)
Balaji Venkataswami (balajivenkat299@gmail.com)
Gaurav Raina (gaurav@ee.iitm.ac.in)
Bhargav Bhikkaji (bhargav_bhikkaji@dell.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)