idnits 2.17.1 draft-balaji-mpls-lawful-intercept-thru-label-dis-03.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 (February 18, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 153, but not defined == Unused Reference: '1' is defined on line 373, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 379, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 382, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 393, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC3924' is defined on line 431, 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 (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Shankar Raman 3 Internet-Draft Balaji Venkat Venkataswami 4 Intended Status: Experimental RFC Gaurav Raina 5 Expires: August 22, 2013 Vasan Srini 6 IIT Madras 7 Bhargav Bhikkaji 8 Dell-Force10 9 February 18, 2013 11 Label-based Provider-Provisioned Lawful Intercept for L3 VPNs 12 draft-balaji-mpls-lawful-intercept-thru-label-dis-03 14 Abstract 16 In models of Single-AS and inter-provider Multi- Protocol Label 17 Switching (MPLS) based Virtual Private Networks (VPNs) Lawful 18 Intercept is a key requirement. For example, MPLS-based Layer 3 VPN 19 models do not have any provider provisioned methods of lawful 20 intercept that are comprehensive, quick and easy to provision from 21 one single point. More particularly the auto-provisioning of lawful 22 intercept for all sets of streams travelling between VPN sites and 23 consequent re-direction of these streams to the appropriate 24 government network has not been covered without multiple instances of 25 having to configure the intercept at various points in the network 26 both in the Single-AS case and the Inter-Provider VPN case. 28 In 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 action is the key to this idea. The intercepted traffic is 33 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.0 Per-Prefix label to Per-VRF LI label . . . . . . . . . . 6 87 2.2.1 Algorithm 1 Control-plane dPE algorithm . . . . . . . . 7 88 2.2.2 Algorithm 2 Control-plane sPE algorithm . . . . . . . . 7 89 2.2.3 Algorithm 3 Data-plane dPE algorithm . . . . . . . . . . 8 90 2.2.4 Monitoring specific flows . . . . . . . . . . . . . . . 8 91 2.2.5 Hierarchalizing the GRE key . . . . . . . . . . . . . . 8 92 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 9 93 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 9 94 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 95 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 96 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 97 5.1 Normative References . . . . . . . . . . . . . . . . . . . 10 98 5.2 Informative References . . . . . . . . . . . . . . . . . . 10 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 101 1 Introduction 103 Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size 104 labels to forward data packets between routers. By stacking labels, 105 specific customer services such as Layer 3 Virtual Private Networks 106 (L3-VPNs) based on Border Gateway Protocol (BGP) extensions are 107 widely deployed in the Internet. BGP-based MPLS L3-VPN services are 108 provided either on a single Internet Service Provider (ISP) core or 109 across multiple ISP cores. The latter cases are known as inter- 110 provider MPLS L3-VPNs which are broadly categorized and referred to 111 as models: "A", "B" and "C". 113 In all the above cases both Single-AS and inter-provider VPN cases 114 for Layer 3 VPNs it is important that the provider or multiple 115 providers have a co-ordinated mechanism of lawfully intercepting 116 traffic to and from Provider Edge Routers (PEs) belonging to one or 117 more VPN instances. 119 This paper outlines a label-based Provider Provisioning technique 120 that helps to provide a single point of action for lawfully 121 intercepting through traffic mirroring or other such techniques of 122 data flowing to and from one or more PEs or all of the PEs that 123 constitute a particular VPN instance. More than one VPN instance may 124 be configured with this technique. Also Enhanced Remote SPAN with GRE 125 keying mechanism is used to transport the intercepted packets to a 126 Lawful Intercept device where it may be examined and analyzed by 127 Government Authorities. 129 In the spirit of RFC 2804 and given that RFC 3924 that already 130 exists, this mechanism can be considered from the point of view of an 131 Experimental draft. No other opinion is professed except to document 132 this as a possible method to use in times of crisis and emergency. In 133 the spirit of 2804 which states and we quote... 135 - On the other hand, the IETF believes that mechanisms designed to 136 facilitate or enable wiretapping, or methods of using other 137 facilities for such purposes, should be openly described, so as to 138 ensure the maximum review of the mechanisms and ensure that they 139 adhere as closely as possible to their design constraints. The IETF 140 believes that the publication of such mechanisms, and the publication 141 of known weaknesses in such mechanisms, is a Good Thing." 143 End of Quote. 145 Hence we submit this document for review in the spirit of what is 146 said above. 148 1.1 Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. Methodology of the proposal 156 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for 157 LI 159 In this section, we briefly review the pre-requisites for applying 160 this technique in terms of the PE configuration and the control-plane 161 exchanges needed for our proposed scheme. 163 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a 164 specific PE 166 The regular mechanisms using SNMP using the TAP-MIB can be used to 167 configure the requirement to intercept traffic going to and from a 168 given PE router. This very mechanism is used to initiate the scheme 169 mentioned in this document. 171 2.1.2.1 PE configuration 173 Various configurations are needed on the PEs to implement the label 174 based Lawful Intercept scheme. A set of pre-defined labels called the 175 Lawful Intercept labels are provided for a VPN instance that is 176 configured on the PE. In the simplest case one single Lawful 177 Intercept label may be used per VPN instance . In this draft, we 178 assume that a single label based lawful intercept is used per VPN 179 instance per PE for cases where the whole VPN site traffic needs to 180 be trapped. For cases where specific flows are required to be 181 monitored section 2.2.4 outlines the necessary actions to be taken. 183 2.1.3 Control and data-plane flow 185 Initially, the usual control plane exchanges take place where the 186 labels configured for the Layer 3 VPN instance between the various 187 PEs participating for that VPN instance are exchanged securely over 188 the control-plane. 190 Appropriate Lawful Intercept labels are configured or a knob that 191 allocates them automatically is configured. These labels are not 192 exchanged at the time when the LI based mechanism is not in place, 193 meaning the TAP-MIBs are not yet setup for LI for a VPN instance. 195 Appropriate ports that will mirror these LI intercepted frames are 196 set up and pre-provisioned with links to the devices that will 197 analyze the data when such interception occurs. 199 Once the secure control-plane exchanges are completed, normal traffic 200 starts to flow. It is possible then that an event occurs which 201 results in a PE being configured for Lawful Intercept to take place. 202 Such an event could be a police tipoff, external intelligence inputs 203 and other events. The exact set of events that will trigger LI are 204 outside the scope of this document. Once the PE (which we will call 205 the dPE) is configured with this, the control plane for example MP- 206 BGP (where BGP is used for control plane exchanges), then sends over 207 the LI label to the other PEs of the same VPN instance. These other 208 PEs called the sPEs (or the source PEs for short), then install this 209 LI label to be the inner label or the VPN service label in their 210 packets they send to the dPE. Appropriate ACLs configured for 211 intercepting packets coming into the dPE with the LI label route the 212 traffic to the mirroring port on the dPE. This is then encapsulated 213 in a GRE tunnel and sent over to the Government network after 214 suitable encryption if necessary. 216 2.2 Domino-effect technique 218 In this case called the Domino-effect technique, all sPEs receiving 219 control plane exchanges with an indication that a LI label is being 220 requested to be installed on them in turn also send their respective 221 LI labels to other PEs in distinct control plane exchanges. This will 222 result in the entire VPNs traffic being monitored at the various 223 participating PEs for that VPN. 225 An appropriate indicator in the control plane exchange, in the case 226 of BGP for example, a special tag in the NLRI information would 227 indicate that this is an LI label. As already mentioned appropriate 228 Access Control Entries (ACEs) in the PEs will direct the traffic 229 coming in with these LI labels to the mirroring ports, one or more if 230 any. 232 The inner label information is mapped to a GRE key and the mirrored 233 packets at the intercepting dPE are sent with this GRE key in place 234 with of course the GRE encapsulation to the analyzing network 235 devices. Additional information as to which sPE the traffic came from 236 is thus added to the packet in the form of the GRE key. The exact 237 means of this technique is upto the implementer to take up. 239 2.2.0 Per-Prefix label to Per-VRF LI label 241 If the configuration on the dPE is to disseminate per-prefix labels 242 then the introduction of the LI label is such that it (the LI label) 243 is advertised as a an aggregate per-VRF label so that all of the 244 traffic is bunched together in the transmit and/or the receive 245 direction to the dPE and from the dPE pivoting around an appropriate 246 single LI label so that it can be easily trapped by the ACE entry in 247 the dPE (and if the domino is triggered in the sPEs as well) to get 248 mirrored onto one or more ports. 250 2.2.1 Algorithm 1 Control-plane dPE algorithm 252 Require: 253 * K Valid Lawful Intercept labels per VPN for FECs to be monitored 254 * If in case the whole VPN site then a single label 255 * else specific LI labels for each prefix to be monitored 256 at required granularity as per VRF route entries. 258 Begin 259 Get event that triggers configuration in the TAP-MIB; 261 Get TAP-MIB configured particulars about which VPN and whether 262 FlagTriggerDominoEffect is set; 264 packet = makepacket(K[VPN Instance or FECinVPN], 265 FlagTriggerDominoEffect); 267 For all sPEs in the VPN 269 CP-SendPacket(sPE[j], MP-BGP, packet); 271 endFor 272 End 274 2.2.2 Algorithm 2 Control-plane sPE algorithm 276 Require: None 277 Begin 278 packet = CP-ReceivePacket(dPE); // from dPE 279 Label = ExtractLabel(packet); // extract LI label 280 if (Label is LI label as indicated by NLRI information) then 281 Set Label in Forwarding table for the VPN; 282 endif 283 FlagTriggerDominoEffect = ExtractFlags(packet); 284 if (FlagTriggerDominoEffect) then 285 Run Algorithm 1 on the sPE (as the dPE); 286 End 288 2.2.3 Algorithm 3 Data-plane dPE algorithm 290 Require: None 292 Begin 293 packet = DP-ReceivePacket(Interface); 294 if ((Label of packet is == LI label for VPN) && 295 (ACL configured for the said Label)) 296 then 298 mirror packet with all information after mapping 299 VPN label to GRE key which indicates dPE; 301 Encapsulate packet in GRE header and mirror it 302 to appropriate port; 304 endif 305 End 307 2.2.4 Monitoring specific flows 309 There would be a necessity to monitor specific flows headed towards 310 and from a subnet or a specific IP address within a site. This 311 monitoring would be needed to be done at all sites to which this 312 subnet or specific IP address within the monitored VRF communicates 313 with. For this specific purpose the LI label may be sent from the dPE 314 to the sPEs (with say the DominoEffectTrigger Flag set) for the 315 specific prefix / subnet / IP address. Though the specific IP address 316 cannot be trapped with a prefix entry with the LI label alone, 317 specific Access Control Lists may be setup at all dPEs where the 318 monitoring takes place to trap the specific IP address in particular. 319 The flexibility lies with both the LI label based on prefix and the 320 consequent Access Control List configured collaboratively working 321 together to monitor the specific IP address or even subnet / prefix. 323 The algorithm in 2.2.1 to 2.2.3 apply for the specific flow 324 monitoring cases as well. 326 2.2.5 Hierarchalizing the GRE key 328 The GRE key can be organized in a hierarchy with respect to site and 329 PE information for a provider who is providing the label based lawful 330 intercept. Since the GRE key is a 32 bit entity, the site could be 20 331 bit ID with the Provider edge router providing the facility being 332 indicated by a 12 bit identifier. The source IP address being the 333 indicator of the provider / ISP who is providing the facility the 334 hierarchy in the GRE key would indicate the location and the PE 335 device from where the frames are being trapped. The intercepting 336 authority could thus figure out in the clutter of information as to 337 where the encapsulated frames are being emanated from. A common 338 registry for the site identifier could be provided and set in the GRE 339 key information thus dilineating information coming from different PE 340 devices in different locations. It is suffice to say that a 20 bit 341 identifier for the site could cover the location. In turn the site 342 identifier could be broken into Country code and Zip code as well in 343 the registry. 345 2.4 CONCLUSION AND FUTURE WORK 347 Additionally this same idea can be applied for L2-VPNs as well. A 348 future draft in this area will be published in due course. 350 2.5 ACKNOWLEDGEMENTS 352 The authors would like to acknowledge the UK EP-SRC Digital Economy 353 Programme and the Government of India Department of Science and 354 Technology (DST) for funding given to the IU-ATC. 356 3 Security Considerations 358 Encryption of the packets funneled to the analyzing devices needs to 359 be considered. 361 4 IANA Considerations 363 Appropriate IANA indicators would have to be provided to exchange the 364 set of values that Algorithm 1,2 outlines in order to implement this 365 scheme. 367 5 References 369 5.1 Normative References 371 5.2 Informative References 373 [1] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS 374 security: an approach for unicast and multicast 375 environments", Annals of Telecommunications, Springer, 376 vol. 64, no. 5, June 2009, pp. 391-400, 377 doi:10.1007/s12243-009-0089-y. 379 [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security", 380 Cisco Press, June 2005, ISBN-10: 1587051834. 382 [3] B. Daugherty and C. Metz, "Multiprotocol Label 383 Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE 384 Internet Computing, May-June 2005, pp. 68-72, doi: 385 10.1109/MIC.2005.61. 387 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 388 "Interprovider IP-MPLS services: requirements, 389 implementations, and challenges", IEEE Communications 390 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 391 10.1109/MCOM.2005.1452840. 393 [5] C. Lin and W. Guowei, "Security research of VPN 394 technology based on MPLS", Proceedings of the Third 395 International Symposium on Computer Science and 396 Computational Technology (ISCSCT 10), August 2010, pp. 397 168-170, ISBN- 13:9789525726107. 399 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 400 Farinacci and D. Katz, "Tag switching architecture 401 overview", Proceedings of the IEEE, vol. 85, no. 12, 402 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 404 [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 405 Networks (VPNs)", RFC 4364, Standard Track, February, 406 2006. 408 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 409 Stein, "Introduction to algorithms", 3rd edition, MIT 410 Press, September 2009, ISBN-10:0262033844. 412 [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals", 413 Juniper Networks white paper, March 2001. 415 [10] Advance MPLS VPN Security Tutorials [Online], 416 Available: 417 "http://etutorials.org/Networking/MPLS+VPN+security/ 418 Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed: 419 10th December 2011] 421 [11] Inter-provider MPLS VPN models [Online], Available: 422 "http://mpls-configuration-on-cisco-iossoftware. 423 org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th 424 December 2011] 426 [12] Davari.S et.al, Transporting PTP messages (1588) over 427 MPLS networks, "http://datatracker.ietf.org/doc/draft- 428 ietf-tictoc-1588overmpls/?include_text=1", Work in 429 Progress, October 2011. 431 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 432 for Lawful Intercept in IP Networks", RFC 3924, October 433 2004. 435 Authors' Addresses 437 Shankar Raman 438 Department of Computer Science and Engineering 439 IIT Madras 440 Chennai - 600036 441 TamilNadu 442 India 444 EMail: mjsraman@cse.iitm.ac.in 445 Balaji Venkat Venkataswami 446 Department of Electrical Engineering 447 IIT Madras 448 Chennai - 600036 449 TamilNadu 450 India 452 EMail: balajivenkat299@gmail.com 454 Prof.Gaurav Raina 455 Department of Electrical Engineering 456 IIT Madras 457 Chennai - 600036 458 TamilNadu 459 India 461 EMail: gaurav@ee.iitm.ac.in 463 Bhargav Bhikkaji 464 Dell-Force10 465 350 Holger Way 466 San Jose 467 CA 468 USA 470 Email: Bhargav_Bhikkaji@dell.com 472 Vasan Srini 473 Department of Computer Science and Engineering 474 IIT Madras 475 Chennai - 600036 476 TamilNadu 477 India 479 EMail: vasan.vs@gmail.com