idnits 2.17.1 draft-balaji-l2vpn-lawful-intercept-thru-label-dis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 25, 2013) is 4080 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 151, but not defined == Unused Reference: 'KEYWORDS' is defined on line 315, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 321, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 326, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 332, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 335, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 340, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 346, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 357, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 361, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 365, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 368, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 374, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 390, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. '9') (Obsoleted by RFC 4364) Summary: 0 errors (**), 0 flaws (~~), 20 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Working Group Shankar Raman 3 Internet-Draft Balaji Venkat Venkataswami 4 Intended Status: Experimental RFC Gaurav Raina 5 Expires: July 2013 IIT Madras 6 Bhargav Bhikkaji 7 Dell-Force10 8 January 25, 2013 10 Label-based Provider-Provisioned Lawful Intercept for L2 VPNs 11 draft-balaji-l2vpn-lawful-intercept-thru-label-dis-01 13 Abstract 15 In models of Single-AS and inter-provider Multi- Protocol Label 16 Switching (MPLS) based Virtual Private Networks (VPNs) Lawful 17 Intercept is a key requirement. For example, MPLS-based Layer 2 VPN 18 models like VPLS and the like do not have any provider provisioned 19 methods of lawful intercept that are comprehensive, quick and easy to 20 provision from one single point. More particularly the auto- 21 provisioning of lawful intercept for all sets of streams travelling 22 between VPN sites and consequent re-direction of these streams to the 23 appropriate government network has not been covered without multiple 24 instances of having to configure the intercept at various points in 25 the network both in the Single-AS case and the Inter-Provider VPN 26 case. 28 this paper, we propose a technique which uses a set of pre-defined 29 labels called Lawful Intercept labels and a method for provisioning 30 lawful intercept amongst the various PE devices using these labels 31 both in the Single-AS and the inter-provider VPN cases. A single 32 point of configuration is the key to this idea. The intercepted 33 traffic is mirrored on a PE or a whole set of PEs or on all the PEs 34 participating in the VPN. A technique called the Domino-effect 35 provisioning of these Label-based Provider Provisioned Lawful 36 Intercept mechanism is also outlined. 38 Status of this Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 Copyright and License Notice 61 Copyright (c) 2013 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Methodology of the proposal . . . . . . . . . . . . . . . . . 5 79 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned 80 SCHEME for LI . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.1.1 Configuring Lawful Intercept for a specific VPN 82 instance on a specific PE . . . . . . . . . . . . . . . 5 83 2.1.2.1 PE configuration . . . . . . . . . . . . . . . . . . 5 84 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 5 85 2.2 Domino-effect technique . . . . . . . . . . . . . . . . . . 6 86 2.2.1 Algorithm 1 Control-plane dPE algorithm . . . . . . . . 7 87 2.2.2 Algorithm 2 Control-plane sPE algorithm . . . . . . . . 7 88 2.2.3 Algorithm 3 Data-plane dPE algorithm . . . . . . . . . . 8 89 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 8 90 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 8 91 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 92 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 93 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 94 5.1 Normative References . . . . . . . . . . . . . . . . . . . 9 95 5.2 Informative References . . . . . . . . . . . . . . . . . . 9 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 98 1 Introduction 100 Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size 101 labels to forward data packets between routers. By stacking labels, 102 specific customer services such as Layer 2 Virtual Private Networks 103 (L2-VPNs) such as VPLS (Virtual Private Lan Service) based on Border 104 Gateway Protocol (BGP) extensions are widely deployed in the 105 Internet. BGP-based MPLS L2-VPN services are provided either on a 106 single Internet Service Provider (ISP) core or across multiple ISP 107 cores. The latter cases are known as inter-provider MPLS L2-VPNs 108 which are broadly categorized and referred to as models: "A", "B" and 109 "C". 111 In all the above cases both Single-AS and inter-provider VPN cases 112 for Layer 2 VPNs it is important that the provider or multiple 113 providers have a co-ordinated mechanism of lawfully intercepting 114 traffic to and from Provider Edge Routers (PEs) belonging to one or 115 more VPN instances. 117 This paper outlines a label-based Provider Provisioning technique 118 that helps to provide a single point of configuration for lawfully 119 intercepting through traffic mirroring or other such techniques of 120 data flowing to and from one or more PEs or all of the PEs that 121 constitute a particular VPN instance. More than one VPN instance may 122 be configured with this technique. Also Enhanced Remote SPAN with GRE 123 keying mechanism is used to transport the intercepted packets to a 124 Lawful Intercept device where it may be examined and analyzed by 125 Government Authorities. 127 In the spirit of RFC 2804 and given that RFC 3924 that already 128 exists, this mechanism can be considered from the point of view of an 129 Experimental draft. No other opinion is professed except to document 130 this as a possible method to use in times of crisis and emergency. In 131 the spirit of 2804 which states and we quote... 133 - On the other hand, the IETF believes that mechanisms designed to 134 facilitate or enable wiretapping, or methods of using other 135 facilities for such purposes, should be openly described, so as to 136 ensure the maximum review of the mechanisms and ensure that they 137 adhere as closely as possible to their design constraints. The IETF 138 believes that the publication of such mechanisms, and the publication 139 of known weaknesses in such mechanisms, is a Good Thing." 141 End of Quote. 143 we submit this document for review in the spirit of what is said 144 above. 146 1.1 Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Methodology of the proposal 154 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for 155 LI 157 In this section, we briefly review the pre-requisites for applying 158 this technique in terms of the PE configuration and the control-plane 159 exchanges needed for our proposed scheme. 161 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a 162 specific PE 164 The regular mechanisms using SNMP using the TAP-MIB can be used to 165 configure the requirement to intercept traffic going to and from a 166 given PE router. This very mechanism is used to initiate the scheme 167 mentioned in this document. 169 2.1.2.1 PE configuration 171 Various configurations are needed on the PEs to implement the label 172 based Lawful Intercept scheme. A set of pre-defined labels called the 173 Lawful Intercept labels are provided for a VPN instance that is 174 configured on the PE. In the simplest case one single Lawful 175 Intercept label may be used per VPN instance . In this draft, we 176 assume that a single label lawful intercept is used per VPN instance 177 per PE. 179 2.1.3 Control and data-plane flow 181 Initially, the usual control plane exchanges take place where the 182 labels configured for the Layer 2 VPN instance between the various 183 PEs participating for that VPN instance are exchanged securely over 184 the control-plane. 186 Appropriate Lawful Intercept labels are configured or a knob that 187 allocates them automatically is configured. These labels are not 188 exchanged at the time when the LI based mechanism is not in place, 189 meaning the TAP-MIBs are not yet setup for LI for a VPN instance. 191 Appropriate ports that will mirror these LI intercepted frames are 192 set up and pre-provisioned with links to the devices that will 193 analyze the data when such interception occurs. 195 Once the secure control-plane exchanges are completed, normal traffic 196 starts to flow. It is possible then that an event occurs which 197 results in a PE being configured for Lawful Intercept to take place. 198 Such an event could be a police tipoff, external intelligence inputs 199 and other events. The exact set of events that will trigger LI are 200 outside the scope of this document. Once the PE (which we will call 201 the dPE) is configured with this, the control plane for example MP- 202 BGP (where BGP is used for control plane exchanges), then sends over 203 the LI label to the other PEs of the same VPN instance. These other 204 PEs called the sPEs (or the source PEs for short), then install this 205 LI label to be the inner label or the VPN service label in their 206 packets they send to the dPE. Appropriate ACLs configured for 207 intercepting packets coming into the dPE with the LI label route the 208 traffic to the mirroring port on the dPE. This is then encapsulated 209 in a GRE tunnel and sent over to the Government network after 210 suitable encryption if necessary. 212 2.2 Domino-effect technique 214 In this case called the Domino-effect technique, all sPEs receiving 215 control plane exchanges with an indication that a LI label is being 216 requested to be installed on them in turn also send their respective 217 LI labels to other PEs in distinct control plane exchanges. This will 218 result in the entire VPNs traffic being monitored at the various 219 participating PEs for that VPN. 221 An appropriate indicator in the control plane exchange, in the case 222 of BGP for example, a special tag in the NLRI information would 223 indicate that this is an LI label. As already mentioned appropriate 224 Access Control Entries (ACEs) in the PEs will direct the traffic 225 coming in with these LI labels to the mirroring ports, one or more if 226 any. 228 The inner label information is mapped to a GRE key and the mirrored 229 packets at the intercepting dPE are sent with this GRE key in place 230 with of course the GRE encapsulation to the analyzing network 231 devices. Additional information as to which sPE the traffic came from 232 is also added to the packet. The exact means of this technique is 233 upto the implementer to take up. 235 2.2.1 Algorithm 1 Control-plane dPE algorithm 237 Require: 238 * K Valid Lawful Intercept labels per VPN, 240 Begin 241 Get event that triggers configuration in the TAP-MIB; 243 Get TAP-MIB configured particulars about which VPN and whether 244 FlagTriggerDominoEffect is set; 246 packet = makepacket(K[VPN Instance], FlagTriggerDominoEffect); 248 For all sPEs in the VPN 250 CP-SendPacket(sPE[j], MP-BGP, packet); 252 endFor 253 End 255 2.2.2 Algorithm 2 Control-plane sPE algorithm 257 Require: None 258 Begin 259 packet = CP-ReceivePacket(dPE); // from dPE 260 Label = ExtractLabel(packet); // extract LI label 261 if (Label is LI label as indicated by NLRI information) then 262 Set Label in Forwarding table for the VPN; 263 endif 264 FlagTriggerDominoEffect = ExtractFlags(packet); 265 if (FlagTriggerDominoEffect) then 266 Run Algorithm 1 on the sPE (as the dPE); 267 End 269 2.2.3 Algorithm 3 Data-plane dPE algorithm 271 Require: None 273 Begin 274 packet = DP-ReceivePacket(Interface); 275 if ((Label of packet is == LI label for VPN) && 276 (ACL configured for the said Label)) 277 then 279 mirror packet with all information after mapping 281 VPN label to GRE key; 283 Encapsulate packet in GRE header and mirror it 284 to appropriate port; 286 endif 287 End 289 2.4 CONCLUSION AND FUTURE WORK 291 Additionally this same idea can be applied for L3-VPNs as well. A 292 future draft in this area will be published in due course. 294 2.5 ACKNOWLEDGEMENTS 296 The authors would like to acknowledge the UK EP-SRC Digital Economy 297 Programme and the Government of India Department of Science and 298 Technology (DST) for funding given to the IU-ATC. 300 3 Security Considerations 302 Encryption of the packets funneled to the analyzing devices needs to 303 be considered. 305 4 IANA Considerations 307 Appropriate IANA indicators would have to be provided to exchange the 308 set of values that Algorithm 1,2 outlines in order to implement this 309 scheme. 311 5 References 313 5.1 Normative References 315 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 319 1 1995. 321 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 322 April 1 1996. 324 5.2 Informative References 326 [1] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS 327 security: an approach for unicast and multicast 328 environments", Annals of Telecommunications, Springer, 329 vol. 64, no. 5, June 2009, pp. 391-400, 330 doi:10.1007/s12243-009-0089-y. 332 [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security", 333 Cisco Press, June 2005, ISBN-10: 1587051834. 335 [3] B. Daugherty and C. Metz, "Multiprotocol Label 336 Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE 337 Internet Computing, May-June 2005, pp. 68-72, doi: 338 10.1109/MIC.2005.61. 340 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 341 "Interprovider IP-MPLS services: requirements, 342 implementations, and challenges", IEEE Communications 343 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 344 10.1109/MCOM.2005.1452840. 346 [5] C. Lin and W. Guowei, "Security research of VPN 347 technology based on MPLS", Proceedings of the Third 348 International Symposium on Computer Science and 349 Computational Technology (ISCSCT 10), August 2010, pp. 350 168-170, ISBN- 13:9789525726107. 352 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 353 Farinacci and D. Katz, "Tag switching architecture 354 overview", Proceedings of the IEEE, vol. 85, no. 12, 355 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 357 [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 358 Networks (VPNs)", RFC 4364, Standard Track, February, 359 2006. 361 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 362 Stein, "Introduction to algorithms", 3rd edition, MIT 363 Press, September 2009, ISBN-10:0262033844. 365 [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals", 366 Juniper Networks white paper, March 2001. 368 [10] Advance MPLS VPN Security Tutorials [Online], 369 Available: 370 "http://etutorials.org/Networking/MPLS+VPN+security/ 371 Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed: 372 10th December 2011] 374 [11] Inter-provider MPLS VPN models [Online], Available: 375 "http://mpls-configuration-on-cisco-iossoftware. 376 org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th 377 December 2011] 379 [12] Davari.S et.al, Transporting PTP messages (1588) over 380 MPLS networks, "http://datatracker.ietf.org/doc/draft- 381 ietf-tictoc-1588overmpls/?include_text=1", Work in 382 Progress, October 2011. 384 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 385 RFC 3514, April 1 2003. 387 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 388 Acronyms", RFC 5513, April 1 2009. 390 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 391 2009. 393 Authors' Addresses 395 Shankar Raman 396 Department of Computer Science and Engineering 397 IIT Madras, 398 Chennai - 600036 399 TamilNadu, 400 India. 402 EMail: mjsraman@cse.iitm.ac.in 404 Balaji Venkat Venkataswami 405 Department of Electrical Engineering, 406 IIT Madras, 407 Chennai - 600036, 408 TamilNadu, 409 India. 411 EMail: balajivenkat299@gmail.com 413 Prof.Gaurav Raina 414 Department of Electrical Engineering, 415 IIT Madras, 416 Chennai - 600036, 417 TamilNadu, 418 India. 420 EMail: gaurav@ee.iitm.ac.in 422 Bhargav Bhikkaji 423 Dell-Force10, 424 350 Holger Way, 425 San Jose, CA 426 U.S.A 428 Email: Bhargav_Bhikkaji@dell.com