MPLS Working Group Shankar Raman Internet-Draft Balaji Venkat Venkataswami Intended Status: Experimental RFC Gaurav Raina Expires: January 2013 Vasan Srini I.I.T Madras Bhargav Bhikkaji Dell-Force10 July 30, 2012 Label-based Provider-Provisioned Lawful Intercept for L3 VPNs draft-balaji-mpls-lawful-intercept-thru-label-dis-00 Abstract In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models like VPLS and the like do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto- provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of configuration is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. 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. Shankar Raman et.al Expires January 2013 [Page 1] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Methodology of the proposal . . . . . . . . . . . . . . . . . 4 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for LI . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a specific PE . . . . . . . . . . . . . . . 4 2.1.2.1 PE configuration . . . . . . . . . . . . . . . . . . 5 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 5 2.2 Domino-effect technique . . . . . . . . . . . . . . . . . . 5 2.2.0 Per-Prefix label to Per-VRF LI label . . . . . . . . . . 6 2.2.1 Algorithm 1 Control-plane dPE algorithm . . . . . . . . 7 2.2.2 Algorithm 2 Control-plane sPE algorithm . . . . . . . . 7 2.2.3 Algorithm 3 Data-plane dPE algorithm . . . . . . . . . . 8 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 8 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 8 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 Shankar Raman et.al Expires January 2013 [Page 2] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Shankar Raman et.al Expires January 2013 [Page 3] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 1 Introduction Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size labels to forward data packets between routers. By stacking labels, specific customer services such as Layer 3 Virtual Private Networks (L3-VPNs) based on Border Gateway Protocol (BGP) extensions are widely deployed in the Internet. BGP-based MPLS L3-VPN services are provided either on a single Internet Service Provider (ISP) core or across multiple ISP cores. The latter cases are known as inter- provider MPLS L3-VPNs which are broadly categorized and referred to as models: "A", "B" and "C". In all the above cases both Single-AS and inter-provider VPN cases for Layer 3 VPNs it is important that the provider or multiple providers have a co-ordinated mechanism of lawfully intercepting traffic to and from Provider Edge Routers (PEs) belonging to one or more VPN instances. This paper outlines a label-based Provider Provisioning technique that helps to provide a single point of configuration for lawfully intercepting through traffic mirroring or other such techniques of data flowing to and from one or more PEs or all of the PEs that constitute a particular VPN instance. More than one VPN instance may be configured with this technique. Also Enhanced Remote SPAN with GRE keying mechanism is used to transport the intercepted packets to a Lawful Intercept device where it may be examined and analyzed by Government Authorities. 1.1 Terminology 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 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for LI In this section, we briefly review the pre-requisites for applying this technique in terms of the PE configuration and the control-plane exchanges needed for our proposed scheme. 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a specific PE The regular mechanisms using SNMP using the TAP-MIB can be used to Shankar Raman et.al Expires January 2013 [Page 4] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 configure the requirement to intercept traffic going to and from a given PE router. This very mechanism is used to initiate the scheme mentioned in this document. 2.1.2.1 PE configuration Various configurations are needed on the PEs to implement the label based Lawful Intercept scheme. A set of pre-defined labels called the Lawful Intercept labels are provided for a VPN instance that is configured on the PE. In the simplest case one single Lawful Intercept label may be used per VPN instance . In this draft, we assume that a single label lawful intercept is used per VPN instance per PE. 2.1.3 Control and data-plane flow Initially, the usual control plane exchanges take place where the labels configured for the Layer 3 VPN instance between the various PEs participating for that VPN instance are exchanged securely over the control-plane. Appropriate Lawful Intercept labels are configured or a knob that allocates them automatically is configured. These labels are not exchanged at the time when the LI based mechanism is not in place, meaning the TAP-MIBs are not yet setup for LI for a VPN instance. Appropriate ports that will mirror these LI intercepted frames are set up and pre-provisioned with links to the devices that will analyze the data when such interception occurs. Once the secure control-plane exchanges are completed, normal traffic starts to flow. It is possible then that an event occurs which results in a PE being configured for Lawful Intercept to take place. Such an event could be a police tipoff, external intelligence inputs and other events. The exact set of events that will trigger LI are outside the scope of this document. Once the PE (which we will call the dPE) is configured with this, the control plane for example MP- BGP (where BGP is used for control plane exchanges), then sends over the LI label to the other PEs of the same VPN instance. These other PEs called the sPEs (or the source PEs for short), then install this LI label to be the inner label or the VPN service label in their packets they send to the dPE. Appropriate ACLs configured for intercepting packets coming into the dPE with the LI label route the traffic to the mirroring port on the dPE. This is then encapsulated in a GRE tunnel and sent over to the Government network after suitable encryption if necessary. 2.2 Domino-effect technique Shankar Raman et.al Expires January 2013 [Page 5] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 In this case called the Domino-effect technique, all sPEs receiving control plane exchanges with an indication that a LI label is being requested to be installed on them in turn also send their respective LI labels to other PEs in distinct control plane exchanges. This will result in the entire VPNs traffic being monitored at the various participating PEs for that VPN. An appropriate indicator in the control plane exchange, in the case of BGP for example, a special tag in the NLRI information would indicate that this is an LI label. As already mentioned appropriate Access Control Entries (ACEs) in the PEs will direct the traffic coming in with these LI labels to the mirroring ports, one or more if any. The inner label information is mapped to a GRE key and the mirrored packets at the intercepting dPE are sent with this GRE key in place with of course the GRE encapsulation to the analyzing network devices. Additional information as to which sPE the traffic came from is also added to the packet. The exact means of this technique is upto the implementer to take up. 2.2.0 Per-Prefix label to Per-VRF LI label If the configuration on the dPE is to disseminate per-prefix labels then the introduction of the LI label is such that it (the LI label) is advertised as a an aggregate per-VRF label so that all of the traffic is bunched together in the transmit and/or the receive direction to the dPE and from the dPE pivoting around an appropriate single LI label so that it can be easily trapped by the ACE entry in the dPE (and if the domino is triggered in the sPEs as well) to get mirrored onto one or more ports. Shankar Raman et.al Expires January 2013 [Page 6] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 2.2.1 Algorithm 1 Control-plane dPE algorithm Require: * K Valid Lawful Intercept labels per VPN, Begin Get event that triggers configuration in the TAP-MIB; Get TAP-MIB configured particulars about which VPN and whether FlagTriggerDominoEffect is set; packet = makepacket(K[VPN Instance], FlagTriggerDominoEffect); For all sPEs in the VPN CP-SendPacket(sPE[j], MP-BGP, packet); endFor End 2.2.2 Algorithm 2 Control-plane sPE algorithm Require: None Begin packet = CP-ReceivePacket(dPE); // from dPE Label = ExtractLabel(packet); // extract LI label if (Label is LI label as indicated by NLRI information) then Set Label in Forwarding table for the VPN; endif FlagTriggerDominoEffect = ExtractFlags(packet); if (FlagTriggerDominoEffect) then Run Algorithm 1 on the sPE (as the dPE); End Shankar Raman et.al Expires January 2013 [Page 7] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 2.2.3 Algorithm 3 Data-plane dPE algorithm Require: None Begin packet = DP-ReceivePacket(Interface); if ((Label of packet is == LI label for VPN) && (ACL configured for the said Label)) then mirror packet with all information after mapping VPN label to GRE key; Encapsulate packet in GRE header and mirror it to appropriate port; endif End 2.4 CONCLUSION AND FUTURE WORK Additionally this same idea can be applied for L2-VPNs as well. A future draft in this area will be published in due course. 2.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. Shankar Raman et.al Expires January 2013 [Page 8] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs 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. Shankar Raman et.al Expires January 2013 [Page 9] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs 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. [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009. [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 2009. Shankar Raman et.al Expires January 2013 [Page 10] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 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 Vasan Srini Department of Computer Science and Engineering, I.I.T Madras, Shankar Raman et.al Expires January 2013 [Page 11] INTERNET DRAFT Label-based Lawful Intercept for L3 VPNs July 2012 Chennai - 600036, TamilNadu, India. EMail: vasan.vs@gmail.com Shankar Raman et.al Expires January 2013 [Page 12]