[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
                                                              R. Bonica
                                                               WorldCom
Internet Draft                                               Y. Rekhter
Expiration Date: December 2002                         Juniper Networks
                                                              R. Raszuk
                                                               E. Rosen
                                                              D. Tappan
                                                          Cisco Systems
                                                              June 2002

               CE-to-CE Authentication for Layer 3 VPNs

                    draft-bonica-l3vpn-auth-03.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC-2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


2. Abstract

   This document describes a CE-based authentication mechanism that
   PPVPN customers can use to detect security breaches caused by
   misconfiguration of the provider network.


3. Overview

   Provider Provisioned Virtual Private Networks (PPVPN) support routing
   privacy among customer interfaces. In order to support routing
   privacy, Provider Edge (PE) routers maintain multiple forwarding
   table instances, with each forwarding table instance representing a
   Virtual Private Network (VPN). Service providers assign customer
   interfaces to these VPN specific routing table instances. In doing
   so, the service provider assigns the customer interface to a VPN.

   The service provider assures VPN customers that all VPN traffic will
   remain within the VPN. Conversely, the service provider assures VPN
   customers that VPN interfaces will never receive datagrams
   originating outside of the VPN.

   In order to provide these assurances, the service provider must
   configure its PE routers correctly. If the service provider assigns a
   customer interface to the wrong forwarding table instance, or commits
   some other configuration error, unauthorized parties might join a
   VPN, while legitimate VPN members are unaware of the security breach.

   Therefore, some VPN customers may require a CE-based authentication
   mechanism. VPN customers could use the CE-based authentication
   mechanism to protect themselves against security breaches caused by
   misconfiguration of the provider network. This document describes
   such a mechanism.

   Specifically, this document describes a magic cookie approach to VPN
   authentication. In order to support authentication, each VPN site
   sends the PE router that supports it a magic cookie. In many cases,
   the Customer Edge (CE) router originates the magic cookie. In
   configurations where the service provider manages the CE, the
   customer can designate another device contained by the VPN site as
   the magic cookie originator.

   Having received the magic cookie, the PE router sends an
   authentication request to a server that the customer controls. The
   query identifies the PE router, VPN, and interface. It also contains
   the magic cookie.

   If the authentication server explicitly rejects the authentication
   request, the PE router terminates the authentication process.
   Therefore, the PE router will neither accept traffic from the CE nor
   send traffic to the CE. If the authentication server explicitly
   accepts the authentication request, cannot be contacted or sends no
   response at all, the PE router joins the CE to the VPN. At this
   point, the PE will accept traffic from the CE and forward traffic to
   the CE. It will also accept routes from the CE and distribute them
   throughout the provider network.

   Having proceeded to this phase of the authentication process, the PE
   router distributes the magic cookie throughout the provider network.
   All PE's that support the VPN receive the magic cookie and relay it
   to each attached CE router that participates in the VPN. CE routers
   use the magic cookie to authenticate their VPN peers.

   If a CE receives a magic cookie that it cannot authenticate, it
   issues an alarm requesting operator intervention. The CE may also
   withdraw from the VPN, neither sending traffic to the VPN nor
   accepting traffic from the VPN until an operator clears the security
   condition.

   Note that the PE will not reveal any magic cookie information to the
   CE until it has received a magic cookie from the customer site that
   the CE supports.

   Note also that the authentication process does not rely upon the
   availability of an authentication server. In fact, authentication
   server deployment is optional. Some customers may choose not to
   deploy an authentication server and rely entirely upon authentication
   by CE routers.

   The magic cookie approach described by this document contains four
   components. These are 1) Customer-to-PE signaling, 2) PE-to-
   authentication server signaling, 3) PE-to-PE signaling and 4) PE-to-
   CE signaling. This document dedicates a section to each component.


4. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].


5. Motivation

   Currently, PPVPN customers cannot detect security breaches that are
   caused by accidental misconfiguration of the service provider
   network. For example, assume that a service provider maintains two
   VPN's. The first VPN supports Customer A while the second VPN
   supports Customer B. Assume also that Customer B requests an new VPN
   service connection.  The service provider processes Customer B's
   request, but accidentally configures Customer B's new connection into
   Customer A's VPN.

   Typically, Customer B is first to detect the problem. Customer B
   tells the service provider that an error has occurred and the service
   provider corrects the error. The service provider may or may not tell
   Customer A that his/her VPN has been breached.

   The CE-to-CE authentication mechanism, described herein, informs
   Customer A of the VPN breach. It provides immediate and automatic
   notification.

   Customers who seek to prevent accidental misconfiguration of the
   provider network should deploy the authentication server described
   above. Customers who merely require post-hoc notification of
   accidental misconfiguration need not deploy the authentication
   server.

   The CE-to-CE authentication mechanism does not protect VPN customers
   from intentional misbehavior on the service provider's part. The VPN
   customer must trust the service provider to implement this mechanism
   faithfully.


6. Customer-to-PE Signaling

   In order to support CE-based authentication, each VPN site must send
   one or more magic cookies to the PE router that supports it. In many
   cases, the CE will originate the magic cookie. In configurations
   where the service provider manages the CE, the customer may designate
   another device contained by the VPN site as the magic cookie
   originator.

   If the device that originates the magic cookie also maintains a BGP
   peering session with the PE, the originating device can piggyback
   magic cookie information on this BGP peering session. Section 8 of
   this document describes an extended BGP community attribute that
   supports this purpose.

   Section 10 of this document describes an ssh-service that also can be
   used to propagate magic cookies from CE to PE. This ssh-service can
   be used in any VPN configuration, including the configuration
   described above.


7. PE-to-Authentication Server Signaling

   Having received the magic cookie, the PE router sends an
   authentication request to a server that the customer controls. The
   authentication request identifies the PE router, VPN, and interface.
   It also contains the magic cookie.

   If the authentication server explicitly rejects the authentication
   request, the PE router terminates the authentication process.
   Therefore, the PE router will neither accept traffic from the CE nor
   send traffic to the CE. If the authentication server explicitly
   accepts the authentication request, cannot be contacted or sends no
   response at all, the PE router joins the CE to the VPN. At this
   point, the PE will accept traffic from the CE and forward traffic to
   the CE. It will also accept routes from the CE and distribute them
   throughout the provider network.

   Section 10 of this document describes an ssh-service that the PE can
   use to communicate with the authentication server. The authentication
   server can also use this ssh-service to send its response to the PE.


8. PE-to-PE Signaling

   In order to support CE-based authentication, the PE router must not
   activate routes to destinations that are contained by a directly
   connected VPN site until it has received a magic cookie from the VPN
   site. When the PE has received a magic cookie and attempted to
   contact the customer's authentication server, it will activate those
   routes and advertise them to its iBGP peers. (That is, the PE will
   advertise those routes to remote PE routers that support the VPN.)

   If the provider network uses BGP to distribute VPN routes among PE
   routers, it appends the magic cookie to each BGP update. To support
   this purpose, this document defines a new transitive extended
   community [EXTBGP] called CE-to-CE Authentication Token.  This
   community uses the format of the Opaque extended community.

   The low-order octet of the Type field of the CE-to-CE Authentication
   Token is TBD (to be assigned by the IANA). The 6 octets of the Value
   field carries the magic cookie. It must contain an non-zero value.

   If the provider network does not use BGP to distribute VPN routes
   among PE routers, it can use the ssh-service described in Section 10
   of this document to distributed magic cookies to remote PE routers.


9. PE-to-CE Signaling

   Previous sections of this document describe how the PE router
   acquires a magic cookie to be associated with each route that is
   active in its forwarding table. Section 6 describes how the PE
   acquires magic cookies from directly connected VPN sites. Section 8
   describes how the PE acquires magic cookies from remote VPN sites.

   In order to support CE-based authentication, the PE router must relay
   these magic cookies to directly connected CE routers. If the PE and
   CE routers maintain a BGP peering session with one another, the PE
   can use this BGP peering session to send magic cookies to the CE.
   Section 8 of this document describes a BGP extended community
   attribute that supports this purpose.

   Section 10 of this document describes an ssh-service that also can be
   used to propagate magic cookies from PE to CE. This ssh-service can
   be used in any VPN configuration, including the configuration
   described above.

   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.


10. Cookie Propagation Using SSH

   VPN devices can use a new ssh-service over [SSH-TRAN] to announce or
   withdraw magic cookies. Specifically, the new ssh-service supports
   the following classes of cookie announcement and withdrawal:

      from CE to PE
      from PE to authentication server
      from PE to PE
      from PE to CE

   When the PE uses the new ssh-service to announce a magic cookie to
   the authentication server, the PE waits for the authentication device
   to accept or reject the magic cookie. The PE terminates the
   authentication process only if the authentication device explicitly
   rejects the cookie.

   When the SSH connection terminates, all magic cookies that were
   distributed through it are withdrawn implicitly.

   The following SSH message will support this service:

      byte    ssh_cookie_exchange
      uint32  action
      uint64  cookie
      string  vpn_identifier
      string  interface_identifier
      string  pe_identifier

   The following actions are defined:

      #define SSH_COOKIE_EXCHANGE_ANNOUNCE 1
      #define SSH_COOKIE_EXCHANGE_WITHDRAW 2
      #define SSH_COOKIE_EXCHANGE_ACCEPT   3
      #define SSH_COOKIE_EXCHANGE_REJECT   4

   The first 48 bits of the "cookie" field represent the magic cookie.
   The remaining 16 bits are set to zero.

   IANA will assign a number to the message described above [SSH-ARCH].
   This number will be drawn from the range that is dedicated to client
   protocols (i.e., 128-191). If this ssh-service is being used to
   transfer magic cookies from PE to CE, and the PE maintains at least
   one VPN route with which no magic cookie is associated, the PE MUST
   announce a null magic cookie (i.e., value 0x000000000000).


11. Configurability

   Service providers can deploy the authentication mechanisms described
   above globally or on a per-VPN basis. In either case, a particular
   VPN site within the authentication domain may not be capable of
   announcing a magic cookie to the PE that supports it. In this case,
   the service provider can configure the PE router so that it will
   permit that particular CE router to join the authentication enabled
   VPN. The PE router will associate a null cookie (value
   0x000000000000) with the VPN site that the CE supports. The PE route
   distribute this null cookie into the VPN as if it had been announced
   by the CE device.


12. Security Considerations

   If VPN customer receives a magic cookie that it cannot authenticate,
   the VPN customer should contact his/her service provider immediately.
   The VPN customer should also consider changing its magic cookie
   value, as the service provider may have revealed that value to an
   unauthorized party.

   If the VPN customer maintains backdoor interfaces outside of the VPN,
   the VPN customer MUST ensure that parties outside of the VPN cannot
   sends signaling traffic to PE-CE interfaces.


13. IANA Considerations

   IANA will assign a new extended BGP community sub-type, with the
   high-order octet of the Type field equal to 0x03.  This BGP extended
   community type will represent the CE-to-CE Authentication Token.


   IANA will assign a number to the SSH message described in Section 10.
   This number will be drawn from the range that is dedicated to client
   protocols (i.e., 128-191).


14. Acknowledgements

   Thanks to Beth Alwin, Eduard Metz, Richard Morgan and Benson
   Schliesser for their comments on this draft.


15. Normative References

   [RFC-1771], Rekhter, Y., Li, T., "A Border Gateway Protocol (BGP-
   4)", RFC 1771, March 1995.

   [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC
   2026, Harvard University, October 1996.

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, March 1997

   [EXTBGP], "BGP Extended Communities Attribute", Ramachandra, S.,
   Tappan, D., Rekhter, Y., June 2001, draft-ietf-idr-bgp-ext-
   communities-02.txt

   [SSH-ARCH], "SSH Protocol Architecture", Ylonen, T., Kivinen, T.,
   Saarinen, M., Rinne, T., Lehtinen, S., November 19, 2001, draft-
   ietf-secsh-architecture-11.txt

   [SSH-TRANS], "SSH Transport Layer Protocol", Ylonen, T., Kivinen, T.,
   Saarinen, M., Ri nne, T., Lehtinen, S., November 19, 2001, draft-
   ietf-secsh-transport-11.txt


16. Author's Addresses

      Ronald P. Bonica
      WorldCom
      22001 Loudoun County Pkwy
      Ashburn, Virginia, 20147
      Phone: 703 886 1681
      Email: ronald.p.bonica@wcom.com

      Yakov Rekhter
      Juniper Networks, Inc.
      1194 N. Mathilda Ave.
      Sunnyvale, California 94089
      Email: yakov@juniper.net

      Eric C. Rosen
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA, 01824
      Email: erosen@cisco.com

      Robert Raszuk
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA, 01824
      Email: raszuk@cisco.com

      Dan Tappan
      Cisco Systems, Inc.
      250 Apollo Drive
      Chelmsford, MA 01824
      Email: tappan@cisco.com




17. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.