idnits 2.17.1 draft-ietf-l3vpn-l3vpn-auth-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 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In order to support CE-based verification, the PE router MUST not activate routes to a directly connected VPN site until it has received a token from that site. When the PE has received a token, it activates those routes and advertise them to its iBGP peers. (That is, the PE advertises those routes to remote PE routers that support the VPN.) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PE MUST relay every token that it has acquired regarding a VPN to each directly connected customer device that participates in the VPN. When the PE router receives a new token, it MUST relay it to the appropriate customer devices immediately. Furthermore, the PE router MUST not reveal any tokens to customer devices that are contained by sites from which a token has not yet been received. -- 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.) -- The document date (December 2004) is 7070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'EXTBGP' on line 160 == Unused Reference: '2' is defined on line 304, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 310, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-07 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group R. Bonica 3 Internet-Draft Y. Rekhter 4 Expires: June 1, 2005 Juniper Networks 5 E. Rosen 6 R. Raszuk 7 D. Tappan 8 Cisco Systems 9 December 2004 11 CE-to-CE Member Verification for Layer 3 VPNs 12 draft-ietf-l3vpn-l3vpn-auth-01 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on June 1, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This document describes a CE-based verification mechanism that VPN 48 customers can use to detect security breaches caused by 49 misconfiguration of the provider network. 51 Table of Contents 53 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Customer-to-PE Signaling . . . . . . . . . . . . . . . . . . . 7 57 5. PE-to-PE Signaling . . . . . . . . . . . . . . . . . . . . . . 8 58 6. PE-to-Customer Signaling . . . . . . . . . . . . . . . . . . . 9 59 7. VPN Token Propagation Protocol . . . . . . . . . . . . . . . . 10 60 8. Configurability . . . . . . . . . . . . . . . . . . . . . . . 11 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 64 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . 16 68 1. Conventions Used In This Document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC2119 [3]. 74 2. Overview 76 When properly configured, a Layer 3 Virtual Private Network (L3VPN) 77 permits communications within a VPN, but prevents communication 78 across VPN boundaries. In order to maintain this posture, the 79 Service Provider must configure its network correctly. If the SP 80 assigns a customer interface to the wrong VPN, or commits some other 81 configuration error, unauthorized parties might join a VPN, while 82 legitimate VPN members are unaware of the security breach. 84 Therefore, some VPN customers may require a CE-based mechanism for 85 VPN membership verification. VPN customers could use the mechanism 86 to detect security breaches caused by misconfiguration of the 87 provider network. 89 This document describes a token-based approach to VPN membership 90 verification. In order to join a VPN, each VPN site sends a token to 91 the Provider Edge (PE) router to which it is attached. In many 92 cases, the Customer Edge (CE) router originates the token. In 93 configurations where the SP manages the CE, the customer can 94 designate another device contained by the VPN site as the token 95 originator. 97 Having received a token, the PE joins the VPN site to the VPN. The 98 PE accepts and activates routes to the VPN site and distributes those 99 routes throughout the provider network. The PE router also 100 distributes the token throughout the provider network. All PE 101 routers that support the VPN receive the token and relay it to each 102 directly connected customer device that participates in the VPN. 103 Customer devices use the token to verify membership of the newly 104 joined VPN site. 106 If a customer device receives a token that it does not recognize, it 107 issues an alarm requesting operator intervention. The customer 108 device may also withdraw from the VPN, neither sending traffic to the 109 VPN nor accepting traffic from it until an operator clears the 110 security condition. 112 Note that the PE will not reveal any tokens to a customer device 113 until it has received a token from the site that the customer device 114 supports. 116 The token-based approach described by this document contains three 117 components. These are: 119 Customer-to-PE signaling 120 PE-to-PE signaling 121 PE-to-Customer signaling 123 This document dedicates a section to each component. 125 3. Motivation 127 Currently, L3VPN customers cannot detect security breaches that are 128 caused by accidental misconfiguration of the SP network. For 129 example, assume that an SP maintains two VPN's. The first VPN 130 supports Customer A while the second VPN supports Customer B. Assume 131 also that Customer B requests a new VPN service connection. The SP 132 processes Customer B's request, but accidentally configures Customer 133 B's new connection into Customer A's VPN. 135 Typically, Customer B is first to detect the problem. Customer B 136 tells the SP that an error has occurred and the SP corrects the 137 error. The SP may or may not tell Customer A that his/her VPN has 138 been breached. 140 The CE-to-CE verification mechanism, described herein, informs both 141 customers of the VPN breach, providing immediate and automatic 142 notification. It does not prevent the breach or the misconfiguration 143 that caused it. 145 The CE-to-CE verification mechanism does not protect VPN customers 146 from intentional misbehavior on the SP's part. The VPN customer must 147 trust the SP to implement this mechanism faithfully. 149 4. Customer-to-PE Signaling 151 In order to join a VPN, each VPN site sends a token to the PE router 152 to which it is attached. In many cases, the CE will originate the 153 token. In configurations where the SP manages the CE, the customer 154 may designate another device contained by the VPN site as the token 155 originator. 157 If the device that originates the token also maintains a BGP [1] 158 peering session with the PE, the originating device can append the 159 token to each BGP update. To support this purpose, this document 160 defines a new transitive extended community [EXTBGP] called CE-to-CE 161 Verification Token. This community uses the format of the opaque 162 extended community. 164 The high-order octet of the Type field of the CE-to-CE Authentication 165 Token is 0x03. The low-order octet of the Type field is 0x02. The 6 166 octets of the Value field carries the token itself. 168 If the device that originates the token does not maintain a BGP 169 peering session with the PE, the VPN site can use new protocol 170 described in Section 7 of this document to send tokens to the PE. 171 This protocol can be used in any VPN configuration, regardless of 172 whether the originating device maintains a BGP peering session with 173 the PE. 175 5. PE-to-PE Signaling 177 In order to support CE-based verification, the PE router MUST not 178 activate routes to a directly connected VPN site until it has 179 received a token from that site. When the PE has received a token, 180 it activates those routes and advertise them to its iBGP peers. 181 (That is, the PE advertises those routes to remote PE routers that 182 support the VPN.) 184 If the provider network uses BGP to distribute VPN routes among PE 185 routers, it appends the token to each BGP update. Section 4 of this 186 document describes a BGP extended community attribute that supports 187 this purpose. 189 If the provider network does not use BGP to distribute VPN routes 190 among PE routers, it can use the new protocol described in Section 7 191 of this document to distribute tokens among PE routers. 193 6. PE-to-Customer Signaling 195 In order to support CE-based verification, the PE router MUST relay 196 tokens that it receives from other PE routers to directly connected 197 customer devices. The customer device can be a CE router or a 198 directly connected host. If the PE and customer device maintain a 199 BGP peering session with one another, the PE can use this BGP peering 200 session to send tokens to the customer device. Section 4 of this 201 document describes a BGP extended community attribute that supports 202 this purpose. 204 Section 7 of this document describes a new protocol that also can be 205 used to propagate tokens from PE to customer device. This protocol 206 can be used in any VPN configuration, regardless of whether the 207 customer device maintains a BGP peering session with the PE. 209 The PE MUST relay every token that it has acquired regarding a VPN to 210 each directly connected customer device that participates in the VPN. 211 When the PE router receives a new token, it MUST relay it to the 212 appropriate customer devices immediately. Furthermore, the PE router 213 MUST not reveal any tokens to customer devices that are contained by 214 sites from which a token has not yet been received. 216 7. VPN Token Propagation Protocol 218 The VPN Token Propagation Protocol is used to distribute tokens. 219 Figure 1 depicts the format of all messages. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Version | AuType | Token (Octets 1 - 2) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Token (Octets 3-6) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Authentication | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Authentication | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1 235 Figure 1: message 237 The Version field is equal to 1. 239 The AuType field indicates how this message should be authenticated. 240 It may contain the following values: 242 No Authentication 0 243 Simple Password 1 244 Message Digest-5 2 246 The Token field contains the verification token. 248 The Authentication field contains 64 bits of authentication data used 249 to authenticate the message. The AuType field specifies how these 64 250 bits are to be used. 252 The VPN Token Propagation Protocol establishes soft state between PE 253 and customer device. Announcements expire automatically upon 254 expiration of a configurable timer. Therefore announcements must be 255 repeated periodically. By default, announcements expire in 30 256 minutes, and should be refreshed 10 minutes. 258 The VPN Token Propagation Protocol obtains transport services from 259 UDP. All VPN Token Propagation Protocol messages are directed to UDP 260 port 3694. 262 8. Configurability 264 SPs can deploy the verification mechanisms described above globally 265 or on a per-VPN basis. In either case, a particular VPN site within 266 the verification domain may not be capable of announcing a token to 267 the PE that supports it. In this case, the SP can configure the PE 268 router so that it will permit that particular VPN site to join the 269 VPN. The PE router will associate a null token (i.e., 270 0x000000000000) with the VPN site. The PE router will distribute 271 this null token into the VPN as if it had been announced by the VPN 272 site. 274 Although the null token may be useful during migration periods, 275 customer should avoid its long term use. 277 9. Security Considerations 279 If VPN customer receives a token that it does not recognize, the VPN 280 customer should contact his/her SP immediately. The VPN customer 281 should also consider changing its token value, as the SP may have 282 revealed that value to an unauthorized party. 284 10. IANA Considerations 286 IANA will assign a new extended BGP community sub-type, with the 287 high-order octet of the Type field equal to 0x03 and low-order octet 288 equal to 0x02. This BGP extended community type will represent the 289 CE-to-CE Authentication Token. 291 IANA will has assigned UDP port number 3694 to the VPN Token 292 Propagation Protocol, described in Section 7. 294 11. Acknowledgements 296 Thanks to Beth Alwin, Eduard Metz, Richard Morgan, Benson Schliesser 297 and Paul Hoffman for their comments on this draft. 299 12 Normative References 301 [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 302 RFC 1771, March 1995. 304 [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 305 9, RFC 2026, October 1996. 307 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 308 Levels", BCP 14, RFC 2119, March 1997. 310 [4] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities 311 Attribute", draft-ietf-idr-bgp-ext-communities-07 (work in 312 progress), March 2004. 314 Authors' Addresses 316 Ronald P. Bonica 317 Juniper Networks 318 2251 Corporate Park Drive 319 Herndon, VA 20171 320 US 322 Phone: +1 571 203 1704 323 EMail: rbonica@juniper.net 325 Yakov Rekhter 326 Juniper Networks 327 1194 N. Mathilda Ave. 328 Sunnyvale, CA 94089 329 US 331 EMail: yakov@juniper.net 332 Eric C. Rosen 333 Cisco Systems 334 250 Apollo Drive 335 Chelmsford, MA 01824 336 US 338 EMail: erosen@cisco.com 340 Robert Raszuk 341 Cisco Systems 342 170 West Tasman Dr 343 San Jose, CA 95134 344 US 346 EMail: raszuk@cisco.com 348 Dan Tappan 349 Cisco Systems 350 250 Apollo Drive 351 Chelmsford, MA 01824 352 US 354 EMail: tappan@cisco.com 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 Disclaimer of Validity 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 385 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 386 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 387 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Copyright Statement 392 Copyright (C) The Internet Society (2004). This document is subject 393 to the rights, licenses and restrictions contained in BCP 78, and 394 except as set forth therein, the authors retain all their rights. 396 Acknowledgment 398 Funding for the RFC Editor function is currently provided by the 399 Internet Society.