Internet DRAFT - draft-balaji-l2vpn-lawful-intercept-thru-label-dis

draft-balaji-l2vpn-lawful-intercept-thru-label-dis



 



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]