[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

                                                           Jim Guichard
                                                           Robert Hanzl
                                                             Dan Tappan
                                                          Scott Wainner
                                                     Cisco Systems, Inc

                                                           Vic Locicero
                                           INFONET Services Corporation



IETF Internet Draft
Expires: November, 2003
Document: draft-guichard-ce-ce-ipsec-00.txt                   May, 2003



                 CE-CE IPSec within an RFC-2547 Network


Status of this Memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026. 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 reference architecture that may be used to
  tightly integrate CE-CE [IPSec] encryption with the any-to-any
  connectivity model of [RFC2547]. Using this mechanism, a Service
  Provider is able to provide an IP VPN service with data encryption
  between customer edge routers, but without the need of direct routing
  protocol exchange, or IP-based tunnels such as provided by [GRE].


1  Conventions used in this document



Guichard, et. al                                                     1






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


1.1 Terminology

  Several terms used within this document are defined as follows:

  "Security Gateway" - A router that is a member of a [RFC2547] VPN and
  serves as a termination point for [IKE] and [IPSec] Security
  Associations

  "Security Gateway Identity" - An IPv4 address representing the
  identity of a router serving as an security gateway for the
  establishment of [IKE] and [IPSec] Security Associations

  "Trusted Subnet" - A range of IP addresses represented as a network
  and mask that a security gateway protects

  "Security Policy" - A set of policies and attributes used to protect
  information as described in [IKE]


2  Introduction

  [RFC2547] provides an attractive service architecture that is able to
  build an any-to-any data path between VPN sites. However, this model
  does not provide any inherent data encryption services; therefore,
  customers that wish to encrypt their traffic must do so before it
  enters the [RFC2547] network. This is typically achieved by enabling
  [IPSec] encryption and running [IPSec] tunnels between CE routers
  that belong to the "encrypted" VPN.

  The deployment of [IPSec] tunnel meshes is analogous to the "overlay"
  model used in Frame-relay or ATM networks. One of the key success
  drivers for [RFC2547] is its ability to avoid such topologies, and
  provide any-to-any connectivity while eliminating pre-configuration
  of a mesh of CE-to-CE circuits. It is desirable to align the CE-to-CE
  protection methodologies with the any-to-any connection model
  provided by [RFC2547] so that the customer experience is seen as the
  "best of both worlds". This enhanced model supports CE-to-CE data
  protection while eliminating the requirement for pre-established IP-
  based tunnels or routing adjacencies between [IPSec] security
  gateways.

  Some Service Providers have provided some integration of [RFC2547]
  and [IPSec] by terminating [IPSec] tunnels into a Virtual Routing &
  Forwarding Instance (VRF). This solution, although network-based,
  does not extend [IPSec] between security gateways in different

 Guichard et. al                                                     2






  customer sites, and is used more for extending the reach of the
  Service Provider so that remote customer locations are able to access
  the VPN.

  This document provides a mechanism that is able to maintain the any-
  to-any connectivity nature of [RFC2547], but also enables the dynamic
  establishment of the CE-CE [IPSec] topology. The [IPSec] security
  associations established can be thought of as "Security & Forwarding
  Associations" in the sense that they are used to exchange encrypted
  data packets between the CE routers; however there is no requirement
  that they be used to exchange routing information. Thus, the routing
  scalability property of [RFC2547] is preserved.


3  Service Provider Infrastructure Reference Model

  A Service Provider may deploy an [RFC2547] service using a number of
  backbone tunneling techniques such as those described in [RFC2547],
  [MPLS-in-IP], or [PE-PE-IPsec]. [RFC2547] uses a hierarchical routing
  model that provides scalable distribution of route forwarding
  attributes. CE-CE [IPsec] encryption, as described within this
  document, relies upon the IP address partitioning and route
  forwarding state created by the [RFC2547] infrastructure and it can
  be deployed independently of the backbone tunneling technique chosen.
  The CE-CE [IPSec] topology requires a point-to-point relationship
  between CE's for data protection; however, the routing plane
  associated with the CE-CE topology leverages the [RFC2547]
  hierarchical routing model.


4  Coupling of CE Security Policy and PE Routing Planes

  Each CE router ascertains through configuration, or other means
  outside the scope of this document, whether it is used as a [IPsec]
  security gateway. Once this information is discovered, the CE router
  MUST advertise it's "Security Gateway Identity" used for [IKE] and
  [IPSec] peer end-point termination to the PE router using [BGP-4].
  The identity must be associated with each 'trusted subnet'
  represented as a prefix that the CE router protects. The identity
  will typically be an IPv4 address where the [IKE] and [IPSec]
  authentication and encryption services will be established. The PE
  router MUST then use [MP-BGP] to advertise the trusted subnet
  prefixes and the associated identity information to other PE routers.

  A PE router that receives this information via [MP-BGP] MUST be able
  to (a) identify which VPN the prefix and security gateway identity
  end-point is associated with, and (b) advertise that information to
  any security gateway CE routers that belong to the VPN.
  Identification of which VPN the update belongs to is determined by


 Guichard et. al                                                     3






  the "route-target" extended-community attribute as described in
  [RFC2547].


5  Distribution of [IPSec] Security Gateway End-points

  A CE router MAY send encrypted and non-encrypted traffic toward the
  PE router for delivery to other members of its VPN. A CE router that
  belongs to an "encrypted" VPN needs to be able to build a Security
  Association (SA) with any remote CE router that also belongs to the
  same VPN, and is a member of the encryption service.

  When traffic that needs to be encrypted is sent from a CE router that
  belongs to an "encrypted" VPN, the CE router MUST be able to
  establish a Security Association (SA) with the remote CE router
  through which the destination of the incoming packet is reachable. To
  achieve this aim, the CE router needs to discover the remote peer's
  trusted subnet prefix and the associated security gateway identity of
  the peer, and then build the [IKE] and [IPSec] security association.

  Discovery of the end-point addresses is achieved through direct [BGP-
  4] exchange with the PE router. If [BGP-4] is not established with
  the customer site, then a different discovery protocol is necessary
  and is outside the scope of this draft.

  Many [RFC2547] deployments use [BGP-4] on the PE-CE links. Typically
  these sessions only carry standard [BGP-4] attributes. In order to
  use the mechanisms described within this document, the CE router MUST
  support the capabilities as specified in [EXTCOM].

  When a CE router advertises routes from an "encrypted" VPN into the
  backbone it MUST attach a new BGP extended-community attribute,
  hereby referred to as the "Security Gateway Identity" attribute, to
  all trusted subnet prefixes for which encryption is desired. A PE
  router that receives such an update MUST export those trusted subnet
  prefixes along with the "Security Gateway Identify" attribute.

  A PE router that receives the update MUST advertise the trusted
  subnet prefixes and security gateway identities to any relevant CE
  routers that are (a) members of the "encrypted" VPN, and (b) are
  running [BGP-4] with the PE router.


6  BGP "Security Gateway Identity" Extended-community Attribute

  The Extended Community Attribute is a transitive optional BGP
  attribute, with type code 16, as specified in [EXTCOM]. The solution
  described within this document proposes to use the Opaque Extended
  Community, as specified in section 6.4 of [EXTCOM]. The format of
  this community is as follows:

 Guichard et. al                                                     4







      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 0x03 or 0x43  | Sub-Type (TBD)|          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         IP Address                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The value of the high-order octet of this extended type is either
  0x03 or 0x43. The low-order octet of this extended type carries the
  sub-type with value (TBD) and indicates that this is a "Security
  Gateway Identity".

  The value field consists of:

     Reserved - 2 octets

           Reserved for future use and should be set to 0x0000

     IP Address - 4 octets

           Security Gateway IP address


7  CE-router IPSec requirements

  A CE router that wishes to belong to an "encrypted" VPN, and use the
  mechanisms described within this document, MUST conform to the
  procedures described in [IPsec]. This means that the CE router MUST
  provide a Security Policy Database (SPD), as described in section
  4.4.1 of [IPSec], which is used to determine the disposition of all
  IP traffic inbound or outbound from the router. Each entry within the
  database specifies whether traffic matching the policy should bypass
  IPsec processing, be discarded, or be subject to IPSec processing.

  A CE router MUST provide the ability to specify "Selectors", as
  described in section 4.4.2 of [IPSec]. These are a set of IP and
  upper layer protocol field values that are used by the Security
  Policy Database (SPD) to map traffic to a Security Association (SA).

  The Security Policy Database and Selector attributes MUST be
  populated with the "Security Gateway Identity" and the associated
  "trusted subnet" prefixes. The population of the SPD from [BGP-4] may
  be an automated process with the appropriate [BGP-4] controls
  provided by the CE.

  Each CE router MUST enable the creation of security associations in
  the Security Association Database (SAD), as described in section
  4.4.3 of [IPSec], that contains parameters derived by traffic


 Guichard et. al                                                     5






  matching the [BGP-4] injected Selectors in the SPD. This database is
  used to determine what [IPSec] services are offered to IP packets.

7.1 CE-CE Security Association Setup using IKE

  A CE router MUST support an automated Security Association/Key
  management protocol for the purpose of establishing and maintaining
  Security Associations between two [IPSec] peer end-points. One
  example of such a protocol is [IKE].

  There are several options available to the CE routers with respect to
  IPsec tunnel setup and encryption of traffic:

        CE-CE authentication and/or encryption of selective packets
        based on traffic flow initiated establishment of security
        associations

        CE-CE authentication and/or encryption of selective packets
        based on pre-established [IPSec] security associations

  Each of these options is described in the following sections.
  Regardless of which option is used, on receipt of traffic that is
  matched to an SPD policy that requires [IPSec] processing, a CE
  router MUST check whether a Security Association (SA) already exists
  with the [IPSec] Security Gateway address. If an SA already exists,
  then the CE router can encrypt the traffic and forward it toward the
  PE router. If no SA exists, the CE router MUST use [IKE] or similar
  protocol to establish the SA with the security gateway identity.


7.1.1   CE-CE encryption of selective packets based on traffic flow

  CE-CE encryption may be driven by traffic flow and a CE router MAY
  choose to selectively encrypt packets based on a 'Selector' match. On
  receipt of a packet that is matched by the CE router's SPD for
  encryption, the CE router MUST be able to establish an SA with the
  remote CE router through which the destination is reachable.

  As the CE router is running [BGP-4] with the PE router, it can
  dynamically build the 'Selector' criteria based on receipt of routing
  updates that carry the "Security Gateway Identity" attribute. Using
  this information, the CE router is able to identify which routes are
  associated with a remote site, and also which of these routes need
  encryption. For the routes that need encryption, the CE is able to
  determine the "Security Gateway Identity" associated with those
  routes.

  The CE MAY dynamically establish [IPSec] SA's between the CE and PE
  routers. These [IPSec] tunnels may be used to protect the [BGP-4]
  exchange of 'Trusted Subnets' and 'Security Gateway Identities'

 Guichard et. al                                                     6






  between the PE and CE. Alternatively, the CE and PE routers MAY use
  [BGP-MD5] on the [BGP-4] session to authenticate the prefixes and the
  associated "Security Gateway Identity".

7.1.2   CE-CE Encryption with pre-established IPSec Security
     Associations

  A CE router MAY choose to pre-establish [IPSec] tunnels between CE
  routers. [IPSec] SA's may be established automatically upon
  population of the SPD that occurs upon receipt of a 'Trusted Subnet'
  prefix with a valid "Security Gateway Identity". The CE router MUST
  encrypt all traffic destined to a route via the established [IPSec]
  security association.

  The CE MAY have pre-established [IPSec] SA's between the CE and PE
  routers. These [IPSec] tunnels may be used to protect the [BGP-4]
  exchange of 'Trusted Subnets' and 'Security Gateway Identities'
  between the PE and CE. Alternatively, the CE and PE routers MAY use
  [BGP-MD5] on the [BGP-4] Session to authenticate the prefixes and the
  associated "Security Gateway Identity".

8  References

  [RFC2547], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn-
  rfc2547bis-03, October, 2002.

  [GRE], Li, T. et al, "Generic Routing Encapsulation (GRE)", RFC 1701,
  October, 1994.

  [IPSec], Kent and Atkinson, "Security Architecture for the Internet
  Protocol", RFC 2401, November 1998.

  [MPLS-in-IP], Rosen E. et al., "Encapsulating MPLS in IP or GRE",
  draft-ietf-mpls-in-ip-or-gre-00, January, 2003.

  [PE-PE-IPsec], Rosen E. et al., "Use of PE-PE IPsec in RFC2547 VPNs",
  draft-ietf-ppvpn-ipsec-2547-03, February, 2003.

  [MP-BGP], Rekhter, Y. et al., "Multiprotocol Extensions for BGP-4",
  RFC 2858, June, 2000.

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

  [EXTCOM], Tappan, D. et al., "BGP Extended Communities Attribute",
  draft-ietf-idr-bgp-ext-communities-05, May, 2002.

  [IKE], Harkins, D. et al., "The Internet Key Exchange (IKE)", RFC
  2409, November, 1998.


 Guichard et. al                                                     7






  [BGP-MD5], Heffernan, A., "Protection of BGP Sessions via the TCP MD5
  Signature Option", RFC 2385, August 1998.


9  Authors' Address

  Jim Guichard
  Cisco Systems, Inc.
  1414 Massachusetts Avenue
  Boxborough, MA, 01719
  Email : jguichar@cisco.com

  Robert Hanzl
  Cisco Systems, Inc.
  1414 Massachusetts Avenue
  Boxborough, MA, 01719
  Email : rhanzl@cisco.com

  Dan Tappan
  Cisco Systems, Inc.
  1414 Massachusetts Avenue
  Boxborough, MA, 01719
  Email : tappan@cisco.com

  Scott Wainner
  Cisco Systems, Inc.
  13600 Dulles Technology Drive
  Herndon
  Virginia, 20171
  Email : swainner@cisco.com

  Vic Locicero
  INFONET Services Corporation
  2160 E. Grand Ave.
  El Segudo, CA 90245
  Email : vic_locicero@infonet.com















 Guichard et. al                                                     8


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