Skip to main content

Label-based Provider-Provisioned Lawful Intercept for L3 VPNs
draft-balaji-mpls-lawful-intercept-thru-label-dis-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 , Vasan Srini, Bhargav Bhikkaji
Last updated 2012-07-30
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-lawful-intercept-thru-label-dis-00
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]