idnits 2.17.1 draft-mjsraman-l2vpn-vpls-tictoc-label-hop-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 : ---------------------------------------------------------------------------- ** There are 16 instances of lines with control characters in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (April 8, 2013) is 4029 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 182 -- Looks like a reference, but probably isn't: 'CurrentTimeSliceIndex' on line 453 == Unused Reference: '7' is defined on line 698, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 709, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. '9') (Obsoleted by RFC 4364) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 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: October 10, 2013 IIT Madras 6 Bhargav Bhikkaji 7 Dell-Force10 8 April 8, 2013 10 Securing Model-C Inter-Provider L2 VPNs with Label Hopping and TicToc 11 draft-mjsraman-l2vpn-vpls-tictoc-label-hop-03 13 Abstract 15 In certain models of inter-provider Multi- Protocol Label Switching 16 (MPLS) based Virtual Private Networks (VPNs) spoofing attack against 17 VPN sites is a key concern. For example, MPLS-based VPN inter- 18 provider model "C" for VPLS, or any L2 VPN purpose is not favoured, 19 owing to security concerns in the dataplane, even though it can scale 20 with respect to maintenance of routing state. Since the inner labels 21 associated with VPN sites are not encrypted during transmission, a 22 man-in-the-middle attacker can spoof packets to a specific L2 VPN 23 site. In this paper, we propose a label-hopping technique which uses 24 a set of randomized labels and a method for hopping amongst these 25 labels using the time instant the packet leaves the port from a 26 sending Provider Edge Router. To prevent the attacker from 27 identifying the labels in polynomial time, we also use an additional 28 label. The proposed technique can be applied to other variants of 29 inter-provider MPLS based VPNs where Multi-Protocol exterior-BGP (MP- 30 eBGP) multi-hop is used. As we address a key security concern, we can 31 make a case for the deployment of MPLS based L2 VPN inter-provider 32 model "C". Specifically we use the TicToc based Precision Time 33 Protocol LSP to provide the timing for determining the time instant 34 at which the packet is sent from the remote end Provider Edge Router 35 and hence calculating when it must have left that peer at the 36 Provider Edge Router in the near / receiving end. 38 This version of the document suggests a better method for gaining 39 more finely granular time slices. This is done by running the PTP LSP 40 between the ASBRs in the ASes that are providing the inter-AS L2VPN 41 service. 43 Status of this Memo 45 This Internet-Draft is submitted to IETF in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as 51 Internet-Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/1id-abstracts.html 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 Copyright and License Notice 66 Copyright (c) 2013 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2. Methodology of the proposal . . . . . . . . . . . . . . . . . 5 84 2.1 PRE-REQUISITES FOR THE LABEL-HOPPING SCHEME . . . . . . . . 5 85 2.1.1 MPLS L2 VPN model "C" . . . . . . . . . . . . . . . . . 5 86 2.1.2 PE configuration . . . . . . . . . . . . . . . . . . . . 6 87 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 6 88 2.2 LABEL-HOPPING TECHNIQUE . . . . . . . . . . . . . . . . . . 7 89 2.2.1 Algorithm 1 Control-plane PEne algorithm . . . . . . . . 8 90 2.2.2 Algorithm 2 Control-plane PEfa algorithm . . . . . . . . 10 91 2.2.3 Algorithm 3 Data-plane PEfa algorithm . . . . . . . . . 11 92 2.2.4 Algorithm 4 Data-plane PEne algorithm . . . . . . . . . 12 93 2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . 13 94 2.3 SIMULATION AND IMPLEMENTATION . . . . . . . . . . . . . . . 14 95 2.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . 14 96 2.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . 14 97 2.3.3 Running the PTP LSP and label hopping at the ASBRs . . . 15 98 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 16 99 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 16 100 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 101 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 102 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 5.1 Normative References . . . . . . . . . . . . . . . . . . . 17 104 5.2 Informative References . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 107 1 Introduction 109 Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size 110 labels to forward data packets between routers. By stacking labels, 111 specific customer services such as Layer 2 Virtual Private Networks 112 (L2-VPNs) such as VPLS (Virtual Private Lan Service) based on Border 113 Gateway Protocol (BGP) extensions are widely deployed in the 114 Internet. BGP-based MPLS L2-VPN services are provided either on a 115 single Internet Service Provider (ISP) core or across multiple ISP 116 cores. The latter cases are known as inter-provider MPLS L2-VPNs 117 which are broadly categorized and referred to as models: "A", "B" and 118 "C". 120 Model "A" uses back-to-back VPN Routing and Forwarding (VRF) 121 connections between Autonomous System Border Routers (ASBRs). Model 122 "B" uses eBGP redistribution of labelled L2 VPN routes from 123 Autonomous Systems (AS) to neighbouring AS. Model "C" uses multi-hop 124 MP-eBGP redistribution of labelled L2 VPN routes and eBGP 125 redistribution of L2 VPN routes from an AS to a neighbouring AS. 126 Model "C" is more scalable for maintaining routing states and hence 127 preferred for deployment in the Internet; refer to [2] for more 128 details. Security issues in MPLS, especially MPLS-based VPNs has 129 attracted attention [1]. The security of model "A" matches the 130 single-AS standard proposed in [9]. Model "B" can be secured well on 131 the control-plane, but on the data-plane the validity of the outer- 132 most label (Label Distribution or Resource Reservation Protocol 133 label) is not checked. This weakness could be exploited to inject 134 crafted packets from inside an MPLS network core. A solution for this 135 problem is proposed in [2]. Model "C" can be secured on the control- 136 plane but has a security weakness on the data-plane. The Autonomous 137 System Border Routers (ASBRs) do not have any VPN information and 138 hence the inner-most label cannot be validated. In this case, the 139 solution used for Model "B" cannot be applied. An attacker can 140 exploit this weakness to send unidirectional packets into the VPN 141 sites connected to the other AS. Therefore, ISPs using model "C" must 142 either trust each other or not deploy it [4]. 144 Control plane security issue in model "C" can be resolved by using 145 IPSec. If IPSec is used in the data-plane then configuring and 146 maintaining key associations could be extremely cumbersome. Even 147 though model "C" is highly scalable for carrying VPN Routing and 148 Forwarding (VRF) L2 VPN routes, the vulnerability of the data-plane 149 renders it unusable. The current recommendation is that model "C" 150 must not be used. In model "C", there are at least two labels for 151 each packet: the Provider Edge (PE) label, which defines the Label 152 Switched Path (LSP) to the egress PE, and the VPN label, which 153 defines the VPN associated with the packet on the PE. 155 In [5], the authors propose encryption techniques, such as IPSec, for 156 securing the provider edge (PE) of the network. The authors also 157 highlight that the processing capacity could be over-burdened. 158 Further, if an attacker is located at the core of the network, or in 159 the network between the providers that constitute an inter-provider 160 MPLS VPN, then spoofing attacks are possible. The vulnerability of 161 MPLS against spoofing attacks and performance impact of IPSec has 162 been discussed in [3]. If the inner labels that identify packets 163 going towards a L2 VPN site are spoofed, then sensitive information 164 related to services available within the organizational servers can 165 be compromised. As far as we know, there is no scheme available for 166 installing an antispoofing mechanism for these L2 VPN service labels. 168 This paper outlines a label-hopping technique that helps to alleviate 169 the data-plane security problem in model "C". We propose a scheme 170 that changes the inner L2 VPN labels dynamically based on the time 171 instant the packet is sent from the remote-end PE router. By using a 172 mix of algorithms and randomized labels, we can guard against 173 spoofing and related attacks. The advantage of our scheme is that it 174 can be used wherever Multiprotocol-external BGP (MP-eBGP) multi-hop 175 scenarios arise. 177 1.1 Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [RFC2119]. 183 2. Methodology of the proposal 185 2.1 PRE-REQUISITES FOR THE LABEL-HOPPING SCHEME 187 In this section, we briefly review the network topology for model 188 "C", the PE configuration and the control-plane exchanges needed for 189 our proposed scheme. 191 2.1.1 MPLS L2 VPN model "C" 193 The reference MPLS-eBGP based L2 VPN network for model "C" as 194 described in [11] is shown in Figure 1, which also shows the control 195 plane exchanges. The near-end PE (PEne) and far-end PE (PEfa) are 196 connected through the inter-provider MPLS core. The VPN connectivity 197 is established through a set of routers from different Autonomous 198 Systems (AS) and their ASBRs. In the L2 VPN, MP-eBGP updates are 199 exchanged for a set of MAC based Forward Equivalence Classes (FECs). 200 These FECs, which have to be protected, originate from the MAC 201 addresses / FECs behind PEne in a L2 VPN site or a set of L2 VPN 202 sites. 204 2.1.2 PE configuration 206 Various configurations are needed on the PEs to implement the label 207 hopping scheme. A set of "m" algorithms that generate collision-free 208 labels (universal hashing algorithms) are initially implemented in 209 the PEs. Each algorithm is mapped to an index A = (a1; a2; . . . am) 210 where m >= 1. The bit-selection pattern used by the PEs for 211 generating the additional label is also configured. PEne must be 212 configured for a FEC or a set of FECs represented by an aggregate 213 label (per VRF label) which will use the label-hopping scheme. For 214 each FEC or a set of FECs, a set of valid labels used for hopping, K 215 = (k1; k2; k3; . . . kn) where n >= 1 and, ki != kj if i != j, is 216 configured in PEne. For the set of labels K time slices TS = (TS1; 217 TS2; TS3 . . . TSn) are also exchanged. These time slices can be 218 periodically changed and a new set of TS ranging from TS1 to TSn can 219 be exchanged after a time duration TS_Exchange_Interval which itself 220 can be randomized from time to time.In the case of bi-directional 221 security, the roles of the PEs can be reversed. In addition to these 222 data sets a random seed is also exchanged. This Random Seed which we 223 will henceforth as Rseed is used to generate the label for the next 224 time slot. 226 2.1.3 Control and data-plane flow 228 Initially, set K, set TS and the bit-selection pattern used by the 229 PEs are exchanged securely over the control-plane. Optionally an 230 index from A, representing a hash-algorithm, could also be exchanged. 231 We propose that only the index is exchanged between the PEs, as it 232 enhances the security, for two reasons. First, the algorithm itself 233 is masked from the attacker. Second, the algorithm can be changed 234 frequently, and it would be difficult for the attacker to identify 235 the final mapping that generates the label to be used for a packet. 236 Figure 1 depicts this unidirectional exchange from PEne to PEfa. 238 The control plane exchanges also involve a-priori constructing a 239 Precision Time Protocol (PTP) LSP for deriving the clock at the PEne 240 and PEfa for a forwarding direction. For the reverse direction 241 another PTP LSP can be constructed as well. In the example that we 242 illustrate we discuss about only a single forwarding direction. The 243 PTP LSP port assigned for a forwarding direction is tied in with the 244 configuration that goes into the inter-PEne-PEfa exchanges to setup 245 the labelling control plane. So each pair of PEne and PEfa knows 246 which PTP port and corresponding PTP LSP as per [12] to be used for 247 the traffic. The PTP LSP is intended for providing the clocking 248 between a pair of PEne and PEfa. The clock / timestamp derived from 249 this PTP LSP is used in the data plane operation to determine which 250 label is valid at that time instant as will be seen in the Algorithms 251 provided below. 253 Once the secure control-plane exchanges are completed, we apply the 254 label-hopping technique, and PEfa forwards the labelled traffic 255 towards PEne through the intermediate routers using the label- 256 stacking technique (Figure 2). The stacked labels along with the 257 payload are transferred between the AS and ASBRs before they reach 258 PEne. Using the label-hopping algorithm PEne verifies the integrity 259 of labels. Upon validation, PEne uses the label information to 260 forward the packets to the appropriate L2 VPN service instance or 261 site. This data-plane exchange from PEfa and PEne is depicted in 262 Figure 3. We now present the label-hopping scheme. 264 2.2 LABEL-HOPPING TECHNIQUE 266 In this section, we describe the label-hopping technique and discuss 267 some implementation aspects. Once a data packet destined to the PEne 268 arrives at the PEfa (a) a first-label is chosen using set K and set 269 TS, and the random seed Rseed, and a first-label selected. Next (b) 270 a selected number of bytes from the payload is chosen as input to the 271 hashing algorithm. The hash-digest obtained as a result is used to 272 obtain the additional label for the packet. The agreed bit-selection 273 pattern is then applied on the hash-digest to obtain an additional 274 label, which is then concatenated with the first label. Once PEne 275 receives these packets it verifies both the labels. 277 The implementation steps for the control-plane at the PEne and PEfa 278 are given by Algorithms 1 and 2. The implementation steps for the 279 data-plane at the PEfa and PEne are given by Algorithms 3 and 4. 281 2.2.1 Algorithm 1 Control-plane PEne algorithm 283 Require: 285 * FEC[] Forward Equivalence Classes, 286 * K[] valid labels, 287 * TS[] valid time slices, 288 * A[i] hash algorithm instance, 289 * I[] the bit-selection pattern chosen for the inner label. 290 * Random seed "Rseed" which is used for generating the index into set 291 K (set of labels). 292 * PTP port and PTP LSP information 294 Begin 295 packet = makepacket(FEC,K, TS, A[i], I, Rseed); 296 CP-SendPacket(PEfa, MP-eBGP, packet); 297 End 299 Note: The values in K need not be contiguous and can be randomly 300 chosen from a pool of labels to remove coherence in the label space. 301 Also the algorithms used could be either vendor dependent or a set of 302 standard algorithms mapped the same way by the PEne and PEfa. If the 303 two PEs involved are from different vendors we assume that a set of 304 standard algorithms are used. 306 Note: Also the values in set TS should be of a coarse granularity of 307 seconds recommended to be higher than 2 seconds. 309 _______[AB1]________________ ___________[AB2]___________ 310 ( / | ) ( / ) 311 ( / +-----------+ ) ( / ) 312 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 313 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 314 ( | | ) ( | | ) 315 ( | | ) ( | | ) 316 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 317 | ^ ^ | 318 | +-------------- MP-eBGP L2-VPN session --------------+ | 319 | | 320 172.18.10.0/24 172.18.20.0/24 321 NH: PE_ne 322 <(FEC[] Forward Equivalence Classes), (K[] valid labels), 323 (TS[] valid time slices), (A[i] hash algorithm instance), 324 (I[] the bit-selection pattern chosen for the inner label), 325 (Rseed - A random seed to generate the next label to be used in set 326 K), 327 (PTP port and PTP LSP information)>. 329 Exchange all details as per Algorithm 1. 331 Figure 1: Control-plane exchanges for model C [11] 333 <------- Label Stack ------> 334 +----------+---------+---------+---------+--------+---------+ 335 | Frame L2 | Label 1 | Label 2 | Label 3 | L2/+L3 | Payload | 336 | Header | | | | Header | | 337 +----------+---------+---------+---------+--------+---------+ 338 S = 0 S = 0 S = 1 339 Figure 2: Label stack using scheme outlined for Model "C" 341 _______[AB1]________________ ___________[AB2]___________ 342 ( / | ) ( / ) 343 ( / +-----------+ ) ( / ) 344 (IL1:SL:L2 FRAME L1:IL1:SL:L2 FRAME / ) 345 ( | L3:IL1:SL:L2 FRAME <-+ L4:IL1:SL:L2 FRAME ) 346 ( | | ) ( | | ) 347 ( | | ) ( | | ) 348 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 349 | | 350 L2 VPN Site (1) L2:IL1:SL:172.18.10.1 L2 VPN Site (2) 352 Figure 3: Data-plane flow for model C [11] 354 2.2.2 Algorithm 2 Control-plane PEfa algorithm 356 Require: None 357 Begin 358 packet = CP-ReceivePacket(PEne); // from PEne 359 FEC[] = ExtractFEC(packet); // extract FECs 360 K[] = ExtractLabels(packet); // extract the labels 361 TS[] = ExtractTimeSlices(packet); // extract the time slices 362 Rseed = ExtractRandomSeed(packet); // extract the Rseed value. 363 selectHashAlgorithm(A[i]); // hash algorithm to use 364 RecordValues(FEC); // information for PEfa 365 RecordValues(K); 366 RecordValues(TS); 367 RecordValues(I); // bit-selection pattern to be used 368 RecordValue(Rseed); 369 End 371 2.2.3 Algorithm 3 Data-plane PEfa algorithm 373 Require: None 375 Begin 376 Initialization : 378 One Time Init : 380 BeginInit 382 CurrentTimeSliceIndex = 0; 384 CurrentMasterClock = PTP LSP Master Clock Timestamp; 386 CurrentTimeInstant = CurrentMasterClock; 388 NextTimeInstant = CurrentMasterClock + TS[CurrentTimeSliceIndex]; 390 EndInit 392 packet = DP-ReceivePacket(Interface); 393 match = CheckFEC(packet); // Is the algorithm enabled? 394 if match == 0 then 395 return; // no match 396 end if 397 hash-digest = calculateHash(A[i],packet); 398 if (CurrentTimeInstant <= NextTimeInstant ((+ or -) configured 399 seconds)) then 400 // do nothing; 401 else 402 CurrentTimeSliceIndex++; 403 if CurrentTimeSliceIndex == n then // check to wrap around 404 CurrentTimeSliceIndex = 0; 405 end if 406 CurrentTimeInstant = NextTimeInstant; 407 NextTimeInstant = CurrentTimeInstant + TS[CurrentTimeSliceIndex]; 408 end if 409 first-label = K[GenerateRandom(Rseed) MOD n(K)]; 410 end if 411 additional-label = process(hash-digest,I) 412 DP-SendPacket(PEne, first-label, additional-label, packet); 413 End 415 2.2.4 Algorithm 4 Data-plane PEne algorithm 417 Require: None 418 Initialization : 419 One Time Init : 421 BeginInit 422 CurrentTimeSliceIndex = 0; 423 CurrentMasterClock = PTP LSP Clock Timestamp; 424 CurrentTimeInstant = CurrentMasterClock; 425 NextTimeInstant = CurrentMasterClock + TS[CurrentTimeSliceIndex]; 426 EndInit 428 Begin 429 packet = DP-ReceivePacket(Interface); 430 match = CheckFEC(packet); 431 if match == 0 then 432 return; //no match 433 end if 435 label-in-packet=extractPacket(packet, LABEL); 436 inner-label=extractPacket(packet, INNER-LABEL); 437 hash-digest=calculateHash(A[i],packet); 438 if (CurrentTimeInstant <= NextTimeInstant ((+ or -) configured 439 seconds)) then 440 // do nothing; 441 else 442 CurrentTimeSliceIndex++; 443 // Save the old RseedIndex into set K 444 OldRseedIndex = RseedIndex; 445 RseedIndex = (GenerateRandom(Rseed) MOD n(K)); 446 NextRseedIndex = 447 LookAheadRseedIndex(GenerateRandom(Rseed) MOD n(K)); 448 RollbackRseed(Rseed by 1); 449 if CurrentTimeSliceIndex == n then // check to wrap around 450 CurrentTimeSliceIndex = 0; 451 end if 452 CurrentTimeInstant = NextTimeInstant; 453 NextTimeInstant = CurrentTimeInstant + TS[CurrentTimeSliceIndex]; 454 end if 455 // Check if label used before in the previous | current or future 456 // time slot can be used 457 // Check with OldRseedIndex, RseedIndex and NextRseedIndex 458 first-label-range = K[RseedIndex (+or- 1)]; 459 additional-label = process(hash-digest,I) 460 if label-in-packet ! in first-label-range then 461 error(); return; 462 end if 463 if inner-label != additional-label then 464 error(); return; 465 end if 466 DP-SendPacket(CE1, NULL, NULL, packet); 467 End 469 Here configured seconds could be a fraction as well. 471 In order to avoid too many processing cycles in the line cards of 472 PEne and PEfa, the hash- digest is calculated over a predefined size 473 of the payload. An additional inner label is further added to enhance 474 protection against spoofing attacks. With an increased label size, an 475 attacker spends more than polynomial time to guess the VPN instance 476 label for the site behind PEne. There could be two hash-digests that 477 generate the same label. In this case, the two hash-digests is 478 differentiated using the additional label. Collisions can be avoided 479 by re-hashing or any other suitable techniques that are proposed in 480 the literature [8]. If collisions exceed a certain number, then 481 Algorithms 1 and 2 can be executed with a set of new labels. 483 Note : 485 It is to be noted that the change in the algorithm to randomly pick 486 up a label for the next time slot will help in avoiding man-in-the- 487 middle attackers from synchronizing with the time slots and the 488 labels which in the previous version of the algorithm was predictable 489 if a large number of packets were observed. The Random seed agreed 490 upon will generate in lock step with the time slots at both the PEfa 491 and PEna, the correct label to be used and that will throw off the 492 attacker from synchronizing with such label changes. Thus even replay 493 attacks may be harder to attempt in such a case. 495 2.2.1 Illustration 497 We now briefly illustrate the label-hopping scheme. In Figure 1, 498 using Algorithms 1 and 2, a set of labels are forwarded from PEne to 499 PEfa. The roles of PEne and PEfa are interchanged for reverse 500 traffic. Figure 2 shows a packet from the data-plane for model "C", 501 with the proposed scheme. In the figure, "Label 1" refers to the 502 outermost label, while "Label 2" refers to the label generated from 503 the set K and set TS and "Label 3" refers to an additional label 504 generated as in Algorithm 3. This additional label has bottom of 505 stack bit (denoted by S in Figure 2) set. These labels are stacked 506 immediately onto the packet and the path labels for routing the 507 packets to appropriate intermediary PEs are added. Figure 3 also 508 shows these path labels used by the data packet to reach PEne. When 509 the packet passes through the core of an intermediary AS involved in 510 model "C", or through the network connecting the intermediary AS, the 511 intruder or the attacker has the capability to inspect the labels and 512 the payload. However, the proposed scheme prevents the attacker from 513 guessing the right combination of the labels. We can increase the 514 size of the additional inner-labels thereby reducing threats from 515 polynomial time attacks. 517 2.3 SIMULATION AND IMPLEMENTATION 519 In this section, we present the preliminary simulation results on 520 performance, comparing the label-hopping technique with deep packet 521 inspection where we encrypt and decrypt the complete packet. We also 522 briefly highlight some implementation issues. 524 2.3.1 Simulation 526 Implementing the label-hopping scheme for all set of FECs belonging 527 to any or all VPN service instances may cause throughput degradation. 528 This is because the hashdigest computation and derivation of the 529 inner-label / additional inner label calculation can be computation 530 intensive. We therefore compared our technique by choosing a part of 531 the payload as input to our hashing algorithm. We simulated our 532 algorithm on a 2.5 GHz processor Intel dual processor quad core 533 machine. We compared the performance of the label-hopping technique 534 with a deep packet inspection technique where the complete packet was 535 encrypted before transmission and decrypted on reception. These 536 simulation figures indicate that we were able to process 10 million 537 packets per second when we used 64-byte for hashing on a payload of 538 size 1024 bytes. For a hash using 128-byte, we were able to process 539 about 6.3 million packets per second. However with a deep packet 540 inspection where we encrypted and decrypted the complete packet, we 541 were able to process only about 1 million packets per second. In 542 cases where performance becomes a bottleneck, this label-hopping 543 scheme can be applied to specific traffic which are mission-critical, 544 sensitive and most likely need to be protected as they travel from 545 the PEfa to the PEne. Selective application of this service which 546 could be offered as a premium for a selected set of FECs is a 547 suitable option, there by protecting the traffic of organizations 548 that are paranoid about the integrity of the switched traffic into 549 their VPN sites. 551 2.3.2 Implementation 553 One of the concerns in the scheme is the use of payload for 554 generating the random inner label / additonal label. If the payload 555 does not vary between two packets then the control-plane exchanges 556 have to be renegotiated with a different algorithm to be used for the 557 hashing for the subsequent packets. The other concern in the scheme 558 is to tackle the problem of fragmentation that can occur along the 559 path from PEfa to PEne. We can fragment the packet at PEfa and ensure 560 that the size of the packet is fixed before transmission. We could 561 also employ the Path Maximum Transfer Unit (Path-MTU) discovery 562 process so that packets do not get split into multiple fragments. If 563 packets are fragmented this scheme fails. However, networks usually 564 employ the Path-MTU discovery process to prevent fragmentation and 565 hence this problem may not occur. 567 2.3.3 Running the PTP LSP and label hopping at the ASBRs 569 The ASes participating in the inter-AS L2VPN Option-C type service 570 connect with each other using ASBRs that connect one AS to another. 572 It would be prudent to run the PTP LSP and the label-hopping 573 algorithm between the ASBRs instead of between the PEs. Since these 574 ASBRs are usually one-hop away from each other or in the worst case a 575 couple of hops away, the granularity of the time slices can be a lot 576 more finer than when running between the PEs. At more granular time 577 slices it will be even harder for an attacker to pump in packets that 578 utilize the slack of + or - microseconds or milliseconds configured 579 in Algorithm 4. 581 Hence spoofing and replay attacks are less likely to succeed. 583 To make it clear the innermost label which is the hash digest 584 computed on the first 128 or 64 byte portion of the payload which is 585 binary anded with an arbitrary bit pattern known to both PEs in the 586 topology , serves as an added binary pattern which has to be guessed 587 by the intruder intending to spoof the packet into the VPN's PE onto 588 the CE. 590 Thus the effective label space that has to be guessed by the intruder 591 is the label for that time slice and the binary pattern computed on 592 the payload (result of the hash-digest ANDed with the arbitrary bit 593 pattern). 595 This makes it essentially a 40 bit label space. The hash-digest was 596 not intended to be a ICV. It could serve as an ICV as well. 598 Since the binary pattern exchanged through the control plane is not 599 known to the intruder, and the hash algorithm used is not known to 600 the intruder (unless of course both of them are compromised in the 601 control plane exchange which is of course secure) the resulting 602 innermost label extends the label space to 40 bits (including the 603 label for that time slice) that has to be guessed. 605 As to whether there might be a flood of replay packets with the + or 606 - 1 time slice being in place, the previous label used would be known 607 but the one after the current time slice would be hard to guess owing 608 to the random number generation function being used to determine 609 which the next label should be. It should be possible to jam for that 610 time slice with the same packet with the 2 labels (previous and 611 current) for that time slice being repeated again and again. This is 612 solved by finely granularizing the time slices to microseconds or 613 milliseconds. This is especially the case if the scheme is run 614 between the ASBRs and not between the PEs. 616 2.4 CONCLUSION AND FUTURE WORK 618 In this paper, we proposed a label-hopping scheme for inter-provider 619 BGP-based MPLS L2 VPNs that employ MPe-BGP multi-hop control-plane 620 exchanges. In such an environment, without label-hopping, the data- 621 plane is subject to spoofing attacks. 623 The technique proposed uses a time-based label hopping scheme in 624 addition to the use of the payload to generate an inner label to 625 prevent attackers from easily deciphering labels and their respective 626 VPNs. The scheme is less computationally intensive than encryption- 627 based methods. It prevents the spoofed packets from getting into a 628 VPN site even if the attacker is in the core or at an intervening 629 link between ISPs. In our scheme, we chose the time instant that the 630 packet leaves the first Provider Edge on the far end and this time 631 instant serves as the variable component that the attacker cannot 632 decipher. This requires the use of time synchronization mechanism. 633 This is provided by the PTP LSP constructed for this purpose. 635 2.5 ACKNOWLEDGEMENTS 637 The authors would like to acknowledge the UK EP-SRC Digital Economy 638 Programme and the Government of India Department of Science and 639 Technology (DST) for funding given to the IU-ATC. The authors would 640 also like to thank Chandrasekhar.R and Narayana Swamy for his review 641 and valuable comments during the writing of this draft. 643 3 Security Considerations 645 The main objective of this proposal is to secure the Inter-Provider 646 MPLS L2 VPN Model-C data plane by preventing spoofing attacks and 647 other unidirectional attacks against the customer site in this model. 648 The suggestions and algorithms provided will mitigate these attacks 649 to a large extent. The attacker will have many barriers to break 650 through before he/she can successfully mount an attack against the 651 customer site in this model with these algorithms implemented. The 652 availability of TicToc as a method of clocking helps a great deal in 653 this direction. 655 4 IANA Considerations 657 Appropriate IANA indicators would have to be provided to exchange the 658 set of values that Algorithm 1 outlines in order to implement this 659 scheme. 661 5 References 663 5.1 Normative References 665 5.2 Informative References 667 [1] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS 668 security: an approach for unicast and multicast 669 environments", Annals of Telecommunications, Springer, 670 vol. 64, no. 5, June 2009, pp. 391-400, 671 doi:10.1007/s12243-009-0089-y. 673 [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security", 674 Cisco Press, June 2005, ISBN-10: 1587051834. 676 [3] B. Daugherty and C. Metz, "Multiprotocol Label 677 Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE 678 Internet Computing, May-June 2005, pp. 68-72, doi: 679 10.1109/MIC.2005.61. 681 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 682 "Interprovider IP-MPLS services: requirements, 683 implementations, and challenges", IEEE Communications 684 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 685 10.1109/MCOM.2005.1452840. 687 [5] C. Lin and W. Guowei, "Security research of VPN 688 technology based on MPLS", Proceedings of the Third 689 International Symposium on Computer Science and 690 Computational Technology (ISCSCT 10), August 2010, pp. 691 168-170, ISBN- 13:9789525726107. 693 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 694 Farinacci and D. Katz, "Tag switching architecture 695 overview", Proceedings of the IEEE, vol. 85, no. 12, 696 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 698 [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 699 Networks (VPNs)", RFC 4364, Standard Track, February, 700 2006. 702 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 703 Stein, "Introduction to algorithms", 3rd edition, MIT 704 Press, September 2009, ISBN-10:0262033844. 706 [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals", 707 Juniper Networks white paper, March 2001. 709 [10] Advance MPLS VPN Security Tutorials [Online], 710 Available: 711 "http://etutorials.org/Networking/MPLS+VPN+security/ 712 Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed: 713 10th December 2011] 715 [11] Inter-provider MPLS VPN models [Online], Available: 716 "http://mpls-configuration-on-cisco-iossoftware. 717 org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th 718 December 2011] 720 [12] Davari.S et.al, Transporting PTP messages (1588) over 721 MPLS networks, "http://datatracker.ietf.org/doc/draft- 722 ietf-tictoc-1588overmpls/?include_text=1", Work in 723 Progress, October 2011. 725 Authors' Addresses 727 Shankar Raman 728 Department of Computer Science and Engineering 729 IIT Madras 730 Chennai - 600036 731 TamilNadu 732 India 733 EMail: mjsraman@cse.iitm.ac.in 735 Balaji Venkat Venkataswami 736 Department of Electrical Engineering 737 IIT Madras 738 Chennai - 600036 739 TamilNadu 740 India 742 EMail: balajivenkat299@gmail.com 744 Prof.Gaurav Raina 745 Department of Electrical Engineering 746 IIT Madras 747 Chennai - 600036 748 TamilNadu 749 India 751 EMail: gaurav@ee.iitm.ac.in 753 Bhargav Bhikkaji 754 Dell-Force10 755 350 Holger Way 756 San Jose, CA 757 USA 759 Email: Bhargav_Bhikkaji@dell.com