[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bonica-l3vpn-auth) 00

                                                              R. Bonica
                                                               WorldCom
Internet Draft                                               Y. Rekhter
Expiration Date: August 2003                           Juniper Networks
                                                              R. Raszuk
                                                               E. Rosen
                                                              D. Tappan
                                                          Cisco Systems
                                                          February 2003

             CE-to-CE Member Verification for Layer 3 VPNs

                  draft-ietf-l3vpn-auth-00.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 verification 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 containing
   routes for one or more Virtual Private Networks (VPN). Service
   providers (SP) assign customer interfaces to these VPN specific
   routing table instances. In doing so, the SP assigns the customer
   interface to a VPN.

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

   In order to provide these assurances, the SP must configure its PE
   routers correctly. If the SP 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 verification
   mechanism. VPN customers could use the CE-based verification
   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 token-based approach to VPN
   membership verification. In order to support verification, each VPN
   site sends the PE router that supports it a token. In many cases, the
   Customer Edge (CE) router originates the token. In configurations
   where the SP manages the CE, the customer can designate another
   device contained by the VPN site as the token originator.

   Having received a token, the PE joins the VPN site to the VPN. The PE
   accepts and activates routes to the VPN site and distributes those
   routes throughout the provider network.  The PE router also
   distributes the token throughout the provider network. All PE's that
   support the VPN receive the token and relay it to each directly
   connected customer device that participates in the VPN. Customer
   devices use the token to verify VPN membership.

   If a customer device receives a token that it does not recognize, it
   issues an alarm requesting operator intervention. The customer device
   may also withdraw from the VPN, neither sending traffic to the VPN
   nor accepting traffic from it until an operator clears the security
   condition.

   Note that the PE will not reveal any tokens to a customer device
   until it has received a token from the site that the customer device
   supports.

   The token-based approach described by this document contains three
   components. These are:

      Customer-to-PE signaling
      PE-to-PE signaling
      PE-to-Customer 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 SP network. For example,
   assume that an SP 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 SP 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 SP that an error has occurred and the SP corrects the
   error. The SP may or may not tell Customer A that his/her VPN has
   been breached.

   The CE-to-CE verification mechanism, described herein, informs both
   customers of the VPN breach. It provides immediate and automatic
   notification. It does not prevent the breach or the misconfiguration
   that caused it.

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


6. Customer-to-PE Signaling

   In order to support CE-based verification, each VPN site must send
   one or more tokens to the PE router that supports it. In many cases,
   the CE will originate the token. In configurations where the SP
   manages the CE, the customer may designate another device contained
   by the VPN site as the token originator.

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

   Section 9 of this document describes a new UDP-based protocol that
   also can be used to propagate tokens from customer equipment to PE.
   This protocol can be used in any VPN configuration, including the
   configuration described above.


7. PE-to-PE Signaling

   In order to support CE-based verification, the PE router must not
   activate routes to destinations that are contained by a directly
   connected VPN site until it has received a token from the VPN site.
   When the PE has received a token, 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 token to each BGP update. To support this
   purpose, this document defines a new transitive extended community
   [EXTBGP] called CE-to-CE Verification Token.  This community uses the
   format of the Opaque extended community.

   The high-order octet of the Type field of the CE-to-CE Authentication
   Token is 0x03. The low-order octet of the Type field is 0x02. The 6
   octets of the Value field carries the token itself.

   If the provider network does not use BGP to distribute VPN routes
   among PE routers, it can use the UDP-based protocol described in
   Section 9 of this document to distribute tokens to remote PE routers.


8. PE-to-Customer Signaling

   Previous sections of this document describe how the PE router
   acquires a token to be associated with each route that is active in
   its forwarding table. Section 6 describes how the PE acquires tokens
   from directly connected VPN sites. Section 7 describes how the PE
   acquires tokens from other PE routers.

   In order to support CE-based verification, the PE router must relay
   these tokens to directly connected customer devices. The customer
   device can be a CE router or a directly connected host. If the PE and
   customer device maintain a BGP peering session with one another, the
   PE can use this BGP peering session to send tokens to the CE. Section
   7 of this document describes a BGP extended community attribute that
   supports this purpose.

   Section 9 of this document describes a new UDP-based protocol that
   also can be used to propagate tokens from PE to customer device. This
   protocol can be used in any VPN configuration, including the
   configuration described above.

   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.


9. VPN Token Propagtion Protocol

   The VPN Token Propagtion Protocol is used to distribute tokens.
   Figure 1 depicts the format of all messages.

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |     AuType    |    Token (Octets 1 - 2)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Token (Octets 3-6)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Authentication                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Authentication                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 1


   The Version field is equal to 1.

   The Token field contains the verification token.

   The AuType field indicates how this message should be authenticated.
   It may contain the following values:

      No Authentication 0
      Simple Password   1
      Message Digest-5  2

   The Authentication field contains 64 bits of authentication data used
   to authenticate the message. The AuType field specifies how these 64
   bits are to be used.

   The VPN Token Propagtion Protocol establishes soft state between PE
   and customer device. Announcements expire automatically upon
   expiration of a configurable timer. Therefore announcements must be
   repeated periodically. By default, announcements expire in 5 minutes,
   and should be refreshed every minute.

   The VPN Token Propagation Protocol obtains transport services from
   UDP. All VPN Token Propagation Protocol messages are directed to UDP
   port 3694.



10. Configurability

   SPs can deploy the verification mechanisms described above globally
   or on a per-VPN basis. In either case, a particular VPN site within
   the verification domain may not be capable of announcing a token to
   the PE that supports it. In this case, the SP can configure the PE
   router so that it will permit that particular VPN site to join the
   VPN. The PE router will associate a null token (i.e., 0x000000000000)
   with the VPN site. The PE router will distribute this null token into
   the VPN as if it had been announced by the VPN site.

   Although the null token may be useful during migration periods,
   customer should avoid its long term use.


11. Security Considerations

   If VPN customer receives a token that it does not recognize, the VPN
   customer should contact his/her SP immediately. The VPN customer
   should also consider changing its token value, as the SP may have
   revealed that value to an unauthorized party.














12. IANA Considerations

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

   IANA will has assigned UDP port number 3694 to the VPN Token
   Propagation Protocol, described in Section 9.


13. Acknowledgements

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


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



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




16. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/