idnits 2.17.1 draft-mjsraman-l3vpn-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 2 instances 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 4035 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2119' on line 183 -- Looks like a reference, but probably isn't: 'CurrentTimeSliceIndex' on line 453 == Unused Reference: '7' is defined on line 697, 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 (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN 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 April 8, 2013 8 Securing Model-C Inter-Provider VPNs with Label Hopping and TicToc 9 draft-mjsraman-l3vpn-tictoc-label-hop-03 11 Abstract 13 In certain models of inter-provider Multi- Protocol Label Switching 14 (MPLS) based Virtual Private Networks (VPNs) spoofing attack against 15 VPN sites is a key concern. For example, MPLS-based VPN inter- 16 provider model "C" is not favoured, owing to security concerns in the 17 dataplane, even though it can scale with respect to maintenance of 18 routing state. Since the inner labels associated with VPN sites are 19 not encrypted during transmission, a man-in-themiddle attacker can 20 spoof packets to a specific VPN site. In this paper, we propose a 21 label-hopping technique which uses a set of randomized labels and a 22 method for hopping amongst these labels using the time instant the 23 packet leaves the port from a sending Provider Edge Router. To 24 prevent the attacker from identifying the labels in polynomial time, 25 we also use an additional label. The proposed technique can be 26 applied to other variants of inter-provider MPLS based VPNs where 27 Multi-Protocol exterior-BGP (MP-eBGP) multi-hop is used. As we 28 address a key security concern, we can make a case for the deployment 29 of MPLS based VPN inter-provider model "C". Specifically we use the 30 TicToc based Precision Time Protocol LSP to provide the timing for 31 determining the time instant at which the packet is sent from the 32 remote end Provider Edge Router and hence calculating when it must 33 have left that peer at the Provider Edge Router in the near / 34 receiving end. 36 This version of the document suggests a better method for gaining 37 more finely granular time slices. This is done by running the PTP LSP 38 between the ASBRs in the ASes that are providing the inter-AS L3VPN 39 service. 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-HOPPING SCHEME . . . . . . . . 5 83 2.1.1 MPLS VPN model "C" . . . . . . . . . . . . . . . . . . . 5 84 2.1.2 PE configuration . . . . . . . . . . . . . . . . . . . . 6 85 2.1.3 Control and data-plane flow . . . . . . . . . . . . . . 6 86 2.2 LABEL-HOPPING TECHNIQUE . . . . . . . . . . . . . . . . . . 7 87 2.2.1 Algorithm 1 Control-plane PEne algorithm . . . . . . . . 8 88 2.2.2 Algorithm 2 Control-plane PEfa algorithm . . . . . . . . 10 89 2.2.3 Algorithm 3 Data-plane PEfa algorithm . . . . . . . . . 11 90 2.2.4 Algorithm 4 Data-plane PEne algorithm . . . . . . . . . 12 91 2.2.1 Illustration . . . . . . . . . . . . . . . . . . . . . . 13 92 2.3 SIMULATION AND IMPLEMENTATION . . . . . . . . . . . . . . . 14 93 2.3.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . 14 94 2.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . 14 95 2.3.3 Running the PTP LSP and label hopping at the ASBRs . . . 15 96 2.4 CONCLUSION AND FUTURE WORK . . . . . . . . . . . . . . . . . 16 97 2.5 ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . 16 98 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 99 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 100 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 5.1 Normative References . . . . . . . . . . . . . . . . . . . 17 102 5.2 Informative References . . . . . . . . . . . . . . . . . . 17 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 105 1 Introduction 107 Multi-Protocol Label Switching (MPLS) [6] technology uses fixed size 108 labels to forward data packets between routers. By stacking labels, 109 specific customer services such as Layer 3 Virtual Private Networks 110 (L3-VPNs) based on Border Gateway Protocol (BGP) extensions are 111 widely deployed in the Internet. BGP-based MPLS L3-VPN services are 112 provided either on a single Internet Service Provider (ISP) core or 113 across multiple ISP cores. The latter cases are known as inter- 114 provider MPLS VPNs which are broadly categorized and referred to as 115 models: "A", "B" and "C" [10]. 117 Model "A" uses back-to-back VPN Routing and Forwarding (VRF) 118 connections between Autonomous System Border Routers (ASBRs). Model 119 "B" uses eBGP redistribution of labelled VPN-IPv4 routes from 120 Autonomous Systems (AS) to neighbouring AS. Model "C" uses multi-hop 121 MP-eBGP redistribution of labelled VPN-IPv4 routes and eBGP 122 redistribution of IPv4 routes from an AS to a neighbouring AS. Model 123 "C" is more scalable for maintaining routing states and hence 124 preferred for deployment in the Internet; refer to [2] for more 125 details. Security issues in MPLS, especially MPLS-based VPNs has 126 attracted attention [1]. The security of model "A" matches the 127 single-AS standard proposed in [9]. Model "B" can be secured well on 128 the control-plane, but on the data-plane the validity of the outer- 129 most label (Label Distribution or Resource Reservation Protocol 130 label) is not checked. This weakness could be exploited to inject 131 crafted packets from inside an MPLS network core. A solution for this 132 problem is proposed in [2]. Model "C" can be secured on the control- 133 plane but has a security weakness on the data-plane. The Autonomous 134 System Border Routers (ASBRs) do not have any VPN information and 135 hence the inner-most label cannot be validated. In this case, the 136 solution used for Model "B" cannot be applied. An attacker can 137 exploit this weakness to send unidirectional packets into the VPN 138 sites connected to the other AS. Therefore, ISPs using model "C" must 139 either trust each other or not deploy it [4]. 141 Control plane security issue in model "C" can be resolved by using 142 IPSec. If IPSec is used in the data-plane then configuring and 143 maintaining key associations could be extremely cumbersome. Even 144 though model "C" is highly scalable for carrying VPN Routing and 145 Forwarding (VRF) routes, the vulnerability of the data-plane renders 146 it unusable. The current recommendation is that model "C" must not be 147 used. A simple solution to this problem is to filter all IP traffic 148 with the exception of the required eBGP peering between the ASBRs, 149 thereby preventing a large number of potential IP traffic-related 150 attacks. However, controlling labelled packets is difficult. In model 151 "C", there are at least two labels for each packet: the Provider Edge 152 (PE) label, which defines the Label Switched Path (LSP) to the egress 153 PE, and the VPN label, which defines the VPN associated with the 154 packet on the PE. 156 In [5], the authors propose encryption techniques, such as IPSec, for 157 securing the provider edge (PE) of the network. The authors also 158 highlight that the processing capacity could be over-burdened. 159 Further, if an attacker is located at the core of the network, or in 160 the network between the providers that constitute an inter-provider 161 MPLS VPN, then spoofing attacks are possible. The vulnerability of 162 MPLS against spoofing attacks and performance impact of IPSec has 163 been discussed in [3]. If the inner labels that identify packets 164 going towards a L3 VPN site are spoofed, then sensitive information 165 related to services available within the organizational servers can 166 be compromised. As far as we know, there is no scheme available for 167 installing an antispoofing mechanism for these VPN service labels. 169 This paper outlines a label-hopping technique that helps to alleviate 170 the data-plane security problem in model "C". We propose a scheme 171 that changes the inner VPN labels dynamically based on the time 172 instant the packet is sent from the remote-end PE router. By using a 173 mix of algorithms and randomized labels, we can guard against 174 spoofing and related attacks. The advantage of our scheme is that it 175 can be used wherever Multiprotocol-external BGP (MP-eBGP) multi-hop 176 scenarios arise. 178 1.1 Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in RFC 2119 [RFC2119]. 184 2. Methodology of the proposal 186 2.1 PRE-REQUISITES FOR THE LABEL-HOPPING SCHEME 188 In this section, we briefly review the network topology for model 189 "C", the PE configuration and the control-plane exchanges needed for 190 our proposed scheme. 192 2.1.1 MPLS VPN model "C" 194 The reference MPLS-eBGP based VPN network for model "C" as described 195 in [11] is shown in Figure 1, which also shows the control plane 196 exchanges. The near-end PE (PEne) and far-end PE (PEfa) are connected 197 through the inter-provider MPLS core. The VPN connectivity is 198 established through a set of routers from different Autonomous 199 Systems (AS) and their ASBRs. In the VPN, MP-eBGP updates are 200 exchanged for a set of Forward Equivalence Classes (FECs). These 201 FECs, which have to be protected, originate from the prefixes behind 202 PEne in a VPN site or a set of VPN 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 VPN service instance or site. 261 This data-plane exchange from PEfa and PEne is depicted in Figure 3. 262 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 * Random seed "Rseed" which is used for generating the index into set 289 K (set of labels). 290 * A[i] hash algorithm instance, 291 * I[] the bit-selection pattern chosen for the inner label. 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 IP-VPNV4 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 | 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:172.18.10.1 L1:IL1:SL:172.18.10.1 / ) 345 ( | L3:IL1:SL:172.18.10.1 <-+ L4:IL1:SL:172.18.10.1) 346 ( | | ) ( | | ) 347 ( | | ) ( | | ) 348 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 349 | | 350 172.18.10.0/24 L2:IL1:SL:172.18.10.1 172.18.20.0/24 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 We are modifying the open source Quagga router software on Linux to 554 implement our scheme. One of the concerns in the scheme is the use of 555 payload for generating the random inner label / additonal label. If 556 the payload does not vary between two packets then the control-plane 557 exchanges have to be renegotiated with a different algorithm to be 558 used for the hashing for the subsequent packets. The other concern in 559 the scheme is to tackle the problem of fragmentation that can occur 560 along the path from PEfa to PEne. We can fragment the packet at PEfa 561 and ensure that the size of the packet is fixed before transmission. 562 We could also employ the Path Maximum Transfer Unit (Path-MTU) 563 discovery process so that packets do not get split into multiple 564 fragments. If packets are fragmented this scheme fails. However, 565 networks usually employ the Path-MTU discovery process to prevent 566 fragmentation and hence this problem may not occur. 568 2.3.3 Running the PTP LSP and label hopping at the ASBRs 570 The ASes participating in the inter-AS L3VPN Option-C type service 571 connect with each other using ASBRs that connect one AS to another. 573 It would be prudent to run the PTP LSP and the label-hopping 574 algorithm between the ASBRs instead of between the PEs. Since these 575 ASBRs are usually one-hop away from each other or in the worst case a 576 couple of hops away, the granularity of the time slices can be a lot 577 more finer than when running between the PEs. At more granular time 578 slices it will be even harder for an attacker to pump in packets that 579 utilize the slack of + or - microseconds or milliseconds configured 580 in Algorithm 4. 582 Hence spoofing and replay attacks are less likely to succeed. 584 To make it clear the innermost label which is the hash digest 585 computed on the first 128 or 64 byte portion of the payload which is 586 binary anded with an arbitrary bit pattern known to both PEs in the 587 topology , serves as an added binary pattern which has to be guessed 588 by the intruder intending to spoof the packet into the VPN's PE onto 589 the CE. 591 Thus the effective label space that has to be guessed by the intruder 592 is the label for that time slice and the binary pattern computed on 593 the payload (result of the hash-digest ANDed with the arbitrary bit 594 pattern). 596 This makes it essentially a 40 bit label space. The hash-digest was 597 not intended to be a ICV. It could serve as an ICV as well. 599 Since the binary pattern exchanged through the control plane is not 600 known to the intruder, and the hash algorithm used is not known to 601 the intruder (unless of course both of them are compromised in the 602 control plane exchange which is of course secure) the resulting 603 innermost label extends the label space to 40 bits (including the 604 label for that time slice) that has to be guessed. 606 As to whether there might be a flood of replay packets with the + or 607 - 1 time slice being in place, the previous label used would be known 608 but the one after the current time slice would be hard to guess owing 609 to the random number generation function being used to determine 610 which the next label should be. It should be possible to jam for that 611 time slice with the same packet with the 2 labels (previous and 612 current) for that time slice being repeated again and again. This is 613 solved by finely granularizing the time slices to microseconds or 614 milliseconds. This is especially the case if the scheme is run 615 between the ASBRs and not between the PEs. 617 2.4 CONCLUSION AND FUTURE WORK 619 In this paper, we proposed a label-hopping scheme for inter-provider 620 BGP-based MPLS VPNs that employ MPe-BGP multi-hop control-plane 621 exchanges. In such an environment, without label-hopping, the data- 622 plane is subject to spoofing attacks. 624 The technique proposed uses a time-based label hopping scheme in 625 addition to the use of the payload to generate an inner label to 626 prevent attackers from easily deciphering labels and their respective 627 VPNs. The scheme is less computationally intensive than encryption- 628 based methods. It prevents the spoofed packets from getting into a 629 VPN site even if the attacker is in the core or at an intervening 630 link between ISPs. In our scheme, we chose the time instant that the 631 packet leaves the first Provider Edge on the far end and this time 632 instant serves as the variable component that the attacker cannot 633 decipher. This requires the use of time synchronization mechanism. 634 This is provided by the PTP LSP constructed for this purpose. 636 2.5 ACKNOWLEDGEMENTS 638 The authors would like to acknowledge the UK EP-SRC Digital Economy 639 Programme and the Government of India Department of Science and 640 Technology (DST) for funding given to the IU-ATC. 642 3 Security Considerations 644 The main objective of this proposal is to secure the Inter-Provider 645 MPLS VPN Model-C data plane by preventing spoofing attacks and other 646 unidirectional attacks against the customer site in this model. The 647 suggestions and algorithms provided will mitigate these attacks to a 648 large extent. The attacker will have many barriers to break through 649 before he/she can successfully mount an attack against the customer 650 site in this model with these algorithms implemented. The 651 availability of TicToc as a method of clocking helps a great deal in 652 this direction. 654 4 IANA Considerations 656 Appropriate IANA indicators would have to be provided to exchange the 657 set of values that Algorithm 1 outlines in order to implement this 658 scheme. 660 5 References 662 5.1 Normative References 664 5.2 Informative References 666 [1] S. Alouneh, A. En-Nouaary and A. Agarwal, "MPLS 667 security: an approach for unicast and multicast 668 environments", Annals of Telecommunications, Springer, 669 vol. 64, no. 5, June 2009, pp. 391-400, 670 doi:10.1007/s12243-009-0089-y. 672 [2] M. H. Behringer and M. J. Morrow, "MPLS VPN security", 673 Cisco Press, June 2005, ISBN-10: 1587051834. 675 [3] B. Daugherty and C. Metz, "Multiprotocol Label 676 Switching and IP, Part 1, MPLS VPNS over IP Tunnels", IEEE 677 Internet Computing, May-June 2005, pp. 68-72, doi: 678 10.1109/MIC.2005.61. 680 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 681 "Interprovider IP-MPLS services: requirements, 682 implementations, and challenges", IEEE Communications 683 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 684 10.1109/MCOM.2005.1452840. 686 [5] C. Lin and W. Guowei, "Security research of VPN 687 technology based on MPLS", Proceedings of the Third 688 International Symposium on Computer Science and 689 Computational Technology (ISCSCT 10), August 2010, pp. 690 168-170, ISBN- 13:9789525726107. 692 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 693 Farinacci and D. Katz, "Tag switching architecture 694 overview", Proceedings of the IEEE, vol. 85, no. 12, 695 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 697 [7] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private 698 Networks (VPNs)", RFC 4364, Standard Track, February, 699 2006. 701 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 702 Stein, "Introduction to algorithms", 3rd edition, MIT 703 Press, September 2009, ISBN-10:0262033844. 705 [9] C. Semeria, "RFC 2547bis: BGP/MPLS VPN fundamentals", 706 Juniper Networks white paper, March 2001. 708 [10] Advance MPLS VPN Security Tutorials [Online], 709 Available: 710 "http://etutorials.org/Networking/MPLS+VPN+security/ 711 Part+II+Advanced+MPLS+VPN+Security+Issues/", [Accessed: 712 10th December 2011] 714 [11] Inter-provider MPLS VPN models [Online], Available: 715 "http://mpls-configuration-on-cisco-iossoftware. 716 org.ua/1587051990/ ch07lev1sec4.html", [Accessed 10th 717 December 2011] 719 [12] Davari.S et.al, Transporting PTP messages (1588) over 720 MPLS networks, "http://datatracker.ietf.org/doc/draft- 721 ietf-tictoc-1588overmpls/?include_text=1", Work in 722 Progress, October 2011. 724 Authors' Addresses 726 Shankar Raman 727 Department of Computer Science and Engineering 728 IIT Madras 729 Chennai - 600036 730 TamilNadu 731 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