idnits 2.17.1 draft-ietf-l3vpn-auth-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 421 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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: 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 (February 2003) is 7739 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) == Unused Reference: 'RFC-1771' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Bonica 2 WorldCom 3 Internet Draft Y. Rekhter 4 Expiration Date: August 2003 Juniper Networks 5 R. Raszuk 6 E. Rosen 7 D. Tappan 8 Cisco Systems 9 February 2003 11 CE-to-CE Member Verification for Layer 3 VPNs 13 draft-ietf-l3vpn-auth-00.txt 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of [RFC-2026]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 2. Abstract 36 This document describes a CE-based verification mechanism that PPVPN 37 customers can use to detect security breaches caused by 38 misconfiguration of the provider network. 40 3. Overview 42 Provider Provisioned Virtual Private Networks (PPVPN) support routing 43 privacy among customer interfaces. In order to support routing 44 privacy, Provider Edge (PE) routers maintain multiple forwarding 45 table instances, with each forwarding table instance containing 46 routes for one or more Virtual Private Networks (VPN). Service 47 providers (SP) assign customer interfaces to these VPN specific 48 routing table instances. In doing so, the SP assigns the customer 49 interface to a VPN. 51 The SP assures VPN customers that all VPN traffic will remain within 52 the VPN. Conversely, the SP assures VPN customers that VPN interfaces 53 will never receive datagrams originating outside of the VPN. 55 In order to provide these assurances, the SP must configure its PE 56 routers correctly. If the SP assigns a customer interface to the 57 wrong forwarding table instance, or commits some other configuration 58 error, unauthorized parties might join a VPN, while legitimate VPN 59 members are unaware of the security breach. 61 Therefore, some VPN customers may require a CE-based verification 62 mechanism. VPN customers could use the CE-based verification 63 mechanism to protect themselves against security breaches caused by 64 misconfiguration of the provider network. This document describes 65 such a mechanism. 67 Specifically, this document describes a token-based approach to VPN 68 membership verification. In order to support verification, each VPN 69 site sends the PE router that supports it a token. In many cases, the 70 Customer Edge (CE) router originates the token. In configurations 71 where the SP manages the CE, the customer can designate another 72 device contained by the VPN site as the token originator. 74 Having received a token, the PE joins the VPN site to the VPN. The PE 75 accepts and activates routes to the VPN site and distributes those 76 routes throughout the provider network. The PE router also 77 distributes the token throughout the provider network. All PE's that 78 support the VPN receive the token and relay it to each directly 79 connected customer device that participates in the VPN. Customer 80 devices use the token to verify VPN membership. 82 If a customer device receives a token that it does not recognize, it 83 issues an alarm requesting operator intervention. The customer device 84 may also withdraw from the VPN, neither sending traffic to the VPN 85 nor accepting traffic from it until an operator clears the security 86 condition. 88 Note that the PE will not reveal any tokens to a customer device 89 until it has received a token from the site that the customer device 90 supports. 92 The token-based approach described by this document contains three 93 components. These are: 95 Customer-to-PE signaling 96 PE-to-PE signaling 97 PE-to-Customer signaling 99 This document dedicates a section to each component. 101 4. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC-2119]. 107 5. Motivation 109 Currently, PPVPN customers cannot detect security breaches that are 110 caused by accidental misconfiguration of the SP network. For example, 111 assume that an SP maintains two VPN's. The first VPN supports 112 Customer A while the second VPN supports Customer B. Assume also that 113 Customer B requests an new VPN service connection. The SP processes 114 Customer B's request, but accidentally configures Customer B's new 115 connection into Customer A's VPN. 117 Typically, Customer B is first to detect the problem. Customer B 118 tells the SP that an error has occurred and the SP corrects the 119 error. The SP may or may not tell Customer A that his/her VPN has 120 been breached. 122 The CE-to-CE verification mechanism, described herein, informs both 123 customers of the VPN breach. It provides immediate and automatic 124 notification. It does not prevent the breach or the misconfiguration 125 that caused it. 127 The CE-to-CE verification mechanism does not protect VPN customers 128 from intentional misbehavior on the SP's part. The VPN customer must 129 trust the SP to implement this mechanism faithfully. 131 6. Customer-to-PE Signaling 133 In order to support CE-based verification, each VPN site must send 134 one or more tokens to the PE router that supports it. In many cases, 135 the CE will originate the token. In configurations where the SP 136 manages the CE, the customer may designate another device contained 137 by the VPN site as the token originator. 139 If the device that originates the token also maintains a BGP peering 140 session with the PE, the originating device can piggyback token 141 information on this BGP peering session. Section 7 of this document 142 describes an extended BGP community attribute that supports this 143 purpose. 145 Section 9 of this document describes a new UDP-based protocol that 146 also can be used to propagate tokens from customer equipment to PE. 147 This protocol can be used in any VPN configuration, including the 148 configuration described above. 150 7. PE-to-PE Signaling 152 In order to support CE-based verification, the PE router must not 153 activate routes to destinations that are contained by a directly 154 connected VPN site until it has received a token from the VPN site. 155 When the PE has received a token, it will activate those routes and 156 advertise them to its iBGP peers. (That is, the PE will advertise 157 those routes to remote PE routers that support the VPN.) 159 If the provider network uses BGP to distribute VPN routes among PE 160 routers, it appends the token to each BGP update. To support this 161 purpose, this document defines a new transitive extended community 162 [EXTBGP] called CE-to-CE Verification Token. This community uses the 163 format of the Opaque extended community. 165 The high-order octet of the Type field of the CE-to-CE Authentication 166 Token is 0x03. The low-order octet of the Type field is 0x02. The 6 167 octets of the Value field carries the token itself. 169 If the provider network does not use BGP to distribute VPN routes 170 among PE routers, it can use the UDP-based protocol described in 171 Section 9 of this document to distribute tokens to remote PE routers. 173 8. PE-to-Customer Signaling 175 Previous sections of this document describe how the PE router 176 acquires a token to be associated with each route that is active in 177 its forwarding table. Section 6 describes how the PE acquires tokens 178 from directly connected VPN sites. Section 7 describes how the PE 179 acquires tokens from other PE routers. 181 In order to support CE-based verification, the PE router must relay 182 these tokens to directly connected customer devices. The customer 183 device can be a CE router or a directly connected host. If the PE and 184 customer device maintain a BGP peering session with one another, the 185 PE can use this BGP peering session to send tokens to the CE. Section 186 7 of this document describes a BGP extended community attribute that 187 supports this purpose. 189 Section 9 of this document describes a new UDP-based protocol that 190 also can be used to propagate tokens from PE to customer device. This 191 protocol can be used in any VPN configuration, including the 192 configuration described above. 194 The PE must relay every token that it has acquired regarding a VPN to 195 each directly connected customer device that participates in the VPN. 196 When the PE router receives a new token, it must relay it to the 197 appropriate customer devices immediately. Furthermore, the PE router 198 MUST not reveal any tokens to customer devices that are contained by 199 sites from which a token has not yet been received. 201 9. VPN Token Propagtion Protocol 203 The VPN Token Propagtion Protocol is used to distribute tokens. 204 Figure 1 depicts the format of all messages. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Version | AuType | Token (Octets 1 - 2) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Token (Octets 3-6) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Authentication | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Authentication | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 1 220 The Version field is equal to 1. 222 The Token field contains the verification token. 224 The AuType field indicates how this message should be authenticated. 225 It may contain the following values: 227 No Authentication 0 228 Simple Password 1 229 Message Digest-5 2 231 The Authentication field contains 64 bits of authentication data used 232 to authenticate the message. The AuType field specifies how these 64 233 bits are to be used. 235 The VPN Token Propagtion Protocol establishes soft state between PE 236 and customer device. Announcements expire automatically upon 237 expiration of a configurable timer. Therefore announcements must be 238 repeated periodically. By default, announcements expire in 5 minutes, 239 and should be refreshed every minute. 241 The VPN Token Propagation Protocol obtains transport services from 242 UDP. All VPN Token Propagation Protocol messages are directed to UDP 243 port 3694. 245 10. Configurability 247 SPs can deploy the verification mechanisms described above globally 248 or on a per-VPN basis. In either case, a particular VPN site within 249 the verification domain may not be capable of announcing a token to 250 the PE that supports it. In this case, the SP can configure the PE 251 router so that it will permit that particular VPN site to join the 252 VPN. The PE router will associate a null token (i.e., 0x000000000000) 253 with the VPN site. The PE router will distribute this null token into 254 the VPN as if it had been announced by the VPN site. 256 Although the null token may be useful during migration periods, 257 customer should avoid its long term use. 259 11. Security Considerations 261 If VPN customer receives a token that it does not recognize, the VPN 262 customer should contact his/her SP immediately. The VPN customer 263 should also consider changing its token value, as the SP may have 264 revealed that value to an unauthorized party. 266 12. IANA Considerations 268 IANA will assign a new extended BGP community sub-type, with the 269 high-order octet of the Type field equal to 0x03 and low-order octet 270 equal to 0x02. This BGP extended community type will represent the 271 CE-to-CE Authentication Token. 273 IANA will has assigned UDP port number 3694 to the VPN Token 274 Propagation Protocol, described in Section 9. 276 13. Acknowledgements 278 Thanks to Beth Alwin, Eduard Metz, Richard Morgan, Benson Schliesser 279 and Paul Hoffman for their comments on this draft. 281 14. Normative References 283 [RFC-1771], Rekhter, Y., Li, T., "A Border Gateway Protocol (BGP- 284 4)", RFC 1771, March 1995. 286 [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 287 2026, Harvard University, October 1996. 289 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", RFC 2119, Harvard University, March 1997 292 [EXTBGP], "BGP Extended Communities Attribute", Ramachandra, S., 293 Tappan, D., Rekhter, Y., June 2001, draft-ietf-idr-bgp-ext- 294 communities-02.txt 296 15. Author's Addresses 298 Ronald P. Bonica 299 WorldCom 300 22001 Loudoun County Pkwy 301 Ashburn, Virginia, 20147 302 Phone: 703 886 1681 303 Email: ronald.p.bonica@wcom.com 305 Yakov Rekhter 306 Juniper Networks, Inc. 307 1194 N. Mathilda Ave. 308 Sunnyvale, California 94089 309 Email: yakov@juniper.net 311 Eric C. Rosen 312 Cisco Systems, Inc. 313 250 Apollo Drive 314 Chelmsford, MA, 01824 315 Email: erosen@cisco.com 317 Robert Raszuk 318 Cisco Systems, Inc. 319 250 Apollo Drive 320 Chelmsford, MA, 01824 321 Email: raszuk@cisco.com 323 Dan Tappan 324 Cisco Systems, Inc. 325 250 Apollo Drive 326 Chelmsford, MA 01824 327 Email: tappan@cisco.com 329 16. Full Copyright Statement 331 Copyright (C) The Internet Society (2003). All Rights Reserved. 333 This document and translations of it may be copied and furnished to 334 others, and derivative works that comment on or otherwise explain it 335 or assist in its implementation may be prepared, copied, published 336 and distributed, in whole or in part, without restriction of any 337 kind, provided that the above copyright notice and this paragraph are 338 included on all such copies and derivative works. However, this 339 document itself may not be modified in any way, such as by removing 340 the copyright notice or references to the Internet Society or other 341 Internet organizations, except as needed for the purpose of 342 developing Internet standards in which case the procedures for 343 copyrights defined in the Internet Standards process must be 344 followed, or as required to translate it into languages other than 345 English. 347 The limited permissions granted above are perpetual and will not be 348 revoked by the Internet Society or its successors or assigns. 350 This document and the information contained herein is provided on an 351 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 352 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 353 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 354 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 355 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.