Internet DRAFT - draft-balaji-mpls-inter-as-policy-based-te-sec
draft-balaji-mpls-inter-as-policy-based-te-sec
MPLS Working Group Shankar Raman
Internet-Draft Balaji Venkat Venkataswami
Intended Status: Experimental RFC Gaurav Raina
Expires: February 2013 I.I.T Madras
Bhargav Bhikkaji
Dell-Force10
August 19, 2012
Avoiding Un-trusted AS thru inter-AS TE-LSPs constructed using Clipping
draft-balaji-mpls-inter-as-policy-based-te-sec-01
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 February 2013 [Page 1]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 February 2013 [Page 2]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 . . . . . . . . . . . . . . . . . . . . . . . . 11
Balaji Venkat et.al Expires February 2013 [Page 3]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 February 2013 [Page 4]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 February 2013 [Page 5]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 H 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 February 2013 [Page 6]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 February 2013 [Page 7]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 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 traffic. The other direction
may be suitably constructed by the tail-end AS becoming the head-end
for such purposes.
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 February 2013 [Page 8]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 2012
3 Security Considerations
The verification of the BGP prefixes and their corresponding
attributes such as AS-PATH-INFO is to be considered. Existing
mechanisms can be used to verify these attributes. While constructing
the strands a technique to verify these actually are indeed the
strands of ASes that are traversed can be done by using a majority
vote technique from among a set of strands that cover a part of the
topology. In order to mount an attack with dis-information through
invalid strands, the rogue AS or set of ASes have to miscommunicate
the strand (AS-PATH-INFO) data in such a way that such majority vote
goes in their favour.
Considering the existing BGP path selection algorithm in place today,
the technique that we propose in this paper is a lot more resilient
and doesnt ply itself to listening to BGP updates without some sort
of verification.
4 IANA Considerations
None.
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.
Balaji Venkat et.al Expires February 2013 [Page 9]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 2012
[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.
[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.
Balaji Venkat et.al Expires February 2013 [Page 10]
INTERNET DRAFTAvoiding untrusted ASes using Graph Clipping August 2012
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 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 February 2013 [Page 11]
