Skip to main content

Avoiding un-trusted AS thru inter-AS TE-LSPs constructed using Clipping
draft-balaji-mpls-inter-as-policy-based-te-sec-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Shankar Raman , Balaji Venkat Venkataswami , Gaurav Raina , Bhargav Bhikkaji
Last updated 2012-08-01
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-balaji-mpls-inter-as-policy-based-te-sec-00
MPLS Working Group                                         Shankar Raman
Internet-Draft                                Balaji Venkat Venkataswami
Intended Status: Experimental RFC                           Gaurav Raina
Expires: January 2013                                       I.I.T Madras
                                                        Bhargav Bhikkaji
                                                            Dell-Force10
                                                           July 30, 2012

Avoiding un-trusted AS thru inter-AS TE-LSPs constructed using Clipping 
           draft-balaji-mpls-inter-as-policy-based-te-sec-00

Abstract

   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
 

Balaji Venkat et.al       Expires January 2013                  [Page 1]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

   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.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
 

Balaji Venkat et.al       Expires January 2013                  [Page 2]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Methodology of the proposal  . . . . . . . . . . . . . . . . .  5
     2.1 Pre-requisites for the Proposed Method . . . . . . . . . . .  5
       2.1.1 Constructing network topology using BGP strands  . . . .  5
       2.1.3 Explicit routing using TE-LSPs . . . . . . . . . . . . .  6
       2.1.4 Conclusion and Future work . . . . . . . . . . . . . . .  7
       2.1.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . .  8
   3  Security Considerations . . . . . . . . . . . . . . . . . . . .  9
   4  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  9
   5  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     5.2  Informative References  . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

 

Balaji Venkat et.al       Expires January 2013                  [Page 3]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

1  Introduction

   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.

1.1  Terminology
 

Balaji Venkat et.al       Expires January 2013                  [Page 4]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Methodology of the proposal

   This draft is an attempt to provide a solution. The following are the
   pre-requisites of the solution.

2.1 Pre-requisites for the Proposed Method

   In this section we discuss the pre-requisites for the implementation
   of the proposed scheme.

2.1.1 Constructing network topology using BGP strands

   The Inter-AS topology can be modeled as a directed graph G = (V; E;
   f) where the vertices (V) are mapped to AS and the edges (E) map the
   link that connect the neighboring AS. The direction (f) on the edge,
   represents the data flow from the head-end to the tail-end AS. To
   obtain the Inter-AS topology, the approach proposed in [5] is used.
   In this approach, it is shown that a sub-graph of the Internet
   topology, can be obtained by collecting several prefix updates in
   BGP. This is illustrated in Figure 1 which shows the different graph
   strands of AS that are recorded from the BGP packets.  Figure 2 shows
   the strands merged together to form the topology sub-graph. 

      (A) ----> (B) ----> (D)

      (D) ----> (G) ----> (H)

      (G) ----> (E) ----> (X)

      (C) ----> (B) ----> (H) ----> (X)

      (B) ----> (E) ----> (X)

   Figure 1: Different strands obtained from BGP updates, where vertices
   A,B,C,D and G represent the head-end AS. D,H and X form the tail-end
   AS. The direction of the link shows the next AS hop.

 

Balaji Venkat et.al       Expires January 2013                  [Page 5]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

             (C)  +----------------+
              |  /                 |
              | /                  |
              V/                   V
      (A)--->(B)--->(D)--->(G)--->(H)
              |             |      |
              |             |      |     
              |             V      V
              +----------->(E)--->(X)

   Figure 2:Combining the strands to get the topology of the Internet.

2.1.3 Explicit routing using TE-LSPs

   We assume that the head-end and the tail-end may reside in different
   AS and the path is along multiple intervening AS. In our example the
   head-end is ISP providing services to its customers which is AS A and
   the tail-end is X which is the well known site AS, and AS X is the
   rogue AS that has to be avoided. The way to generate this path is by
   using Traffic Engineered Label Switched Paths (TE-LSPs). TE-LSPs can
   influence the exact path (at the AS level) that the traffic will pass
   through. This path can then be realized by providing these set of
   ASes to a protocol like Resource Reservation Protocol (RSVP). RSVP-TE
   then creates TE-LSPs or tunnels, using its label assigning procedure.
   The routers use these paths created by the explicit routing method
   rather than using the conventional shortest path to the destination.
   By this way, we can influence exclusion of a number of to-be-avoided-
   ASes on the way from the head-end to the tail-end AS. For example,
   the dotted line in Figure 5 represents the explicit route that is
   chosen by making use of such TE-LSPs from head-end AS A to the tail-
   end AS X. Note that if number of hop was the metric used by CSPF,
   then the route chosen is the path with 3 hops. Here the AS to be
   avoided is the AS H. In order to exclude the possibility of any
   traffic passing through H the policy is applied at the time of path
   computation to exclude all links to and from node H and the AS H
   itself. This can be used by clipping the to be excluded AS by
   clipping links to and from it, in this case H.

   The prefixes in X and behind X need to be advertised as reachable
   through the TE-LSP so constructed. This way the traffic goes through
   trusted ASes and not into territory of ASes that are rogue and have
   an intent to snarf or eavesdrop on the data encrypted or non-
   encrypted.

   The clipped topology is shown in the figure below and the path
   constructed after excluding AS H is shown in the figure after the one
   below.

 

Balaji Venkat et.al       Expires January 2013                  [Page 6]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

             (C)                     
              |                     
              |                     
              V                     
      (A)--->(B)--->(D)--->(G)
              |             |
              |             |
              |             V
              +----------->(E)--->(X)

   Figure 5.1: Clipped Graph excluding AS H.

             (C)  +----------------+
              |  /                 |
              | /                  |
              V/                   V
      (A)...>(B)...>(D)...>(G)--->(H)
              |             .      |
              |             .      |                
              |             V      V
              +----------->(E)...>(X)

   Figure 5.2:The final path is represented by the dotted lines. This
   path has a longer number of hops than the conventional shortest path
   but it avoids AS H.

   It is also possible through this scheme to cut out a set of ASes
   rather than just one AS. Thus a gaping hole in the topology might
   result thus excluding one or more ASes from being considered while
   considering the Inter-AS TE-LSPs. This can be easily done by clipping
   all links to and from the graph to these set of ASes and eliminating
   the ASes altogether from consideration if they are not trusted by the
   Path Computation Element (PCE) of the TE-LSP initiating provider or
   AS.

   This process of setting up inter-AS TE-LSPs that are passing through
   trusted (so called) ASes can be selectively done only for traffic
   heading to tail-end ASes which may be ISPs for the well-known sites
   or the well-known sites themselves (assuming they have an AS of their
   own). Such selective tunneling would take care of scalability
   concerns at the provider initiating these tunnels (head-ends).

2.1.4 Conclusion and Future work

   Avoiding ASes and their associated links that should not be traversed
   towards needs be considered. One method that can be used is
   constructing inter-AS TE LSPs with or without bandwidth reservation
   to and from a head-end and a tail-end avoiding certain ASes which are
 

Balaji Venkat et.al       Expires January 2013                  [Page 7]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

   explicitly specified. Other methods are also being investigated which
   will be specified in due course in an updated version of this
   document. we show only one direction of 

2.1.5 ACKNOWLEDGEMENTS

   The authors would like to acknowledge the UK EP-SRC Digital Economy
   Programme and the Government of India Department of Science and
   Technology (DST) for funding given to the IU-ATC. 

 

Balaji Venkat et.al       Expires January 2013                  [Page 8]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

3  Security Considerations

   Encryption of the packets funneled to the analyzing devices needs to
   be considered.

4  IANA Considerations

   Appropriate IANA indicators would have to be provided to exchange the
   set of values that Algorithm 1,2 outlines in order to implement this
   scheme.

5  References

5.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC1776]  Crocker, S., "The Address is the Message", RFC 1776, April
              1 1995.

   [TRUTHS]   Callon, R., "The Twelve Networking Truths", RFC 1925,
              April 1 1996.

5.2  Informative References

              [1] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS
              security: an approach for unicast and multicast
              environments", Annals of Telecommunications, Springer,
              vol. 64, no. 5, June 2009, pp. 391-400,
              doi:10.1007/s12243-009-0089-y.

              [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security",
              Cisco Press, June 2005, ISBN-10: 1587051834.  

              [3] B. Daugherty and C. Metz, "Multiprotocol Label
              Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE
              Internet Computing, May-June 2005, pp. 68-72, doi:
              10.1109/MIC.2005.61.

              [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles,
              "Interprovider IP-MPLS services: requirements,
              implementations, and challenges", IEEE Communications
              Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi:
              10.1109/MCOM.2005.1452840.
 

Balaji Venkat et.al       Expires January 2013                  [Page 9]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

              [5] C. Lin and W. Guowei, "Security research of VPN
              technology based on MPLS", Proceedings of the Third
              International Symposium on Computer Science and
              Computational Technology (ISCSCT 10), August 2010, pp.
              168-170, ISBN- 13:9789525726107.

              [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D.
              Farinacci and D. Katz, "Tag switching architecture
              overview", Proceedings of the IEEE, vol. 85, no. 12,
              December 1997, pp. 1973-1983, doi:10.1109/5.650179.

              [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, Standard Track, February,
              2006.

              [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C.
              Stein, "Introduction to algorithms", 3rd edition, MIT
              Press, September 2009, ISBN-10:0262033844.

              [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals",
              Juniper Networks white paper, March 2001.

              [10] Advance MPLS VPN Security Tutorials [Online],
              Available:
              "http://etutorials.org/Networking/MPLS+VPN+security/
              Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed:
              10th December 2011]

              [11] Inter-provider MPLS VPN models [Online], Available:
              "http://mpls-configuration-on-cisco-iossoftware. 
              org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th
              December 2011] 

              [12] Davari.S et.al, Transporting PTP messages (1588) over
              MPLS networks, "http://datatracker.ietf.org/doc/draft-
              ietf-tictoc-1588overmpls/?include_text=1", Work in
              Progress, October 2011.

Authors' Addresses

              Shankar Raman
              Department of Computer Science and Engineering
              I.I.T Madras,
              Chennai - 600036
              TamilNadu,
              India.

              EMail: mjsraman@cse.iitm.ac.in
 

Balaji Venkat et.al       Expires January 2013                 [Page 10]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping     July 2012

              Balaji Venkat Venkataswami
              Department of Electrical Engineering,
              I.I.T Madras,
              Chennai - 600036,
              TamilNadu,
              India.

              EMail: balajivenkat299@gmail.com

              Prof.Gaurav Raina
              Department of Electrical Engineering,
              I.I.T Madras,
              Chennai - 600036,
              TamilNadu,
              India.

              EMail: gaurav@ee.iitm.ac.in

              Bhargav Bhikkaji
              Dell-Force10,
              350 Holger Way,
              San Jose, CA
              U.S.A

              Email: Bhargav_Bhikkaji@dell.com

Balaji Venkat et.al       Expires January 2013                 [Page 11]