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

Versions: 00 01                                                         
L3VPN Working Group                                            R. Bonica
Internet-Draft                                                Y. Rekhter
Expires: June 1, 2005                                   Juniper Networks
                                                                E. Rosen
                                                               R. Raszuk
                                                               D. Tappan
                                                           Cisco Systems
                                                           December 2004

             CE-to-CE Member Verification for Layer 3 VPNs
                    draft-ietf-l3vpn-l3vpn-auth-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on June 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

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


Bonica, et al.            Expires June 1, 2005                  [Page 1]


Internet-Draft              CE Verification                December 2004

Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Customer-to-PE Signaling . . . . . . . . . . . . . . . . . . .  7
   5.  PE-to-PE Signaling . . . . . . . . . . . . . . . . . . . . . .  8
   6.  PE-to-Customer Signaling . . . . . . . . . . . . . . . . . . .  9
   7.  VPN Token Propagation Protocol . . . . . . . . . . . . . . . . 10
   8.  Configurability  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 13
   11.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
   12.   Normative References . . . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16


















Bonica, et al.            Expires June 1, 2005                  [Page 2]


Internet-Draft              CE Verification                December 2004

1.   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 RFC2119 [3].























Bonica, et al.            Expires June 1, 2005                  [Page 3]


Internet-Draft              CE Verification                December 2004

2.  Overview

   When properly configured, a Layer 3 Virtual Private Network (L3VPN)
   permits communications within a VPN, but prevents communication
   across VPN boundaries.  In order to maintain this posture, the
   Service Provider must configure its network correctly.  If the SP
   assigns a customer interface to the wrong VPN, 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 mechanism for
   VPN membership verification.  VPN customers could use the mechanism
   to detect security breaches caused by misconfiguration of the
   provider network.

   This document describes a token-based approach to VPN membership
   verification.  In order to join a VPN, each VPN site sends a token to
   the Provider Edge (PE) router to which it is attached.  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
   routers 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 membership of the newly
   joined VPN site.

   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:




Bonica, et al.            Expires June 1, 2005                  [Page 4]


Internet-Draft              CE Verification                December 2004

      Customer-to-PE signaling
      PE-to-PE signaling
      PE-to-Customer signaling

   This document dedicates a section to each component.























Bonica, et al.            Expires June 1, 2005                  [Page 5]


Internet-Draft              CE Verification                December 2004

3.  Motivation

   Currently, L3VPN 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 a 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, providing 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.














Bonica, et al.            Expires June 1, 2005                  [Page 6]


Internet-Draft              CE Verification                December 2004

4.  Customer-to-PE Signaling

   In order to join a VPN, each VPN site sends a token to the PE router
   to which it is attached.  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 [1]
   peering session with the PE, the originating device can append 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 device that originates the token does not maintain a BGP
   peering session with the PE, the VPN site can use new protocol
   described in Section 7 of this document to send tokens to the PE.
   This protocol can be used in any VPN configuration, regardless of
   whether the originating device maintains a BGP peering session with
   the PE.













Bonica, et al.            Expires June 1, 2005                  [Page 7]


Internet-Draft              CE Verification                December 2004

5.  PE-to-PE Signaling

   In order to support CE-based verification, the PE router MUST not
   activate routes to a directly connected VPN site until it has
   received a token from that site.  When the PE has received a token,
   it activates those routes and advertise them to its iBGP peers.
   (That is, the PE advertises 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.  Section 4 of this
   document describes a BGP extended community attribute that supports
   this purpose.

   If the provider network does not use BGP to distribute VPN routes
   among PE routers, it can use the new protocol described in Section 7
   of this document to distribute tokens among PE routers.

















Bonica, et al.            Expires June 1, 2005                  [Page 8]


Internet-Draft              CE Verification                December 2004

6.  PE-to-Customer Signaling

   In order to support CE-based verification, the PE router MUST relay
   tokens that it receives from other PE routers 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 customer device.  Section 4 of this
   document describes a BGP extended community attribute that supports
   this purpose.

   Section 7 of this document describes a new protocol that also can be
   used to propagate tokens from PE to customer device.  This protocol
   can be used in any VPN configuration, regardless of whether the
   customer device maintains a BGP peering session with the PE.

   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.















Bonica, et al.            Expires June 1, 2005                  [Page 9]


Internet-Draft              CE Verification                December 2004

7.  VPN Token Propagation Protocol

   The VPN Token Propagation 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

                           Figure 1: message

   The Version field is equal to 1.

   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 Token field contains the verification token.

   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 Propagation 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 30
   minutes, and should be refreshed 10 minutes.

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



Bonica, et al.            Expires June 1, 2005                 [Page 10]


Internet-Draft              CE Verification                December 2004

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



















Bonica, et al.            Expires June 1, 2005                 [Page 11]


Internet-Draft              CE Verification                December 2004

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























Bonica, et al.            Expires June 1, 2005                 [Page 12]


Internet-Draft              CE Verification                December 2004

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





















Bonica, et al.            Expires June 1, 2005                 [Page 13]


Internet-Draft              CE Verification                December 2004

11.  Acknowledgements

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

12  Normative References

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

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities
        Attribute", draft-ietf-idr-bgp-ext-communities-07 (work in
        progress), March 2004.

Authors' Addresses

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Phone: +1 571 203 1704
   EMail: rbonica@juniper.net

   Yakov Rekhter
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   EMail: yakov@juniper.net






Bonica, et al.            Expires June 1, 2005                 [Page 14]


Internet-Draft              CE Verification                December 2004

   Eric C. Rosen
   Cisco Systems
   250 Apollo Drive
   Chelmsford, MA  01824
   US

   EMail: erosen@cisco.com

   Robert Raszuk
   Cisco Systems
   170 West Tasman Dr
   San Jose, CA  95134
   US

   EMail: raszuk@cisco.com

   Dan Tappan
   Cisco Systems
   250 Apollo Drive
   Chelmsford, MA  01824
   US

   EMail: tappan@cisco.com













Bonica, et al.            Expires June 1, 2005                 [Page 15]


Internet-Draft              CE Verification                December 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


Bonica, et al.            Expires June 1, 2005                 [Page 16]