L2VPN Working Group Shankar Raman Internet-Draft Balaji Venkat Venkataswami Intended Status: Experimental RFC Gaurav Raina Expires: July 2013 IIT Madras Bhargav Bhikkaji Dell-Force10 January 25, 2013 Label-based Provider-Provisioned Lawful Intercept for L2 VPNs draft-balaji-l2vpn-lawful-intercept-thru-label-dis-01 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 2 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 July 2013 [Page 1] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Methodology of the proposal . . . . . . . . . . . . . . . . . 5 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for LI . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a specific PE . . . . . . . . . . . . . . . 5 2.1.2.1 PE configuration . . . . . . . . . . . . . . . . . . 5 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 5 2.2 Domino-effect technique . . . . . . . . . . . . . . . . . . 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 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 Shankar Raman et.al Expires July 2013 [Page 2] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Shankar Raman et.al Expires July 2013 [Page 3] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 2 Virtual Private Networks (L2-VPNs) such as VPLS (Virtual Private Lan Service) based on Border Gateway Protocol (BGP) extensions are widely deployed in the Internet. BGP-based MPLS L2-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 L2-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 2 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. In the spirit of RFC 2804 and given that RFC 3924 that already exists, this mechanism can be considered from the point of view of an Experimental draft. No other opinion is professed except to document this as a possible method to use in times of crisis and emergency. In the spirit of 2804 which states and we quote... - On the other hand, the IETF believes that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described, so as to ensure the maximum review of the mechanisms and ensure that they adhere as closely as possible to their design constraints. The IETF believes that the publication of such mechanisms, and the publication of known weaknesses in such mechanisms, is a Good Thing." End of Quote. we submit this document for review in the spirit of what is said above. Shankar Raman et.al Expires July 2013 [Page 4] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 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 2 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 Shankar Raman et.al Expires July 2013 [Page 5] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 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. Shankar Raman et.al Expires July 2013 [Page 6] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 July 2013 [Page 7] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 L3-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 July 2013 [Page 8] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 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 July 2013 [Page 9] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 [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 July 2013 [Page 10] INTERNET DRAFT Label-based Lawful Intercept for L2 VPNs January 2013 Authors' Addresses Shankar Raman Department of Computer Science and Engineering IIT Madras, Chennai - 600036 TamilNadu, India. EMail: mjsraman@cse.iitm.ac.in Balaji Venkat Venkataswami Department of Electrical Engineering, IIT Madras, Chennai - 600036, TamilNadu, India. EMail: balajivenkat299@gmail.com Prof.Gaurav Raina Department of Electrical Engineering, IIT 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 Shankar Raman et.al Expires July 2013 [Page 11]