idnits 2.17.1 draft-bhargav-l3vpn-inter-provider-optcsec-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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. == There are 5 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 (March 2, 2012) is 4431 days in the past. Is this intentional? Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 166, but not defined == Missing Reference: 'CE2' is mentioned on line 190, but not defined == Unused Reference: 'KEYWORDS' is defined on line 495, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 501, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 544, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 564, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. '9') (Obsoleted by RFC 4364) Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Bhargav Bhikkaji 3 Internet-draft Balaji Venkat Venkataswami 4 Intended Status:Experimental RFC Dell-Force10 5 Expires: August 2012 March 2, 2012 7 Preventing spoofing attacks in BGP-MPLS-VPN Inter-Provider Model-C 8 draft-bhargav-l3vpn-inter-provider-optcsec-03 10 Abstract 12 In certain models of inter-provider Multi-Protocol-Label-Switching 13 based Virtual Private Networks (MPLS-VPNs), spoofing attacks against 14 VPN sites is a key concern. Unidirectional attacks towards VPN sites 15 can compromise servers at the VPN sites and cause Denial-of-Service 16 (DoS) situations. Currently, the inner labels associated with VPN 17 sites are not encrypted during transmission. The Provider Edge (PE) 18 router at the end to which the VPN customer is attached accepts any 19 data packet with a valid label. This enables a man-in-the-middle 20 attacker to spoof a packet to a specific site of a VPN. In this 21 paper, we propose some secure techniques which provide security 22 against such label-spoofing. These techniques ensure that an attacker 23 would not be able to spoof labeled data packets. In order to make the 24 proposed scheme robust, some additional steps are proposed over and 25 above the initial steps specified. This makes the attacker to spend 26 non-linear time to guess the right label for his unidirectional 27 attacks to succeed. Our proposed technique can be applied to a 28 specific type of inter-provider Border Gateway Protocol(BGP) based 29 MPLS VPN and other existing variant where Multi-Protocol exterior- 30 BGP (MP-eBGP) multi-hop is used. In future, if any other variant is 31 proposed to use MP-eBGP multi-hop, our scheme can be used to protect 32 against spoofing attacks. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as 42 Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/1id-abstracts.html 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 Copyright and License Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1 Security issue in model C . . . . . . . . . . . . . . . . . 5 74 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Methodology of the Proposal . . . . . . . . . . . . . . . . . 6 76 2.1 Solution:1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 2.1.1 Control Plane operation . . . . . . . . . . . . . . . . 7 78 2.1.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 8 79 2.1.3 Mapping a hash to a 20 bit value . . . . . . . . . . . . 9 80 2.2 Solution:2 . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 2.2.1 Control Plane operation . . . . . . . . . . . . . . . . 9 82 2.2.2 Data-Plane Operation . . . . . . . . . . . . . . . . . . 10 83 2.3 Use Case:1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 2.4 Use Case:2 (RSVP can use this during tunnel setup) . . . . . 11 85 2.5 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 12 87 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 88 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 13 89 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 91 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 94 1 Introduction 96 MPLS technology helps forward data packets in the Internet using 97 fixed-size labels [3]. By stacking labels (label-stacking technique), 98 specific customer services such as layer 3 VPNs based on BGP 99 extensions are widely deployed in the Internet. BGP based MPLS layer 100 3 VPN services are provided either on a single internet service 101 provider (ISP) core or across multiple ISP cores. The latter cases 102 are known as inter-provider MPLS VPNs which are broadly categorized 103 and referred to as models: A, B and C. Model A uses back-to-back VPN 104 Routing and Forwarding (VRF) connections between Autonomous System 105 Border Routers (ASBRs). Model B uses eBGP redistribution of labelled 106 VPN-IPv4 routes from AS to neighbouring AS. Model C uses multi-hop 107 eBGP redistribution of labelled VPNIPv4 routes and eBGP 108 redistribution of IPv4 routes from AS to neighbouring AS. Please 109 refer [1] for more details. A. Security issues in inter-provider VPN 110 models Model A is as secure a standard as the single-Autonomous 111 System (AS) standard proposed in [5]. Model B can be secured well on 112 the control plane, but on the data-plane the top-most label is not 113 checked for validity. This weakness could be exploited to inject 114 crafted packets from inside an MPLS core into the other. There is a 115 work-around discussed in [1] that solves the problem. Model C can 116 also be secured well on the control plane. But as the ASBRs do not 117 have any VPN information and the inner-most label cannot be 118 validated, the data-plane has architectural weakness with respect to 119 security. This enables unidirectional packets to be sent into the VPN 120 sites connected to the other AS, which cannot be protected against by 121 mere configuration. Model C can therefore only be deployed where 122 service providers trust each other. For more details refer to [1]. 124 In [2] the authors propose encryption techniques, such as IPSec, for 125 securing the provider edge (PE) to PE legs of the network. However 126 the authors also highlight that the processing capacity could be 127 over-burdened. If an attacker is located at the core of the network, 128 or in the intermediate link or network between the providers that 129 constitute a inter-provider MPLS VPN solution, then spoofing attacks 130 are possible. In case an attacker spoofs the inner labels that 131 identify packets going towards a L3 VPN site, sensitive information 132 related to services available within the organizational servers can 133 be compromised. A denial-of-service (DoS) attack could also be 134 launched against these sensitive sites. As far as we know, there is 135 no scheme adopting encryption available for installing an anti- 136 spoofing mechanism for these VPN service labels. The proposed scheme 137 in this document provides an alternative in case other schemes that 138 dont adopt encryption are not suitable. The PEs at the end to which 139 the VPN customer is attached will accept any packet with a valid 140 label and will forward it to the VPN customer. There is no way to 141 ensure the veracity of a spoofed packet. 143 1.1 Security issue in model C 145 The deficiency discussed above is particularly true in the case of 146 inter-provider BGP based MPLS VPN model C. Even though model C is 147 highly scalable for carrying VRF routes, the vulnerability of the 148 data-plane has rendered it unusable and the current recommendation is 149 that model C must not be used. As discussed in [1] the insecurity for 150 model C stems from the fact that anybody within the core of the 151 network or at the peering points of the providers can cause DoS 152 attacks or worm attacks. It is possible to filter all IP traffic with 153 the exception of the required eBGP peering between the AS border 154 routers thereby preventing a large number of potential IP traffic 155 related attacks. Labelled packets, however, are much harder to 156 control. In model C, there are at least two labels for each packet: 157 the PE label, which defines the Label Switched Path (LSP) to the 158 egress PE, and the VPN label, which defines the VPN on the PE to 159 which the packet is associated. 161 1.2 Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Methodology of the Proposal 169 Consider a setup as below 171 The reference MPLS-eBGP based VPN network for model-C / Option-C as 172 described in [11] is shown in Figure 1, which also shows the control 173 plane exchanges. The near-end PE (PE_ne) and far-end PE (PE_fa) are 174 connected through the inter-provider MPLS core. The VPN connectivity 175 is established through a set of routers from different Autonomous 176 Systems (AS) and their ASBRs. In the VPN, MP-eBGP updates are 177 exchanged for a set of Forward Equivalence Classes (FECs). These 178 FECs, which have to be protected, originate from the prefixes behind 179 PE_ne in a VPN site or a set of VPN sites. 181 _______[AB1]________________ ___________[AB2]___________ 182 ( / | ) ( / \ ) 183 ( / +-----------+ ) ( / \ ) 184 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 185 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 186 ( | | ) ( | | ) 187 ( | | ) ( | | ) 188 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]_________________[PE_fa] 189 | 190 172.18.10.0/24 NH:PE_ne 172.18.20.0/24 [CE2] 191 VPN Label: Inner Label IL1 193 For the example below we refer to PE_ne and PE_fa in the diagram as 194 PE-1 and PE-2. 196 1) PE-1 and PE-2 would establish a MPeBGP-VPNV4 session between them 198 2) PE-1 and PE-2 will exchange VPN-labels for the prefixes (FECs) 199 between them which are to be used during forwarding 201 3) This mechanism does not avoid an attacker who is trying to spoof a 202 packet from somewhere inside the core or from within the network 203 between the two ISP / provider networks. 205 There are 2 ways to solve this problem 207 2.1 Solution:1 209 2.1.1 Control Plane operation 211 1) PE-1 and PE-2 agree upon looking for a "Secure Label" in addition 212 to the VPN label 214 2) PE-1 and PE-2 use PKI and publish their respective public keys. 216 _______[AB1]________________ ___________[AB2]___________ 217 ( / | ) ( / \ ) 218 ( / +-----------+ ) ( / \ ) 219 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 220 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 221 ( | | ) ( | | ) 222 ( | | ) ( | | ) 223 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 224 ^ ^ 225 +-------------- MP-eBGP IPVPN-V4 session --------------+ 227 Figure 2:PKI exchange to exchange their respective public keys. 229 3) PE-1 and PE-2 also agree upon a universal hashing algorithm to 230 use. It could be any of standard universal hashing algorithms which 231 minimize collisions to the maximum extent possible. They also agree 232 upon a bitmask that is to be used in step 5.1. These could be 233 exchanged using the MP-eBGP label exchange mechanism using suitable 234 fields which will be discussed in the appendix A.1 to be added later. 236 4) Unlike the VPN label that is exchanged as part of the MPBGP-VPNV4 237 exchange, the "Secure Label" is generated on the fly during forwarding. 239 _______[AB1]________________ ___________[AB2]___________ 240 ( / | ) ( / \ ) 241 ( / +-----------+ ) ( / \ ) 242 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 243 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 244 ( | | ) ( | | ) 245 ( | | ) ( | | ) 246 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 247 ^ ^ 248 +-------------- MP-eBGP IPVPN-V4 session --------+ 250 172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24 251 VPN Label: Inner Label IL1 252 Universal hashing Algorithm: UA1, 253 Bitmask: B1 255 5) Secure labels are generated for prefixes reachable via PE-1 by PE-2 256 5.1) PE-2 takes a hash on the first 256 bytes of the packet's 257 payload received using the universal hashing algorithm agreed upon. 258 If the PEs are from the same vendor or from a different vendor the 259 algorithm to be used is expressed in a standard identifier which is 260 understood by both PEs. 262 5.2) Take any 20 bits from the hash using a bitmask that is also 263 shared amongst the two PEs. 265 5.3) Take this 20 bit value and encrypt with the private key of PE-2 266 if traffic is flowing from PE-2 to PE-1. The inner label, universal 267 hashing algorithm and the bitmask are sent from PE-1 to PE-2 for 268 prefixes reachable via PE-1. Steps 5.1 to 5.3 are done as part of data 269 plane operations which are explained below. 271 2.1.2 Data-Plane Operation 273 _______[AB1]________________ ___________[AB2]___________ 274 ( / | ) ( / \ ) 275 ( / +-----------+ ) ( / \ ) 276 (IL1:SL:172.18.10.1 L1:IL1:SL:172.18.10.1 / \ ) 277 ( | L3:IL1:SL:172.18.10.1 <-+ L4:IL1:SL:172.18.10.1) 278 ( | | ) ( | | ) 279 ( | | ) ( | | ) 280 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 282 172.18.10.0/24 L2:IL1:SL:172.18.10.1 172.18.20.0/24 284 1) Let us assume a customer connected to PE-2 is sending a packet to 285 PE-1 287 2) The packet could be any payload encapsulated in the MPLS header 288 having the usual stack of labels for MODEL-C 290 3) When the packet reaches PE-2, following operation is done 292 3.1) Generate a hash of the received packet using the universal 293 hashing algorithm chosen. 295 3.2) Take agreed 20 bits from the hash using the bitmask exchanged. 296 (Text below talks about what 20 bits to take) 298 3.3) Encrypt those 20 bits with PE-2's private key 300 3.4) Send the packet with VPN label on top of the secure label 302 4) When the packet reaches PE-1, following operation is done 304 4.1) Generate a hash on the 256 bytes of data after the secured 305 label 307 4.2) Take agreed 20 bits using the bitmask agreed upon after 308 hash calculation in #4.1, call it 'K' 310 4.3) Decrypt received secured-label using public key of PE-1 312 4.4) Check if decrypted secured label and K are same. 314 4.5) If both are same then forward the packet otherwise drop it 316 2.1.3 Mapping a hash to a 20 bit value 318 1) The universal hashing algorithm selected generates a 128 bit value 319 but a MPLS label is 20 bit value 321 2) A mechanism is necessary to map 128 bits to a 20 bit value 323 3) PE-1 and PE-2 would exchange a 128 bitmask which is used to convey 324 which 20 bits in that 128 bits is to be used for the purposes of 325 encryption 327 4) This bitmask / bitmap is generated randomly and exchanged at the 328 time of MP-eBGP NLRI exchanges and expires every t seconds. 330 5) Whenever a new bitmap is generated, this would be shared between 331 the PE's 333 2.2 Solution:2 335 2.2.1 Control Plane operation 337 _______[AB1]________________ ___________[AB2]___________ 338 ( / | ) ( / \ ) 339 ( / +-----------+ ) ( / \ ) 340 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 341 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 342 ( | | ) ( | | ) 343 ( | | ) ( | | ) 344 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 345 ^ ^ 346 +-------------- MP-eBGP IPVPN-V4 session --------------+ 348 (1) PKI exchange to exchange their respective public keys. 350 1) PE-1 and PE-2 use PKI and publish their respective public keys. 352 2) PE-1 and PE-2 agree upon looking for a digital signature below 353 the EOS label.This would be done with an appropriate indicator in the 354 MP-eBGP update which would tell the other PE (far-end PE) that a 355 digital signature mechanism is to be used for purposes of protecting 356 the payload / stream between the two PEs. 358 _______[AB1]________________ ___________[AB2]___________ 359 ( / | ) ( / \ ) 360 ( / +-----------+ ) ( / \ ) 361 ( Net:PE_ne Net:PE_ne ) ( Net:PE_ne Net:PE_ne ) 362 ( LDP Label:POP LDP Label:L1 ) (LDP Label:L3 LDP Label:L4) 363 ( | | ) ( | | ) 364 ( | | ) ( | | ) 365 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 366 ^ ^ 367 +-------------- MP-eBGP IPVPN-V4 session --------+ 369 172.18.10.0/24 (4) NH:PE_ne 172.18.20.0/24 370 VPN Label: Inner Label IL1 371 Universal hashing Algorithm: UA1, 372 Digital Signature mechanism 374 3) PE-1 and PE-2 also agree upon what universal hashing algorithm to 375 use. 377 4) Digital signature is generated as follows 379 4.1) First take a hash on the first 256 bytes of the packet received 381 4.2) Encrypt with private key available for the transaction. 383 2.2.2 Data-Plane Operation 385 _______[AB1]________________ ___________[AB2]___________ 386 ( / | ) ( / \ ) 387 ( / +-----------+ ) ( / \ ) 388 (IL1:DS:172.18.10.1 L1:IL1:DS:172.18.10.1 / \ ) 389 ( | L3:IL1:DS:172.18.10.1 <-+ L4:IL1:DS:172.18.10.1) 390 ( | | ) ( | | ) 391 ( | | ) ( | | ) 392 [CE1]<-[PE_ne]__________[ASBR1]<---->[ASBR2]__________[PE_fa]-->[CE2] 394 172.18.10.0/24 L2:IL1:DS:172.18.10.1 172.18.20.0/24 396 1) Let us assume a customer connected to PE-1 is sending a packet 397 to PE-2 399 2) The packet could be any payload encapsulated in the MPLS header 400 having a stack of labels for MODEL-C 401 3) When the packet reaches PE-1, following operation is done 403 3.1) Generate a hash of the received packet involving the first 404 256 bytes of the packet. 406 3.2) Encrypt the hash with private key of PE-1. 408 3.3) Add these encrypted 128 bits below EOS label 410 3.4) Send the packet with VPN label and with encrypted 411 digital signature below EOS label 413 4) When the packet reaches PE-2, following operation is done 415 4.1) Based on the VPN label, PE-2 knows that it needs to look for 416 a digital signature below EOS label 418 4.2) Remove 128 bit digital signature below EOS label 420 4.3) Calculate a hash after removing the digital signature, 421 call it 'J' 423 4.4) Decrypt the received digital signature with public key of 424 PE-1, Call it 'K' 426 4.5) compare the J and K. If they are equal, forward 427 the packet else drop it. 429 Note: 431 1) For both solutions, hash is calculated only before slapping VPN 432 label at PE-1, ie TTL update gets over by then 434 2) In case of Solution 2, to support ECMP case, we could add one 435 nibble extra in front of the digital signature based on IPV4 or IPV6 437 2.3 Use Case:1 439 1) The above case talks about usage of this mechanism in VPN case 441 2.4 Use Case:2 (RSVP can use this during tunnel setup) 443 1) Head-end during tunnel setup can inform tail-end about "Secured- 444 Label" during setup 446 2) We can use any of the above solutions for LSP setup as well. 448 2.5 Advantages 449 1) Any attacker's packet would have to guess a 40 bit label in the 450 case of Solution 1 and a 20 + 128-bit DS label in Solution 2. 452 2) Since we are using PKI, it is impossible for an attacker to create 453 a packet with same semantics(of PE) since he would have to guess the 454 Algorithm UA(x) and the bitmask pattern in Solution (1) and the PKI 455 key as well. In Solution (2) he would have to guess the PKI key and 456 the Algorithm UA(x). 458 3) Provides real security from attacker in the case of a man-in-the- 459 middle attack say from the intervening network between the two 460 providers. 462 5) The same mechanism could be used by RSVP for tunnel setup between 463 Head-end and tail-end. Head-end during RSVP set-up can inform tail- 464 end to use the "Secured-Label" mechanism or the DS mechanism in 465 Solution 1 and Solution 2 respectively. 467 2.6 Limitations 469 1) An additional decryption and hashing is necessary in PE for 470 secured labels in Solution 2 and in Solution 1 a bitmask lookup and 471 selection is required over and above the decryption and hashing. 473 2) This mechanism will not work if this packet is fragmented inside 474 the core. But given that fragmentation is not done as PMTUD may 475 be in vogue this is not really a serious limitation. 477 3 Security Considerations 479 PKI is a secure mechanism as established in common security 480 parlance. The control plane is secure in Option-C / Model-C in 481 Inter-provider VPNs. It would take more than polynomial time 482 complexity for an attacker to spoof the traffic when this 483 mechanism is in vogue. Thus spoofing attacks are obviated. 485 4 IANA Considerations 487 IANA needs to assign the Type value for exchanging the additional 488 details in the control plane as illustrated in the above two 489 solutions. 491 5 References 493 5.1 Normative References 495 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 499 1 1995. 501 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 502 April 1 1996. 504 5.2 Informative References 506 [1] S. Alouneh, A. En-Nouaary and A. Agarwal, MPLS 507 security: an approach for unicast and multicast 508 environments, Annals of Telecommunications, Springer, vol. 509 64, no. 5, June 2009, pp. 391-400, doi:10.1007/s12243-009- 510 0089-y. 512 [2] M. H. Behringer and M. J. Morrow, MPLS VPN security, 513 Cisco Press, June 2005, ISBN-10: 1587051834. 515 [3] B. Daugherty and C. Metz, Multiprotocol Label 516 Switching and IP, Part 1, MPLS VPNS over IP Tunnels, IEEE 517 Internet Computing, May-June 2005, pp. 68-72, doi: 518 10.1109/MIC.2005.61. 520 [4] L. Fang, N. Bita, J. L. Le Roux and J. Miles, 521 Interprovider IP-MPLS services: requirements, 522 implementations, and challenges, IEEE Communications 523 Magazine, vol. 43, no. 6, June 2005, pp. 119-128, doi: 524 10.1109/MCOM.2005.1452840. 526 [5] C. Lin and W. Guowei, Security research of VPN 527 technology based on MPLS, Proceedings of the Third 528 International Symposium on Computer Science and 529 Computational Technology (ISCSCT 10), August 2010, pp. 530 168-170, ISBN- 13:9789525726107. 532 [6] Y. Rekhter, B. Davie, E. Rosen, G. Swallow, D. 533 Farinacci and D. Katz, Tag switching architecture 534 overview, Proceedings of the IEEE, vol. 85, no. 12, 535 December 1997, pp. 1973-1983, doi:10.1109/5.650179. 537 [7] E. Rosen and Y. Rekhter, BGP/MPLS IP Virtual Private 538 Networks (VPNs), RFC 4364, Standard Track, February, 2006. 540 [8] T. H. Cormen, C. E. Leiserson, R. L. Rivest and C. 541 Stein, Introduction to algorithms, 3rd edition, MIT Press, 542 September 2009, ISBN-10:0262033844. 544 [9] C. Semeria, RFC 2547bis: BGP/MPLS VPN fundamentals, 545 Juniper Networks white paper, March 2001. 547 [10] Advance MPLS VPN Security Tutorials [Online], 548 Available: 549 http://etutorials.org/Networking/MPLS+VPN+security/ 550 Part+II+Advanced+MPLS+VPN+Security+Issues, [Accessed: 10th 551 December 2011] 553 [11] Inter-provider MPLS VPN models [Online], Available: 554 http://mpls-configuration-on-cisco- 555 iossoftware.org.ua/1587051990/ ch07lev1sec4.html, 556 [Accessed 10th December 2011] 558 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 559 RFC 3514, April 1 2003. 561 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 562 Acronyms", RFC 5513, April 1 2009. 564 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 565 2009. 567 Authors' Addresses 569 Bhargav Bhikkaji, 570 Dell-Force10, 571 350 Holger Way, 572 San Jose, CA 95134 573 U.S.A 575 EMail: BHARGAV_BHIKKAJI@dell.com 577 Balaji Venkat Venkataswami, 578 Dell-Force10, 579 Olympia Technology Park, 580 Fortius block, 7th & 8th Floor, 581 Plot No. 1, SIDCO Industrial Estate, 582 Guindy, Chennai - 600032. 584 EMail: BALAJI_VENKAT_VENKAT@dell.com