Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs
draft-ietf-l3vpn-ipsec-2547-05

  Please excuse the length of this DISCUSS position.  It summarizes
  concerns from reviewers in the Security Directorate and myself.
  I have tried to eliminate overlap from the various reviewers.

  The term "privacy" should be replaced with "confidentiality" in the
  whole document.  See definitions in RFC 2828.

  The title of the document and the Introduction do not seem to agree
  on the purpose of the document.  The Title says:
  >
  > Architecture for the Use of PE-PE IPsec Tunnels ...
  >
  And, the Introduction says:
  >
  > This document specifies procedures for replacing the backbone
  > route label with an IPsec encapsulation
  >
  I think that the Introduction is more accurate.

  The introductory text says that IPsec is used to 'encapsulate" MPLS
  traffic. It says the "payload" will be an MPLS packet with the label
  stack consisting of a single MPLS entry, a route label.  This raises
  several concerns:

   * I assume ESP encapsulation is intended, but ESP is mentioned
     anywhere.

   * Section 2 explains the encapsulation, and that does not match
     the description in introductory text.  A diagram in Section 2
     would help.

   * There is no mention of the SPD.  Without a discussion of the SPD,
     the granularity of access control unclear.  Section 2.2 talks
     about selecting a security policy, but again there is no mention
     of the SPD.  What SPD entries that are appropriate for this
     application?  How are source and destination address used?  How
     is the next protocol value used?  How are the port fields used?

   * Section 1.2 talks about anti-spoofing protection; however, the
     actual protection depends on the way that the previous points are
     resolved.

  Section 2.2 says:
  >
  > [RFC2547bis] already provides an egress-to-ingress signaling
  > capability via BGP, and we specify below how to extend this to
  > the signaling of security policy.
  >
  I assume this is a reference to Section 2.3, which says:
  >
  > Distribution of labeled VPN-IP routes by BGP is done exactly as
  > specified in [RFC2547bis], except that some additional BGP 
  > attributes are needed for each distributed VPN-IP route.
  >
  > A given egress PE will be configurable to indicate whether it expects
  > to receive all, some, or none of its VPN traffic through an IPsec-
  > secured IP or GRE tunnel.  In general, an ingress PE will not have to
  > know in advance whether any of the egress PEs for its VPNs require
  > their VPN traffic to be sent through an IPsec-secured IP tunnel; this
  > will be signaled from the egress PE. If an egress PE wants to receive
  > traffic for a particular VPN-IP route through an IPsec-secured IP
  > tunnel, it adds a new BGP Extended Community attribute to the route.
  > This attribute will then get distributed along with the route to the
  > ingress PEs.
  >
  If I understand this correctly, unsecured BGP configures IPsec SPD
  entries.  Authentication and integrity of this configuration information
  is vital to security.  Maybe I did not understand the intention here,
  but later comments in section 2.4 suggest otherwise.  For example,
  section 2.4 notes that "no a priori configuration of remote tunnel
  endpoints is needed."  If my understanding is correct, please tell how
  the distribution of security policy will be protected.

  Section 2.3 says:
  >
  > It is conceivable that an egress PE will want some of its IPsec-
  > secured IP-tunneled VPN traffic to be encrypted, but will want some
  > to be authenticated and not encrypted.
  >
  And then, Section 2.6 says:
  >
  > It is conceivable that there might need to be two (or more) SAs
  > between a pair of PEs, e.g., one in which data encryption is used
  > and one in which authentication but not encryption is used.
  >
  Multiple SAs are needed to support this vision, but providing
  different security services to different packets in a single SA is
  not supported by IPsec.  Since the purpose for this draft is to
  protect PE-PE MPLS-in-IP traffic from being spoofed, why skip the
  authentication?

  Section 2.6 suggests that one SA can be used to carry traffic for
  multiple VPNs between two routers (a PE-PE pair).  This seems
  reasonable given the security model proposed; however, this section
  also says that the packet delivered for IPsec processing need not be
  in the MPLS-in-IP or MPLS-in-GRE format; it might be a raw MPLS packet
  Handling raw MPLS assumes an IPsec module design very different than
  ones seen today in hosts, security gateways, or even bump-in-the-wire
  implementations.  The text also says that the module would "apply the
  appropriate IPsec procedures," which seem to include generation of
  an IP header for the transport mode SA.  This sort of processing is
  not part of IPsec.  It needs to be specified in this document.
  (Only a tunnel mode SA can generate an IP header to encapsulate
  outbound traffic, but transport mode is used here.)

  Section 2.7 describes inbound processing and tries to address the
  problem of detecting and rejecting traffic that arrives with an MPLS
  label associated with an IPsec-protected VPN, but which has not be
  delivered via an appropriate SA. This discussion points out that the
  intent is to use MPLS labels as a basis for access control, even
  though it does not explicitly say so.  The problem is that IPsec is
  not prepared to enforce this particular access control model, since
  MPLS labels are not selectors.  It would be good to see a diagram
  showing where the IPsec boundary fits in this proposed use of IPsec,
  since the easy interpretation of the access control goal here does
  not match IPsec capabilities.  This will also help make it clear
  how to configure the SPD for this application.  The use of virtual
  interfaces is mentioned briefly, and that might be a way to address
  the access control issues.

  The Security Considerations are insufficient.  Some points that need
  to be included are:
  
   * Describe any of the concerns arising from security policy
     distribution via BGP.  RFC 3723 requires that iSNS be secured
     when it is used for security policy distribution.  If BGP is
     used to distribution security policy I would expect similar
     considerations to apply.

   * Discuss the IPsec Extended Community.  Is this community
     transitive?  The Extended Community attribute is itself
     transitive, but each community must be identified as to
     whether it is transitive across ASes or not.  There are
     concerns about the integrity of this way of signaling
     security policy:

      -- In the case where all PEs are in one AS, then the VPN-IPv4
         routes can be distributed through IBGP connections (single
         hop) or through route reflectors.

      -- RFC 2796 does not mention any restrictions on the types of
         modifications a route reflector might do to reflected routes.
         General rules of BGP operation would then presume to apply.

      -- draft-ietf-idr-bgp-ext-communities-09.txt says that "A BGP
         speaker receiving a route with the Extended Communities
         attribute MAY modify this attribute according to the local
         policy."  So, integrity/authentication protection would be
         difficult to provide for this field, in its hop through route
         reflectors.

      -- If the ingress and egress routers are in different ASes, then
         the draft says there must be an EBGP connection between a pair
         of routers in the two ASes (presumably not necessarily the
         ingress/router pair).  This should be a single hop, so there
         should not be a problem with the integrity of the community,
         given that it is transitive and understood by both endpoints
         (assuming integrity/authentication for the BGP session).  But,
         the Multi-AS Backbones section talks of using EBGP connections
         between ASBR's with the ASBR forwarding IBGP learned routes,
         so the ASBR would have the opportunity to affect the IPsec
         Extended Community attribute.  The Multi-AS Backbones also
         speaks of ASes that serve as transit between the source AS
         and the destination AS, giving even more routers the chance
         to modify the IPsec Extended Community attribute.

   * Discuss the consequences of a misconfigured PE router.  The
     document already says: "The SP must be careful not to incorrectly
     create a VPN containing sites that are not supposed to
     communicate with each other."  This is too easily dismissed in
     the body of the document, where it says: "likely as not the PE
     has been misconfigured to apply that VPN's authenticator to
     packets to/from that site."  This presumes that the PE is
     legitimately associated with the incorrect VPN, otherwise it
     should not know the authenticator.