idnits 2.17.1 draft-balaji-mpls-li-thru-label-dis-snmp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 4085 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 157, but not defined == Unused Reference: '1a' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 396, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 399, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 425, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 432, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 438, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC3924' is defined on line 448, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-balaji-mpls-lawful-intercept-thru-label-dis-02 -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. '9') (Obsoleted by RFC 4364) Summary: 1 error (**), 0 flaws (~~), 16 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 2013 Vasan Srini 6 IIT Madras 7 Bhargav Bhikkaji 8 Dell-Force10 9 February 18, 2013 11 SNMP based Provider-Provisioned label for Lawful Intercept in L3 VPNs 12 draft-balaji-mpls-li-thru-label-dis-snmp-01 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. This differs from [1] in that 37 there is explicit use of a secure SNMP mechanism to provision the 38 labels for Lawful Intercept at the various PEs instead of a MP-BGP 39 update. 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as 49 Internet-Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/1id-abstracts.html 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html 62 Copyright and License Notice 64 Copyright (c) 2013 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. Methodology of the proposal . . . . . . . . . . . . . . . . . 5 82 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned 83 SCHEME for LI . . . . . . . . . . . . . . . . . . . . . . . 5 84 2.1.1 Configuring Lawful Intercept for a specific VPN 85 instance on a specific PE . . . . . . . . . . . . . . . 5 86 2.1.2.1 PE configuration . . . . . . . . . . . . . . . . . . 5 87 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 5 88 2.2 Domino-effect technique . . . . . . . . . . . . . . . . . . 6 89 2.2.0 Per-Prefix label to Per-VRF LI label . . . . . . . . . . 7 90 2.2.1 Algorithm 1 Control-plane dPE algorithm . . . . . . . . 7 91 2.2.2 Algorithm 2 Control-plane sPE algorithm . . . . . . . . 7 92 2.2.3 Algorithm 3 Data-plane dPE algorithm . . . . . . . . . . 8 93 2.2.4 Monitoring specific flows . . . . . . . . . . . . . . . 8 94 2.2.5 Hierarchalizing the GRE key . . . . . . . . . . . . . . 8 95 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 9 96 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 9 97 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 98 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 99 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 100 5.1 Normative References . . . . . . . . . . . . . . . . . . . 10 101 5.2 Informative References . . . . . . . . . . . . . . . . . . 10 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 104 1 Introduction 106 Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size 107 labels to forward data packets between routers. By stacking labels, 108 specific customer services such as Layer 3 Virtual Private Networks 109 (L3-VPNs) based on Border Gateway Protocol (BGP) extensions are 110 widely deployed in the Internet. BGP-based MPLS L3-VPN services are 111 provided either on a single Internet Service Provider (ISP) core or 112 across multiple ISP cores. The latter cases are known as inter- 113 provider MPLS L3-VPNs which are broadly categorized and referred to 114 as models: "A", "B" and "C". 116 In all the above cases both Single-AS and inter-provider VPN cases 117 for Layer 3 VPNs it is important that the provider or multiple 118 providers have a co-ordinated mechanism of lawfully intercepting 119 traffic to and from Provider Edge Routers (PEs) belonging to one or 120 more VPN instances for the VPN instance as a whole or for a specific 121 subnet / prefix. 123 This paper outlines a label-based Provider Provisioning technique 124 that helps to provide a single point of action for lawfully 125 intercepting through traffic mirroring or other such techniques of 126 data flowing to and from one or more PEs or all of the PEs that 127 constitute a particular VPN instance. More than one VPN instance may 128 be configured with this technique. Also Enhanced Remote SPAN with GRE 129 keying mechanism is used to transport the intercepted packets to a 130 Lawful Intercept device where it may be examined and analyzed by 131 Government Authorities. 133 In the spirit of RFC 2804 and given that RFC 3924 that already 134 exists, this mechanism can be considered from the point of view of an 135 Experimental draft. No other opinion is professed except to document 136 this as a possible method to use in times of crisis and emergency. In 137 the spirit of 2804 which states and we quote... 139 - On the other hand, the IETF believes that mechanisms designed to 140 facilitate or enable wiretapping, or methods of using other 141 facilities for such purposes, should be openly described, so as to 142 ensure the maximum review of the mechanisms and ensure that they 143 adhere as closely as possible to their design constraints. The IETF 144 believes that the publication of such mechanisms, and the publication 145 of known weaknesses in such mechanisms, is a Good Thing." 147 End of Quote. 149 Hence we submit this document for review in the spirit of what is 150 said above. 152 1.1 Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 2. Methodology of the proposal 160 2.1 PRE-REQUISITES FOR THE LABEL-BASED Provider-Provisioned SCHEME for 161 LI 163 In this section, we briefly review the pre-requisites for applying 164 this technique in terms of the PE configuration and the control-plane 165 exchanges needed for our proposed scheme. 167 2.1.1 Configuring Lawful Intercept for a specific VPN instance on a 168 specific PE 170 The regular mechanisms using SNMP using the TAP-MIB can be used to 171 configure the requirement to intercept traffic going to and from a 172 given PE router. This very mechanism is used to initiate the scheme 173 mentioned in this document. 175 2.1.2.1 PE configuration 177 Various configurations are needed on the PEs to implement the label 178 based Lawful Intercept scheme. A set of pre-defined labels called the 179 Lawful Intercept labels are provided for a VPN instance that is 180 configured on the PE. In the simplest case one single Lawful 181 Intercept label may be used per VPN instance . In this draft, we 182 assume that a single label based lawful intercept is used per VPN 183 instance per PE for cases where the whole VPN site traffic needs to 184 be trapped. For cases where specific flows are required to be 185 monitored section 2.2.4 outlines the necessary actions to be taken. 187 2.1.3 Control and data-plane flow 189 Initially, the usual control plane exchanges take place where the 190 labels configured for the Layer 3 VPN instance between the various 191 PEs participating for that VPN instance are exchanged securely over 192 the control-plane. 194 Appropriate Lawful Intercept labels are configured or a knob that 195 allocates them automatically is configured. These labels are not 196 exchanged at the time when the LI based mechanism is not in place, 197 meaning the TAP-MIBs are not yet setup for LI for a VPN instance. 199 Appropriate ports that will mirror these LI intercepted frames are 200 set up and pre-provisioned with links to the devices that will 201 analyze the data when such interception occurs. 203 Once the secure control-plane exchanges are completed, normal traffic 204 starts to flow. It is possible then that an event occurs which 205 results in a PE being configured for Lawful Intercept to take place. 206 Such an event could be a police tipoff, external intelligence inputs 207 and other events. The exact set of events that will trigger LI are 208 outside the scope of this document. Once the PE (which we will call 209 the dPE) is configured with this, the control plane in this case SNMP 210 then sends over the LI label to the other PEs of the same VPN 211 instance in the form of a secure SNMP PDU with the relevant details 212 such as 214 a) Prefix for which LI is to be enforced 216 b) Actual LI label to be used 218 c) DominoEffectTrigger Flag (OFF or ON) 220 These other PEs called the sPEs (or the source PEs for short), then 221 install this LI label to be the inner label or the VPN service label 222 in their packets they send to the dPE. Appropriate ACLs configured 223 for intercepting packets coming into the dPE with the LI label route 224 the traffic to the mirroring port on the dPE. This is then 225 encapsulated in a GRE tunnel and sent over to the Government network 226 after suitable encryption if necessary. 228 2.2 Domino-effect technique 230 In this case called the Domino-effect technique, all sPEs receiving 231 control plane exchanges with an indication that a LI label is being 232 requested to be installed on them in turn also send their respective 233 LI labels to other PEs in distinct control plane exchanges through 234 SNMP. This will result in the entire VPNs traffic being monitored at 235 the various participating PEs for that VPN. 237 As already mentioned appropriate Access Control Entries (ACEs) in the 238 PEs will direct the traffic coming in with these LI labels to the 239 mirroring ports, one or more if any. 241 The inner label information is mapped to a GRE key and the mirrored 242 packets at the intercepting dPE are sent with this GRE key in place 243 with of course the GRE encapsulation to the analyzing network 244 devices. Additional information as to which sPE the traffic came from 245 is thus added to the packet in the form of the GRE key. The exact 246 means of this technique is upto the implementer to take up. 248 2.2.0 Per-Prefix label to Per-VRF LI label 250 If the configuration on the dPE is to disseminate per-prefix labels 251 then the introduction of the LI label is such that it (the LI label) 252 is advertised as a an aggregate per-VRF label so that all of the 253 traffic is bunched together in the transmit and/or the receive 254 direction to the dPE and from the dPE pivoting around an appropriate 255 single LI label so that it can be easily trapped by the ACE entry in 256 the dPE (and if the domino is triggered in the sPEs as well) to get 257 mirrored onto one or more ports. 259 2.2.1 Algorithm 1 Control-plane dPE algorithm 261 Require: 262 * K Valid Lawful Intercept labels per VPN for FECs to be monitored 263 * If in case the whole VPN site then a single label 264 * else specific LI labels for each prefix to be monitored 265 at required granularity as per VRF route entries. 267 Begin 268 Get event that triggers configuration in the TAP-MIB; 270 Get TAP-MIB configured particulars about which VPN and whether 271 FlagTriggerDominoEffect is set; 273 packet = makeSNMPpacket(K[VPN Instance or FECinVPN], 274 FlagTriggerDominoEffect); 276 For all sPEs in the VPN 278 CP-SendPacket(sPE[j], Secure-SNMP, packet); 280 endFor 281 End 283 2.2.2 Algorithm 2 Control-plane sPE algorithm 285 Require: None 286 Begin 287 SNMPpacket = CP-ReceivePacket(dPE); // from dPE 288 Label = ExtractLabel(SNMPpacket); // extract LI label 289 if (Label is LI label as indicated by SNMP ObjectID information) then 290 Set Label in Forwarding table for the VPN; 291 endif 292 FlagTriggerDominoEffect = ExtractFlags(SNMPpacket); 293 if (FlagTriggerDominoEffect) then 294 Run Algorithm 1 on the sPE (as the dPE); 295 End 297 2.2.3 Algorithm 3 Data-plane dPE algorithm 299 Require: None 301 Begin 302 packet = DP-ReceivePacket(Interface); 303 if ((Label of packet is == LI label for VPN) && 304 (ACL configured for the said Label)) 305 then 307 mirror packet with all information after mapping 308 VPN label to GRE key which indicates dPE; 310 Encapsulate packet in GRE header and mirror it 311 to appropriate port; 313 endif 314 End 316 2.2.4 Monitoring specific flows 318 There would be a necessity to monitor specific flows headed towards 319 and from a subnet or a specific IP address within a site. This 320 monitoring would be needed to be done at all sites to which this 321 subnet or specific IP address within the monitored VRF communicates 322 with. For this specific purpose the LI label may be sent from the dPE 323 to the sPEs (with say the DominoEffectTrigger Flag set) for the 324 specific prefix / subnet / IP address. Though the specific IP address 325 cannot be trapped with a prefix entry with the LI label alone, 326 specific Access Control Lists may be setup at all dPEs where the 327 monitoring takes place to trap the specific IP address in particular. 328 The flexibility lies with both the LI label based on prefix and the 329 consequent Access Control List configured collaboratively working 330 together to monitor the specific IP address or even subnet / prefix. 332 The algorithm in 2.2.1 to 2.2.3 apply for the specific flow 333 monitoring cases as well. 335 2.2.5 Hierarchalizing the GRE key 337 The GRE key can be organized in a hierarchy with respect to site and 338 PE information for a provider who is providing the label based lawful 339 intercept. Since the GRE key is a 32 bit entity, the site could be 20 340 bit ID with the Provider edge router providing the facility being 341 indicated by a 12 bit identifier. The source IP address being the 342 indicator of the provider / ISP who is providing the facility the 343 hierarchy in the GRE key would indicate the location and the PE 344 device from where the frames are being trapped. The intercepting 345 authority could thus figure out in the clutter of information as to 346 where the encapsulated frames are being emanated from. A common 347 registry for the site identifier could be provided and set in the GRE 348 key information thus dilineating information coming from different PE 349 devices in different locations. It is suffice to say that a 20 bit 350 identifier for the site could cover the location. In turn the site 351 identifier could be broken into Country code and Zip code as well in 352 the registry. 354 2.4 CONCLUSION AND FUTURE WORK 356 Additionally this same idea can be applied for L2-VPNs as well. A 357 future draft in this area will be published in due course. 359 2.5 ACKNOWLEDGEMENTS 361 The authors would like to acknowledge the UK EP-SRC Digital Economy 362 Programme and the Government of India Department of Science and 363 Technology (DST) for funding given to the IU-ATC. 365 3 Security Considerations 367 Encryption of the packets funneled to the analyzing devices needs to 368 be considered. 370 4 IANA Considerations 372 Appropriate SNMP MIB particulars need to be drawn up to support this 373 mechanism. Vendor specific MIBs are a good choice to deploy this 374 scheme. That way IANA indicators would not have to be provided to 375 exchange the set of values that Algorithm 1,2 outlines in order to 376 implement this scheme like if say BGP were to be used for the control 377 plane exchanges. 379 5 References 381 5.1 Normative References 383 5.2 Informative References 385 [1] Shankar Raman et.al, "Label based Provider- 386 Provisioned Lawful Intercept for L3 VPNs", draft-balaji- 387 mpls-lawful-intercept-thru-label-dis-02.txt, Work in 388 Progress, August 2012. 390 [1a] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS 391 security: an approach for unicast and multicast 392 environments", Annals of Telecommunications, Springer, 393 vol. 64, no. 5, June 2009, pp. 391-400, 394 doi:10.1007/s12243-009-0089-y. 396 [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security", 397 Cisco Press, June 2005, ISBN-10: 1587051834. 399 [3] B. Daugherty and C. Metz, "Multiprotocol Label 400 Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE 401 Internet Computing, May-June 2005, pp. 68-72, doi: 402 10.1109/MIC.2005.61. 404 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 405 "Interprovider IP-MPLS services: requirements, 406 implementations, and challenges", IEEE Communications 407 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 408 10.1109/MCOM.2005.1452840. 410 [5] C. Lin and W. Guowei, "Security research of VPN 411 technology based on MPLS", Proceedings of the Third 412 International Symposium on Computer Science and 413 Computational Technology (ISCSCT 10), August 2010, pp. 414 168-170, ISBN- 13:9789525726107. 416 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 417 Farinacci and D. Katz, "Tag switching architecture 418 overview", Proceedings of the IEEE, vol. 85, no. 12, 419 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 421 [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 422 Networks (VPNs)", RFC 4364, Standard Track, February, 423 2006. 425 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 426 Stein, "Introduction to algorithms", 3rd edition, MIT 427 Press, September 2009, ISBN-10:0262033844. 429 [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals", 430 Juniper Networks white paper, March 2001. 432 [10] Advance MPLS VPN Security Tutorials [Online], 433 Available: 434 "http://etutorials.org/Networking/MPLS+VPN+security/ 435 Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed: 436 10th December 2011] 438 [11] Inter-provider MPLS VPN models [Online], Available: 439 "http://mpls-configuration-on-cisco-iossoftware. 440 org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th 441 December 2011] 443 [12] Davari.S et.al, Transporting PTP messages (1588) over 444 MPLS networks, "http://datatracker.ietf.org/doc/draft- 445 ietf-tictoc-1588overmpls/?include_text=1", Work in 446 Progress, October 2011. 448 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 449 for Lawful Intercept in IP Networks", RFC 3924, October 450 2004. 452 Authors' Addresses 454 Shankar Raman 455 Department of Computer Science and Engineering 456 IIT Madras 457 Chennai - 600036 458 TamilNadu 459 India 461 EMail: mjsraman@cse.iitm.ac.in 463 Balaji Venkat Venkataswami 464 Department of Electrical Engineering 465 IIT Madras 466 Chennai - 600036 467 TamilNadu 468 India. 470 EMail: balajivenkat299@gmail.com 472 Prof.Gaurav Raina 473 Department of Electrical Engineering 474 IIT Madras 475 Chennai - 600036 476 TamilNadu 477 India. 479 EMail: gaurav@ee.iitm.ac.in 481 Bhargav Bhikkaji 482 Dell-Force10 483 350 Holger Way 484 San Jose 485 CA 486 USA 488 Email: Bhargav_Bhikkaji@dell.com 490 Vasan Srini 491 Department of Computer Science and Engineering 492 IIT Madras 493 Chennai - 600036 494 TamilNadu 495 India. 497 EMail: vasan.vs@gmail.com