idnits 2.17.1 draft-townsley-l3vpn-l2tpv3-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 532), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 18 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L2TPV3' is mentioned on line 91, but not defined == Missing Reference: 'MPLS-L2TPV3' is mentioned on line 126, but not defined == Missing Reference: 'MPLS-IPsec' is mentioned on line 421, but not defined == Missing Reference: 'RFC2434' is mentioned on line 426, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 -- Possible downref: Normative reference to a draft: ref. 'MPLS-L2TPv3' -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-05) exists of draft-nalawade-kapoor-tunnel-safi-01 == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-ipsec-2547-01 == Outdated reference: A later version (-10) exists of draft-behringer-mpls-security-05 == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-gre-ip-2547-00 Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Mark Townsley 3 Internet-Draft cisco Systems 4 Ted Seely 5 January 2004 Sprint 7 BGP/MPLS IP VPNs over Layer 2 Tunneling Protocol ver 3 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt . 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html . 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a 39 protocol for tunneling a variety of payload types over IP networks. 40 This document describes a variation of "BGP/MPLS IP VPNs" in which 41 the outermost MPLS label of a VPN packet is replaced with an L2TPv3 42 encapsulation, enabling the VPN packets to be carried over an IP 43 network. 45 Contents 47 Status of this Memo.......................................... 1 49 1. Introduction.............................................. 2 50 1.1 Terminology........................................... 3 51 1.2 Overview.............................................. 3 53 2. MPLS over L2TPv3 Encapsulation............................ 3 54 2.1 Encapsulation by Ingress PE........................... 5 55 2.2 Decapsulation by Egress PE............................ 5 57 3. Assigning the Session ID and Cookie....................... 5 58 3.1 Distribution of the Session ID and Cookie via BGP..... 6 60 4. Implications on Packet Spoofing........................... 6 62 5. Applicability............................................. 7 64 6. Security Considerations................................... 8 66 7. IANA Considerations....................................... 9 68 8. Acknowledgments........................................... 10 70 9. References................................................ 10 71 9.1 Normative References.................................. 10 72 9.2 Informative References................................ 10 74 10. Contacts................................................. 11 76 Specification of Requirements 78 In this document, several words are used to signify the requirements 79 of the specification. These words are often capitalized. The key 80 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 81 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 82 are to be interpreted as described in [RFC2119]. 84 1. Introduction 86 The "BGP/MPLS IP VPNs" base specification described in [RFC2547] 87 defines a particular style of Layer 3 Virtual Private Network (L3VPN) 88 using MPLS label switched paths between Provider Edge (PE) routers. 89 This document describes an extension to the [RFC2547] specification 90 by defining procedures for providing the same style of L3VPN using 91 L2TPv3/IP [L2TPV3] tunnels (rather than MPLS LSPs) as the 92 encapsulation between PE routers. 94 1.1 Terminology 96 Terminology used in this document is defined in [PPVPN-TERMS] and not 97 reiterated here. Terms relevant to this document include: 99 Customer Edge device (CE) 100 Provider Edge (PE) 101 Virtual Private Network (VPN) 102 Layer 3 VPN (L3VPN) 103 BGP/MPLS IP VPN 104 VPN Routing and Forwarding (VRF) 106 1.2 Overview 108 In a BGP/MPLS IP VPN, when a PE router receives a packet from a CE 109 router, it looks up the packet's destination IP address in a VPN 110 Routing and Forwarding (VRF) table. As a result of this lookup, it 111 obtains an MPLS label stack, a data link header, and an output 112 interface. The label stack is prepended to the packet, the data link 113 header is prepended to that, and the resulting frame is queued for 114 the output interface. 116 The "bottom label" [RFC3032] on the MPLS label stack is always a 117 label which will not be seen until the packet reaches its point of 118 egress from the network. This label represents a particular route 119 within the packet's VPN and will be referred to in this document as a 120 "VPN label." The purpose of the upper labels is to cause the packet 121 to be delivered to the router which understands the VPN label. Thus, 122 a BGP/MPLS IP VPN may be constructed among any set of PEs for which 123 the VPN label is carried intact. 125 This document describes methods for carrying a VPN label among PEs 126 via the MPLS over L2TPv3 encapsulation as described in [MPLS-L2TPV3]. 127 This enables a BPG/MPLS IP VPN which traditionally required an MPLS- 128 enabled core network to utilize an L2TPv3 encapsulation over an IP 129 network instead. An applicability section describing L2TPv3 in 130 context with MPLS, GRE, IP, and IPsec is presented as well. 132 2. MPLS over L2TPv3 Encapsulation 134 MPLS over L2TPv3 as defined in [MPLS-L2TPv3] allows the tunneling of 135 an MPLS label stack [RFC3032] over an IP network via L2TPv3. A 136 BGP/MPLS IP VPN over L2TPv3 utilizes a single VPN label (MPLS bottom 137 label) which is carried over the L2TPv3 encapsulation. This is 138 depicted in Figure 2.1 and 2.2. 140 +-+-+-+-+-+-+-+-+-+-+ 141 | IP | 142 +-+-+-+-+-+-+-+-+-+-+ 143 | L2TPv3 | 144 +-+-+-+-+-+-+-+-+-+-+ 145 | VPN Label | 146 +-+-+-+-+-+-+-+-+-+-+ 147 | VPN Payload (IP) | 148 +-+-+-+-+-+-+-+-+-+-+ 150 Figure 2.1 BGP/MPLS IP VPN over L2TPv3/IP 152 0 1 2 3 153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Session ID | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Cookie (optional, maximum 64 bits)... 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 ... | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | (VPN) Label | Exp |S| TTL | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 2.2 MPLS VPN Label over L2TPv3 encapsulation 167 Session ID 169 The L2TPv3 Session ID is a 32-bit identifier field locally 170 selected as a lookup key for the context of an L2TP Session. An 171 L2TP Session contains necessary context for processing a received 172 L2TP packet. For the application described in this document, this 173 includes whether the Cookie is present, the value it was assigned, 174 and that a MPLS VPN label follows. 176 Cookie 178 The L2TPv3 Cookie field contains a variable length (maximum 64 179 bits) value assigned by a cryptographically random [RFC1750] 180 algorithm. 182 VPN Label 184 An MPLS label used to identify a route for a BGP/MPLS IP VPN. 186 Please refer to [MPLS-L2TPv3] for other MPLS over L2TPv3/IP 187 encapsulation specifics. 189 2.1 Encapsulation by Ingress PE 191 When a PE receives a packet from a CE, it looks up the packet's IP 192 destination address in the VRF corresponding to that CE. This enables 193 it to find an IP route within the VPN. This route will have an 194 associated MPLS label (the VPN label) and BGP Next Hop with 195 reachability information for the Next Hop in the form of a set of 196 L2TPv3 tunnel parameters (IP Address, Session ID and Cookie). The VPN 197 label, L2TPv3, and IP encapsulation headers are prepended to the 198 packet. The IP source address field of the encapsulation header will 199 be an address of the ingress PE itself. The IP destination address 200 field of the encapsulation header will contain the value of the 201 associated BGP Next Hop attribute; this will be an IP address of the 202 egress PE. 204 As defined in [L2TPv3], the Ingress PE MUST support the ability to 205 encapsulate a 32 and 64 bit Cookie, or no Cookie at all. The Egress 206 PE (section 2.2) is always in control of the size and value of the 207 cookie to be encapsulated by the Ingress PE by virtue of it 208 advertising its own tunnel reachability information (section 3). In 209 order to achieve the anti-spoofing benefits of the Cookie as 210 described in section 4, a 64-bit Cookie MUST always be used. 212 2.2 Decapsulation by Egress PE 214 Upon receipt of the L2TPv3 packet addressed to a local IP address at 215 the PE, a context lookup on the Session ID returns the Cookie for 216 validation and the type of payload that follows. If the Cookie does 217 not match, the packet MUST be dropped and a counter incremented in 218 order to detect the occurrence of received cookie mismatches (this 219 MAY be a global counter for the PE). If the type of payload is MPLS, 220 then the packet is delivered to the routing function for MPLS 221 switching. 223 The Egress PE is in control of the size and value of the Cookie it 224 will permit packets to be received and processed with. As such, it is 225 not a protocol violation to always advertise a 64-bit cookie, or no 226 cookie at all. In order to achieve the anti-spoofing benefits of the 227 Cookie as described in section 4, a 64-bit Cookie MUST be used and 228 MUST be the default configuration. A zero or 32-bit Cookie MAY be 229 used to reduce the size of the tunnel encapsulation if there are 230 other forms of authentication embedded with the packet at another 231 layer (e.g., IPsec authentication). 233 3. Assigning the Session ID and Cookie 235 A minimum of one L2TPv3 Session ID must be allocated per PE. This 236 Session ID may be any 32-bit value, and may be manually configured or 237 distributed via a signaling protocol. The Session ID need not be 238 different for all PEs within a VPN, thus a single "global" value MAY 239 be used. 241 The L2TPv3 Cookie MUST be selected via a cryptographically random 242 algorithm [RFC1750] and distributed (either by configuration or a 243 signaling protocol) to all PEs. The default size for the Cookie MUST 244 be 64 bits. A 32 or 0 (not present) bit Cookie MAY be used if another 245 form of packet authentication is present at another layer (e.g. IPsec 246 authentication). Unlike the Session ID, the Cookie SHOULD be 247 different at each PE within a VPN. 249 3.1 Distribution of the Session ID and Cookie via BGP 251 The combination of the PE IP address, L2TPv3 Session ID, and Cookie 252 embody the necessary reachability information for a PE to participate 253 in an RFC 2547 Style VPN over L2TPv3. BGP may be extended as defined 254 in [NALAWADE] to distribute the L2TPv3 reachability information for 255 the PE. The VPN label is distributed in BGP via the VPN-IPv4 address 256 family as is typical for a BGP/MPLS IP VPN. 258 The set of L2TPv3 tunnel parameters (IP address, Session ID and 259 Cookie) MUST be able to be updated for a given PE at any time without 260 disruption of the VPN service. This allows for on-demand or periodic 261 update of reachability information. 263 4. Implications on Packet Spoofing 265 Without the L2TPv3 Cookie, protection against spoofed VPN packets 266 carried over IP requires having all the boundary routers perform 267 filtering; either filtering out packets from "outside" which are 268 addressed to PE routers, or filtering out packets from "outside" 269 which have source addresses that belong "inside" and filtering on 270 each PE all packets which have source addresses that belong 271 "outside". The maintenance of these filter lists can be management- 272 intensive, and the their use at all border routers can affect the 273 performance seen by all traffic entering the SP's network. 275 Unlike boundary filters, the L2TPv3 Session ID and Cookie are 276 selected and distributed automatically among participating PEs, 277 requiring virtually no additional operational impact and no impact on 278 the performance of border routers whatsoever. While the L2TPv3 Cookie 279 does not provide cryptographic security protection, it does provide 280 effective protection against "blind" spoofed packet insertion attacks 281 on an SP network in a very efficient manner. 283 A "blind" insertion attack is defined as a packet spoofing attack 284 where: 286 The attacker has the ability to insert spoofed IP packets into the 287 service provider core, circumventing edge filters at one or more 288 locations. 290 The attacker knows the address of one or more PEs participating in 291 the VPN service, and can send spoofed packets to these addresses 292 at will. 294 The attacker does NOT have the ability to instantaneously sniff, 295 reroute, or otherwise obtain legitimate data in transit between 296 participating PE routers for use in a coordinated spoofing attack. 298 The blind insertion attack is indicative of an attacker who is able 299 to operate without much sophistication, particularly if armed with an 300 automated tool populated with a few unscrupulously obtained 301 parameters such as the VPN PE IP address(es) and vulnerable core 302 entry points. This type of attacker may have very good success in 303 randomly guessing a valid MPLS VPN label for insertion into a 304 customer VPN. For example, if 4096 unique VPN labels are being 305 advertised by a given PE, the probability approaches one that random 306 guessing would yield a valid result for as few as 256 attempts 307 (2^20/4096 = 256). The more VPN labels advertised, the more likely 308 one might guess a valid label which would end up being routed to the 309 customer VPN. 311 A 64-bit Cookie within L2TPv3 is a very significant barrier against a 312 packet spoofing attack. Consider a PE which has been assigned two 313 valid random cookies. All L2TPv3 traffic entering this PE must be 314 stamped with the proper value in order to be accepted. Thus, the 315 probability that a random guess would yield the correct value is 316 2/2^64. Assuming the ability to guess at a rate of 10 Mpps, the 317 probability approaches one that a correct value would be selected 318 after 2^64 / 10*10^6 /2 seconds, or more than 29,000 years (note that 319 the same calculation with a 32 bit Cookie yields 3 minutes 35 320 seconds, thus a 64 bit key is recommended). Further, if it is 321 expected that the Cookie has become compromised, it may be re- 322 advertised without affecting outstanding VPN labels or CE 323 connectivity to the VPN. 325 5. Applicability 327 The methods defined [MPLS-IP-GRE-L3VPN], [MPLS-IPSEC] and this 328 document all describe methods for carrying MPLS over an IP network in 329 support of an RFC 2547 Style VPN. Situations where L2TPv3 may be 330 preferable include: 332 L2TPv3 can provide protection against VPN packet spoofing in a 333 very lightweight manner. [MPLS-IPSEC] provides cryptographic 334 protection against this and other potential vulnerabilities, but 335 at greater operational and packet processing overhead (it should 336 be noted here that L2TPv3 may be protected by IPsec as well given 337 that it is a general mechanism for securing IP traffic). [MPLS- 338 IP-GRE-L3VPN] does not provide any protection for packet insertion 339 attacks beyond reliance upon core network boundary filtering. 341 (The following two applicability statements are adopted from [MPLS- 342 IP-GRE]) 344 If two routers are "adjacent" over an L2TPv3 tunnel that exists 345 for some reason outside the scope of this document, and those two 346 routers need to send MPLS packets over that adjacency. 348 Implementation considerations may dictate the use of MPLS-in- 349 L2TPv3. For example, some hardware device might only be able to 350 handle L2TPv3 encapsulations in its fastpath. 352 In summary, L2TPv3 can provide a balance between the limited security 353 against IP spoofing attacks offered by [MPLS-IP-GRE-L3VPN] vs. the 354 greater overhead required by an [MPLS-IPSEC]. Further, an BGP/MPLS 355 IP VPN over L2TPv3 may be faster in some hardware, particularly if it 356 is already optimized to classify incoming L2TPv3 packets carrying IP 357 framed in a variety of ways. That is, IP encapsulated by HDLC or 358 Frame Relay over L2TPv3 may be considered not that far removed from 359 IP encapsulated by an MPLS label carried over L2TPv3. 361 6. Security Considerations 363 BGP/MPLS IP VPN security is discussed in detail in [MPLS-VPN-SEC]. 364 The analysis shows that BGP/MPLS IP VPN networks can be considered as 365 secure as a more traditional layer-2 VPN network such as Frame Relay. 366 Many of the properties discussed in this document are equivalent when 367 a VPN label is carried over L2TPv3 or MPLS, in particular topics such 368 as "Address space, Routing and Traffic Separation." The security 369 provided by L2TPv3 acts as an additional layer of protection among 370 the participating PEs themselves. 372 There are subtle differences when discussing resistance to packet 373 spoofing attacks on an IP network vs. an MPLS network, as the core 374 transport for the VPN packets plays a large role. In order for a 375 BGP/MPLS IP VPN to be secure over an MPLS infrastructure, it is 376 assumed in [MPLS-VPN-SEC] that it is impossible to insert spoofed 377 MPLS packets into an MPLS core network since labeled packets should 378 never be accepted from a CE. As long as this principle holds (i.e., 379 there is no physical tap by a hacker on the core of the network), 380 there is no possibility of spoofing since packets cannot enter the 381 network from outside in the first place. 383 In practice, an IP core network may be more vulnerable to spoofing 384 attacks than an isolated MPLS core network as the various L3 ACLs 385 necessary to filter traffic at the edge of the network can be more 386 cumbersome to setup and maintain than simply dropping any MPLS 387 labeled packet. Use of the L2TPv3 Cookie (as described in Section 4) 388 provides an extra layer of anti-spoofing protection as long as the 389 hacker does not have the ability to capture, decode, and utilize 390 traffic on the core network in a coordinated replay attack (i.e., as 391 above, there is no physical tap by a hacker on the core of the 392 network). 394 Thus, given the assumptions for an MPLS core network that no labeled 395 packets may enter the core from an untrusted source, and the 396 assumption for an IP core network that an untrusted source cannot 397 sniff packets in transit for use in a coordinated attack, the 398 security of a BGP/MPLS VPN over L2TPv3 with an IP core is effectively 399 equivalent to that of a BGP/MPLS IP VPN over an MPLS core. 401 It is very important for the security of the anti-spoofing mechanism 402 of L2TPv3 that the Cookie be selected in a truly random manner, and 403 that a series of cookies not be predictable. It should be assumed 404 that a hacker has access to similar hardware and software for 405 examining a series of assigned Cookie values for a given 406 implementation. The precise algorithm for Cookie selection is not 407 defined in this document, though [RFC1750] provides guidelines that 408 should be followed for the selection of an algorithm. 410 The cryptographic protection of IPsec provides greater security than 411 the methods described in this document or that of an MPLS core 412 network as it does not rely on the assumption that a hacker does not 413 have privileged access to traffic in the network core. If an IP or 414 MPLS core network is subject to packet sniffing such that traffic in 415 transit between PEs may be used in a coordinated spoofing attack 416 across core network boundaries, then MPLS over IPsec is necessary to 417 provide true security against these types of attacks. Since IPsec may 418 be used to secure any type of host-to-host IP traffic, it can be used 419 to secure MPLS/L2TPv3 traffic by setting up the proper IPsec policies 420 to match L2TPv3 traffic between participating PEs or to secure MPLS 421 over GRE or MPLS over IP as described in [MPLS-IPsec]. 423 7. IANA Considerations 425 This document creates a no new requirements on IANA namespaces 426 [RFC2434]. 428 8. Acknowledgments 430 Portions of text in this document was borrowed or adapted from 431 [MPLS-IP-GRE-L3VPN]. Thanks to Dave Meyer and Michael Behringer for 432 review, comments and suggestions. 434 9. References 436 9.1 Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [L2TPv3] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling 442 Protocol (Version 3)", work in progress, 443 draft-ietf-l2tpext-l2tp-base-14.txt, June 2004. 445 [MPLS-L2TPv3] M. Townsley, "Encapsulation of MPLS over Layer 2 446 Tunneling Protocol Version 3", draft-townsley-l2tpv3-mpls-02.txt 447 October 2004 449 9.2 Informative References 451 [RFC1750] D. Eastlake III, S. Crocker, J. Schiller, "Randomness 452 Recommendations for Security", RFC 1750, December 1994 454 [RFC2547] E. Rosen, Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. 456 [RFC3032] R. Rosen, et. al., "MPLS Label Stack Encoding," RFC 3032, 457 January 2001. 459 [NALAWADE] G. Nalawade, R. Kapoor, D. Tappan, "IPv4-Tunnel SAFI", 460 work in progress, draft-nalawade-kapoor-tunnel-safi-01.txt, 461 October 2003. 463 [MPLS-IPSEC] E. Rosen, J. De Clercq, O/ Paridaens, Y. T'Joens, 464 C. Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", 465 work in progress, draft-ietf-l3vpn-ipsec-2547-01.txt, 466 August 2003. 468 [PPVPN-TERMS] L. Andersson, T. Madsen, "PPVPN terminology", 469 work in progress, draft-andersson-ppvpn-terminology-04.txt, 470 September 2003. 472 [MPLS-IP-GRE] T. Worster, Y. Rekhter, E. Rosen, "Encapsulating 473 MPLS in IP or Generic Routing Encapsulation (GRE)", 474 work in progress, draft-ietf-mpls-in-ip-or-gre-08.txt, 475 June 2004. 477 [MPLS-VPN-SEC] M. Behringer, "Analysis of the Security of BGP/MPLS IP VPNs," 478 work in progress, draft-behringer-mpls-security-05.txt, 479 November 2003. 481 [MPLS-IP-GRE-L3VPN] Y. Rekhter, E. Rosen, "Use of PE-PE GRE or IP in 482 RFC2547 VPNs", work in progress, draft-ietf-l3vpn-gre-ip-2547-00.txt 483 April 2003. 485 10. Contacts 487 W. Mark Townsley 488 cisco Systems 489 7025 Kit Creek Road 490 Research Triangle Park, NC 27709 491 mark@townsley.net 492 Ted Seely Sprint tseely@sprint.net 494 Intellectual Property Statement 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org. 518 Disclaimer of Validity 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 523 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 524 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 525 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Copyright Statement 530 Copyright (C) The Internet Society (2004). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78, and 532 except as set forth therein, the authors retain all their rights. 534 Acknowledgment 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.