idnits 2.17.1 draft-bonica-l3vpn-auth-03.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 483 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 == Line 269 has weird spacing: '... byte ssh...' == Line 272 has weird spacing: '... string vpn_i...' == Line 273 has weird spacing: '... string inter...' == Line 274 has weird spacing: '... string pe_id...' == 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 magic cookie that it has acquired regarding a VPN to each CE router that participates in the VPN. When the PE router receives a new magic cookie, it must relay it to the appropriate CE routers immediately. Furthermore, the PE router MUST not reveal any magic cookie information to CE routers that are contained by sites from which a magic cookie 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 (June 2002) is 7986 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'SSH-TRAN' is mentioned on line 249, but not defined == Unused Reference: 'RFC-1771' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'SSH-TRANS' is defined on line 352, 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 == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-11 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-11 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 3 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: December 2002 Juniper Networks 5 R. Raszuk 6 E. Rosen 7 D. Tappan 8 Cisco Systems 9 June 2002 11 CE-to-CE Authentication for Layer 3 VPNs 13 draft-bonica-l3vpn-auth-03.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 authentication mechanism that 37 PPVPN 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 representing a 46 Virtual Private Network (VPN). Service providers assign customer 47 interfaces to these VPN specific routing table instances. In doing 48 so, the service provider assigns the customer interface to a VPN. 50 The service provider assures VPN customers that all VPN traffic will 51 remain within the VPN. Conversely, the service provider assures VPN 52 customers that VPN interfaces will never receive datagrams 53 originating outside of the VPN. 55 In order to provide these assurances, the service provider must 56 configure its PE routers correctly. If the service provider assigns a 57 customer interface to the wrong forwarding table instance, or commits 58 some other configuration error, unauthorized parties might join a 59 VPN, while legitimate VPN members are unaware of the security breach. 61 Therefore, some VPN customers may require a CE-based authentication 62 mechanism. VPN customers could use the CE-based authentication 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 magic cookie approach to VPN 68 authentication. In order to support authentication, each VPN site 69 sends the PE router that supports it a magic cookie. In many cases, 70 the Customer Edge (CE) router originates the magic cookie. In 71 configurations where the service provider manages the CE, the 72 customer can designate another device contained by the VPN site as 73 the magic cookie originator. 75 Having received the magic cookie, the PE router sends an 76 authentication request to a server that the customer controls. The 77 query identifies the PE router, VPN, and interface. It also contains 78 the magic cookie. 80 If the authentication server explicitly rejects the authentication 81 request, the PE router terminates the authentication process. 82 Therefore, the PE router will neither accept traffic from the CE nor 83 send traffic to the CE. If the authentication server explicitly 84 accepts the authentication request, cannot be contacted or sends no 85 response at all, the PE router joins the CE to the VPN. At this 86 point, the PE will accept traffic from the CE and forward traffic to 87 the CE. It will also accept routes from the CE and distribute them 88 throughout the provider network. 90 Having proceeded to this phase of the authentication process, the PE 91 router distributes the magic cookie throughout the provider network. 92 All PE's that support the VPN receive the magic cookie and relay it 93 to each attached CE router that participates in the VPN. CE routers 94 use the magic cookie to authenticate their VPN peers. 96 If a CE receives a magic cookie that it cannot authenticate, it 97 issues an alarm requesting operator intervention. The CE may also 98 withdraw from the VPN, neither sending traffic to the VPN nor 99 accepting traffic from the VPN until an operator clears the security 100 condition. 102 Note that the PE will not reveal any magic cookie information to the 103 CE until it has received a magic cookie from the customer site that 104 the CE supports. 106 Note also that the authentication process does not rely upon the 107 availability of an authentication server. In fact, authentication 108 server deployment is optional. Some customers may choose not to 109 deploy an authentication server and rely entirely upon authentication 110 by CE routers. 112 The magic cookie approach described by this document contains four 113 components. These are 1) Customer-to-PE signaling, 2) PE-to- 114 authentication server signaling, 3) PE-to-PE signaling and 4) PE-to- 115 CE signaling. This document dedicates a section to each component. 117 4. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC-2119]. 123 5. Motivation 125 Currently, PPVPN customers cannot detect security breaches that are 126 caused by accidental misconfiguration of the service provider 127 network. For example, assume that a service provider maintains two 128 VPN's. The first VPN supports Customer A while the second VPN 129 supports Customer B. Assume also that Customer B requests an new VPN 130 service connection. The service provider processes Customer B's 131 request, but accidentally configures Customer B's new connection into 132 Customer A's VPN. 134 Typically, Customer B is first to detect the problem. Customer B 135 tells the service provider that an error has occurred and the service 136 provider corrects the error. The service provider may or may not tell 137 Customer A that his/her VPN has been breached. 139 The CE-to-CE authentication mechanism, described herein, informs 140 Customer A of the VPN breach. It provides immediate and automatic 141 notification. 143 Customers who seek to prevent accidental misconfiguration of the 144 provider network should deploy the authentication server described 145 above. Customers who merely require post-hoc notification of 146 accidental misconfiguration need not deploy the authentication 147 server. 149 The CE-to-CE authentication mechanism does not protect VPN customers 150 from intentional misbehavior on the service provider's part. The VPN 151 customer must trust the service provider to implement this mechanism 152 faithfully. 154 6. Customer-to-PE Signaling 156 In order to support CE-based authentication, each VPN site must send 157 one or more magic cookies to the PE router that supports it. In many 158 cases, the CE will originate the magic cookie. In configurations 159 where the service provider manages the CE, the customer may designate 160 another device contained by the VPN site as the magic cookie 161 originator. 163 If the device that originates the magic cookie also maintains a BGP 164 peering session with the PE, the originating device can piggyback 165 magic cookie information on this BGP peering session. Section 8 of 166 this document describes an extended BGP community attribute that 167 supports this purpose. 169 Section 10 of this document describes an ssh-service that also can be 170 used to propagate magic cookies from CE to PE. This ssh-service can 171 be used in any VPN configuration, including the configuration 172 described above. 174 7. PE-to-Authentication Server Signaling 176 Having received the magic cookie, the PE router sends an 177 authentication request to a server that the customer controls. The 178 authentication request identifies the PE router, VPN, and interface. 179 It also contains the magic cookie. 181 If the authentication server explicitly rejects the authentication 182 request, the PE router terminates the authentication process. 183 Therefore, the PE router will neither accept traffic from the CE nor 184 send traffic to the CE. If the authentication server explicitly 185 accepts the authentication request, cannot be contacted or sends no 186 response at all, the PE router joins the CE to the VPN. At this 187 point, the PE will accept traffic from the CE and forward traffic to 188 the CE. It will also accept routes from the CE and distribute them 189 throughout the provider network. 191 Section 10 of this document describes an ssh-service that the PE can 192 use to communicate with the authentication server. The authentication 193 server can also use this ssh-service to send its response to the PE. 195 8. PE-to-PE Signaling 197 In order to support CE-based authentication, the PE router must not 198 activate routes to destinations that are contained by a directly 199 connected VPN site until it has received a magic cookie from the VPN 200 site. When the PE has received a magic cookie and attempted to 201 contact the customer's authentication server, it will activate those 202 routes and advertise them to its iBGP peers. (That is, the PE will 203 advertise those routes to remote PE routers that support the VPN.) 205 If the provider network uses BGP to distribute VPN routes among PE 206 routers, it appends the magic cookie to each BGP update. To support 207 this purpose, this document defines a new transitive extended 208 community [EXTBGP] called CE-to-CE Authentication Token. This 209 community uses the format of the Opaque extended community. 211 The low-order octet of the Type field of the CE-to-CE Authentication 212 Token is TBD (to be assigned by the IANA). The 6 octets of the Value 213 field carries the magic cookie. It must contain an non-zero value. 215 If the provider network does not use BGP to distribute VPN routes 216 among PE routers, it can use the ssh-service described in Section 10 217 of this document to distributed magic cookies to remote PE routers. 219 9. PE-to-CE Signaling 221 Previous sections of this document describe how the PE router 222 acquires a magic cookie to be associated with each route that is 223 active in its forwarding table. Section 6 describes how the PE 224 acquires magic cookies from directly connected VPN sites. Section 8 225 describes how the PE acquires magic cookies from remote VPN sites. 227 In order to support CE-based authentication, the PE router must relay 228 these magic cookies to directly connected CE routers. If the PE and 229 CE routers maintain a BGP peering session with one another, the PE 230 can use this BGP peering session to send magic cookies to the CE. 231 Section 8 of this document describes a BGP extended community 232 attribute that supports this purpose. 234 Section 10 of this document describes an ssh-service that also can be 235 used to propagate magic cookies from PE to CE. This ssh-service can 236 be used in any VPN configuration, including the configuration 237 described above. 239 The PE must relay every magic cookie that it has acquired regarding a 240 VPN to each CE router that participates in the VPN. When the PE 241 router receives a new magic cookie, it must relay it to the 242 appropriate CE routers immediately. Furthermore, the PE router MUST 243 not reveal any magic cookie information to CE routers that are 244 contained by sites from which a magic cookie has not yet been 245 received. 247 10. Cookie Propagation Using SSH 249 VPN devices can use a new ssh-service over [SSH-TRAN] to announce or 250 withdraw magic cookies. Specifically, the new ssh-service supports 251 the following classes of cookie announcement and withdrawal: 253 from CE to PE 254 from PE to authentication server 255 from PE to PE 256 from PE to CE 258 When the PE uses the new ssh-service to announce a magic cookie to 259 the authentication server, the PE waits for the authentication device 260 to accept or reject the magic cookie. The PE terminates the 261 authentication process only if the authentication device explicitly 262 rejects the cookie. 264 When the SSH connection terminates, all magic cookies that were 265 distributed through it are withdrawn implicitly. 267 The following SSH message will support this service: 269 byte ssh_cookie_exchange 270 uint32 action 271 uint64 cookie 272 string vpn_identifier 273 string interface_identifier 274 string pe_identifier 276 The following actions are defined: 278 #define SSH_COOKIE_EXCHANGE_ANNOUNCE 1 279 #define SSH_COOKIE_EXCHANGE_WITHDRAW 2 280 #define SSH_COOKIE_EXCHANGE_ACCEPT 3 281 #define SSH_COOKIE_EXCHANGE_REJECT 4 283 The first 48 bits of the "cookie" field represent the magic cookie. 284 The remaining 16 bits are set to zero. 286 IANA will assign a number to the message described above [SSH-ARCH]. 287 This number will be drawn from the range that is dedicated to client 288 protocols (i.e., 128-191). If this ssh-service is being used to 289 transfer magic cookies from PE to CE, and the PE maintains at least 290 one VPN route with which no magic cookie is associated, the PE MUST 291 announce a null magic cookie (i.e., value 0x000000000000). 293 11. Configurability 295 Service providers can deploy the authentication mechanisms described 296 above globally or on a per-VPN basis. In either case, a particular 297 VPN site within the authentication domain may not be capable of 298 announcing a magic cookie to the PE that supports it. In this case, 299 the service provider can configure the PE router so that it will 300 permit that particular CE router to join the authentication enabled 301 VPN. The PE router will associate a null cookie (value 302 0x000000000000) with the VPN site that the CE supports. The PE route 303 distribute this null cookie into the VPN as if it had been announced 304 by the CE device. 306 12. Security Considerations 308 If VPN customer receives a magic cookie that it cannot authenticate, 309 the VPN customer should contact his/her service provider immediately. 310 The VPN customer should also consider changing its magic cookie 311 value, as the service provider may have revealed that value to an 312 unauthorized party. 314 If the VPN customer maintains backdoor interfaces outside of the VPN, 315 the VPN customer MUST ensure that parties outside of the VPN cannot 316 sends signaling traffic to PE-CE interfaces. 318 13. IANA Considerations 320 IANA will assign a new extended BGP community sub-type, with the 321 high-order octet of the Type field equal to 0x03. This BGP extended 322 community type will represent the CE-to-CE Authentication Token. 324 IANA will assign a number to the SSH message described in Section 10. 325 This number will be drawn from the range that is dedicated to client 326 protocols (i.e., 128-191). 328 14. Acknowledgements 330 Thanks to Beth Alwin, Eduard Metz, Richard Morgan and Benson 331 Schliesser for their comments on this draft. 333 15. Normative References 335 [RFC-1771], Rekhter, Y., Li, T., "A Border Gateway Protocol (BGP- 336 4)", RFC 1771, March 1995. 338 [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 339 2026, Harvard University, October 1996. 341 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", RFC 2119, Harvard University, March 1997 344 [EXTBGP], "BGP Extended Communities Attribute", Ramachandra, S., 345 Tappan, D., Rekhter, Y., June 2001, draft-ietf-idr-bgp-ext- 346 communities-02.txt 348 [SSH-ARCH], "SSH Protocol Architecture", Ylonen, T., Kivinen, T., 349 Saarinen, M., Rinne, T., Lehtinen, S., November 19, 2001, draft- 350 ietf-secsh-architecture-11.txt 352 [SSH-TRANS], "SSH Transport Layer Protocol", Ylonen, T., Kivinen, T., 353 Saarinen, M., Ri nne, T., Lehtinen, S., November 19, 2001, draft- 354 ietf-secsh-transport-11.txt 356 16. Author's Addresses 358 Ronald P. Bonica 359 WorldCom 360 22001 Loudoun County Pkwy 361 Ashburn, Virginia, 20147 362 Phone: 703 886 1681 363 Email: ronald.p.bonica@wcom.com 365 Yakov Rekhter 366 Juniper Networks, Inc. 367 1194 N. Mathilda Ave. 368 Sunnyvale, California 94089 369 Email: yakov@juniper.net 371 Eric C. Rosen 372 Cisco Systems, Inc. 373 250 Apollo Drive 374 Chelmsford, MA, 01824 375 Email: erosen@cisco.com 377 Robert Raszuk 378 Cisco Systems, Inc. 379 250 Apollo Drive 380 Chelmsford, MA, 01824 381 Email: raszuk@cisco.com 383 Dan Tappan 384 Cisco Systems, Inc. 385 250 Apollo Drive 386 Chelmsford, MA 01824 387 Email: tappan@cisco.com 389 17. Full Copyright Statement 391 Copyright (C) The Internet Society (2000). All Rights Reserved. 393 This document and translations of it may be copied and furnished to 394 others, and derivative works that comment on or otherwise explain it 395 or assist in its implementation may be prepared, copied, published 396 and distributed, in whole or in part, without restriction of any 397 kind, provided that the above copyright notice and this paragraph are 398 included on all such copies and derivative works. However, this 399 document itself may not be modified in any way, such as by removing 400 the copyright notice or references to the Internet Society or other 401 Internet organizations, except as needed for the purpose of 402 developing Internet standards in which case the procedures for 403 copyrights defined in the Internet Standards process must be 404 followed, or as required to translate it into languages other than 405 English. 407 The limited permissions granted above are perpetual and will not be 408 revoked by the Internet Society or its successors or assigns. 410 This document and the information contained herein is provided on an 411 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 412 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 413 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 414 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 415 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.