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]
