R. Bonica
                                                               WorldCom
Internet Draft                                               Y. Rekhter
Expiration Date: May 2002                              Juniper Networks
                                                              R. Raszuk
                                                               E. Rosen
                                                              D. Tappan
                                                          Cisco Systems
                                                          November 2001

               CE-to-CE Authentication for RFC 2547 VPNs

                    draft-bonica-l3vpn-auth-01.txt


. 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.


. Abstract

   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.  Only after the
   PE has received the magic cookie will it accept traffic from the
   customer interface that supports the VPN site.

   In many cases, the Customer Edge (CE) router originates the magic
   cookie. In configurations where the service provider manages the CE,
   the customer may designate another device contained by the VPN site
   to originate the magic cookie.

   Having received the magic cookie, the PE router distributes it
   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.


. Overview

   RFC 2547 VPNs [2547bis] 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 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 that
   originated 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 from 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.  Only after the
   PE has received the magic cookie will it accept traffic from the
   customer interface that supports the VPN site.

   In many cases, the Customer Edge (CE) router originates the magic
   cookie. In configurations where the service provider manages the CE,
   the customer may designate another device contained by the VPN site
   to originate the magic cookie.

   Having received the magic cookie, the PE router distributes it
   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 accept any traffic from a VPN site until it
   has received a magic cookie from that VPN site. Furthermore, the PE
   will not distribute any VPN routes representing a VPN site until it
   has received a magic cookie from that VPN site.

   Note also 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.

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


. 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].



. 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 to originate the magic
   cookie.

   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 6 of
   this document describes an extended BGP community attribute that
   supports this purpose.

   Section 8 of this document specifies an alternative protocol that can
   be used to propagate magic cookies. This protocol can be used in any
   VPN configuration, including the configuration mentioned above.


. 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, 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.) As
   the PE advertises those routes, it appends the magic cookie to each
   BGP update.

   To support this purpose, this document defines a new extended
   community attribute type, called CE-to-CE Authentication Token. The
   extended community attribute [EXTBGP] is data structure that contains
   eight octets. The first two octets represent a community type and the
   remaining six octets represent a value.

   The high-order octet of the Type field is set to 0x03. The low-order
   octet of the Type field is TBD (to be assigned by the IANA).  The
   Value field carries the magic cookie.

   This extended community will be transitive and optional.




. 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 5 describes how the PE
   acquires magic cookies to be associated with routes to destinations
   that are contained by directly connected VPN sites. Section 6
   describes how the PE acuires magic cookies to be associated with
   routes to destinations that are contained by 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 6 of this document describes a BGP extended community
   attribute that supports this purpose.

   Section 8 of this document describes an alternative protocol that the
   PE can use to send magic cookies to the CE. This protocol can be used
   in any VPN configuration, including the configuration mentioned
   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 CE
   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.


. Protocol Support

   This section describes a protocol that PE and CE routers use to
   exchange magic cookies with one another. The protocol can obtain
   transport services from TCP or SSH. IANA will assign a TCP port to
   support this protocol.

   The protocol supports the following message types:

      UPDATE
      KEEPALIVE

   The format of these messages is TBD.

   Protocol partners exchange magic cookie information using the UPDATE
   message.

   Protocol partners must send each other KEEPALIVE messages every 90
   seconds. Having missed four consecutive KEEPALIVE messages, the
   protocol partner will reset the peering session.

   When the peering session terminates, all magic cookies that were
   distributed through the peering session are withdrawn.





. 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.


. 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 also assign a TCP port to support the CE-based-
   Authentication Protocol.


. Acknowledgements

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


. References

   [2547bis], Rosen, E. et al., "BGP/MPLS VPSs", July, 2001, draft-
   ietf-ppvpn-rfc2547bis-00.

   [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














. 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




. 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.