[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                      Eric C. Rosen
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: December 2001
                                                        Jeremy De Clercq
                                                       Olivier Paridaens
                                                            Yves T'Joens

                                                          Chandru Sargor
                                                   Cosine Communications

                                                               June 2001

                   Use of PE-PE IPsec in RFC2547 VPNs


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

   The list of Internet-Draft Shadow Directories can be accessed at


   This draft describes a variation of RFC2547 [RFC2547bis] in which the
   outermost MPLS label of a VPN packet is replaced with an IPsec
   encapsulation. This enables the VPN packets to be carried over non-
   MPLS networks, and allows the IPsec authentication and encryption
   functions to be used to protect VPN packets.

Rosen, et al.                                                   [Page 1]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

Table of Contents

    1      Introduction  ...........................................   2
    1.1    Issue: MPLS Infrastructure Required  ....................   3
    1.2    Issue: Protection Against Misbehavior by Transit Nodes  .   4
    1.3    Issue: Limitations on Multi-Provider Misconfigurations  .   4
    1.4    Issue: Privacy for VPN Data  ............................   5
    1.5    Non-Issue: General Protection against Misconfiguration  .   6
    1.6    Conclusion  .............................................   6
    2      Specification  ..........................................   6
    2.1    Technical Approach  .....................................   6
    2.2    Selecting the Security Policy  ..........................   7
    2.3    BGP Label, Route, and Policy Distribution  ..............   7
    2.4    MPLS-in-IP Encapsulation by Ingress PE  .................   9
    2.5    PE-PE IPsec (Application of IPsec by Ingress PE)  .......  10
    2.6    Application of IPsec by Egress PE  ......................  11
    3      Comparison with Using Part of SPI Field as a Label  .....  13
    4      Summary for Sub-IP Area  ................................  14
    4.1    Summary  ................................................  14
    4.2    Where does it fit in the Picture of the Sub-IP Work  ....  14
    4.3    Why is it Targeted at this WG  ..........................  14
    4.4    Justification  ..........................................  14
    5      Authors' Addresses  .....................................  14
    6      References  .............................................  15

1. Introduction

   In "conventional" RFC2547 VPNs, when a PE router receives a packet
   from a CE router, it looks up the packet's destination IP address in
   a VRF.  As a result of this lookup, it obtains an MPLS label stack, a
   data link header, an output interface.  The label stack is prepended
   to the packet, the data link header is prepended to that, and the
   resulting frame is queued for the output interface.

   The bottom label on the MPLS label stack is always a label which will
   not be seen until the packet reaches its point of egress from the
   network. This label represents a particular route within the packet's
   VPN. The purpose of the upper labels is to cause the packet to be
   delivered to the router which understands the bottom label.

   What we discuss here are procedures creating an MPLS packet which

Rosen, et al.                                                   [Page 2]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   carries ONLY the bottom label, and then using an IPsec encapsulation
   to carry that MPLS packet (authenticated and/or encrypted) across the
   network. That is, the upper labels are replaced with an IP header and
   an IPsec header. The two endpoints of the IPsec Security Association
   will be the ingress PE router and the egress PE router.

   This note is inspired by [VPN-SPI], and originated as an attempt to
   improve upon it.

   The remainder of section 1 outlines a number of issues which can be
   addressed by the use of IPsec.

1.1. Issue: MPLS Infrastructure Required

   "Conventional" RFC2547 VPNs require that there be an MPLS Label
   Switched Path (LSP) between a packet's ingress PE router and its
   egress PE router.  This means that an RFC2547 VPN cannot be
   implemented if there is a part of the path between the ingress and
   egress PE routers which does not support MPLS.

   In order to enable RFC2547 VPNs to be deployed even when there are
   non-MPLS router along the path between the ingress and egress PE
   routers, it is desirable to have an alternative which allows the
   upper labels to be replaced with an IP header.  This encapsulating IP
   header would encapsulate an MPLS packet containing only a bottom
   label. The encapsulation header would have the address of the egress
   PE in its destination IP address field, and this would cause the
   packet to be delivered to the egress PE.

   In this procedure, the ingress and egress PEs themselves must support
   MPLS, but that is not an issue, as those routers must necessarily
   have RFC2547 VPN support, whereas the transit routers arguably should
   be able to be "vanilla" routers with no special MPLS or VPN support.
   This is most likely to be of import when VPN traffic must transit
   through multiple providers.

   It should be noted that if the upper MPLS labels are replaced with an
   unsecured IP encapsulation, it becomes more difficult to protect the
   VPNs against spoofed packets. A Service Provider (SP) can protect
   against spoofed MPLS packets by the simple expedient of not accepting
   MPLS packets from outside its own boundaries (or more generally by
   keeping track of which labels are validly received over which
   interfaces, and discarding packets which arrive with labels that are
   not valid for their incoming interfaces).  Protection against spoofed
   IP packets requires having all the boundary routers perform
   filtering; either filtering out packets from "outside" which are
   addressed to PE routers, or filtering out packets from "outside"

Rosen, et al.                                                   [Page 3]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   which have source addresses that belong "inside".  The maintenance of
   these filter lists can be management-intensive, and the their use at
   all border routers can affect the performance seen by all traffic
   entering the SP's network.

   If an IPsec encapsulation is used, however, this filtering at the
   border can be eliminated, and the spoofing protection can be managed
   at the ingress and egress PE routers, transparently to the border
   routers. IPsec does have its own management and performance
   implications, of course.

1.2. Issue: Protection Against Misbehavior by Transit Nodes

   Authentication applied by the ingress PE on a PE-to-PE basis can
   protect against the misrouting or modification (intentional or
   accidental) of packets by the transit nodes. Packets which get
   forwarded to the "wrong" egress PE will not pass authentication, nor
   will packets which have been modified. In particular, the
   authentication should guarantee the integrity of whatever MPLS labels
   are carried by the packet.

1.3. Issue: Limitations on Multi-Provider Misconfigurations

   Sometimes a VPN will have some sites which connect to one SP (SP1),
   and some other sites which connect to another SP (SP2).

   Consider a case in which VPN V1 has sites attaching to SP1 and SP2,
   but VPN V2 has all of its sites attaching only to SP2.

   SP2 would like to ensure that nothing done by SP1 can cause V1 to get
   illegitimately cross-connected to V2.  Since V2 has no sites in SP1,
   it should be immune to the effects of any misconfigurations within

   This assurance can be achieved if the egress PE (in SP2) can
   determine, for each VPN packet, whether that packet came from SP1,
   and if so, whether it carries an MPLS label which corresponds to a
   VPN route that was actually distributed to SP1. (That is, packets
   originating from SP1 destined for VPNs in SP2 would be checked if
   they are for VPNs which really have sites in SP1.)  SP2's egress PEs
   could be configured with the knowledge of which VPNs have sites
   attached to SP1. Cryptographic authentication could then be used to
   determine that a particular packet did indeed originate in SP1.

   In general, if an egress PE knows which labels may be validly applied
   by which ingress PEs, IPsec authentication can be used to ensure that

Rosen, et al.                                                   [Page 4]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   a given ingress PE has not applied a label that it has no right to
   use. However, the scalability of the VPN scheme would be severely
   compromised if an egress PE had to distribute a different set of
   labels to each ingress PE, so we will not pursue this general case,
   but will only pursue label authentication in the inter-provider case.

1.4. Issue: Privacy for VPN Data

   IPsec Security Associations that associate ingress PE routes with
   egress PE routers do not ensure privacy for VPN data. The data is
   exposed on the PE-CE access links, and is exposed in the PE routers
   themselves. Complete privacy requires that the encryption/decryption
   be performed within the enterprise, not by the SP.  So the use of
   PE-PE IPsec encryption within the network of a single SP will perhaps
   be of less import than the use of IPsec authentication.  On the other
   hand, if an SP is trusted to properly secure its routers, but the
   transmission media used by the SP are not trusted, then PE-PE
   encryption does provide the necessary privacy.

   There may be a need for encryption if a VPN has sites attached to
   different trusted SPs, but some of the transit traffic needs to go
   through the "public Internet". In this case, it may be necessary to
   encrypt the VPN data traffic as it crosses the public Internet.
   However, while PE-PE encryption is the one way to handle this, it is
   not the only way. An alternative would be to use an encrypted tunnel
   to connecting a border router of one trusted SP to a border router of
   another. Then the two trusted domains could be treated as immediate
   neighbors, adjacent over the tunnel.  This would keep the
   encryption/decryption at the few locations where it is actually
   needed.  On the other hand, there may be performance and scalability
   advantages to spreading the cost of the cryptography among a larger
   set of routers, viz., the ingress and egress PEs.

   The scenario of having VPN traffic go from a trusted domain through
   an untrusted domain to another trusted domain may not be completely
   realistic, though, due to the difficulty of supporting the necessary
   Service Level Agreements through the public Internet.  (This is an
   issue of some controversy.)

Rosen, et al.                                                   [Page 5]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

1.5. Non-Issue: General Protection against Misconfiguration

   In general, the integrity of an RFC2547 VPN depends upon the SP
   having properly configured the PE routers.  There is no way of
   preventing an SP from creating a bogus VPN that contains sites which
   aren't supposed to communicate with each other.  It is the SP's
   responsibility to get this right.

   It is sometimes thought one can obtain protection against
   misconfigurations by having the PE routers apply cryptographic
   authentication to the VPN packets.  This is not the case.  If an
   ingress PE router has been misconfigured so as to assign a particular
   site to the wrong VPN, likely as not the PE has been misconfigured to
   apply that VPN's authenticator to packets to/from that site.

   Protection against misconfiguration on the part of the SP requires
   that the authentication procedure be applied before the ingress PE
   router sees the packets, and after the egress PE router forwards
   them, and cannot be dealt with by PE-PE IPsec.

1.6. Conclusion

   Taken together, the above set of issues suggest that there are
   situations in which using PE-PE IPsec as the tunneling protocol for
   RFC2547 VPNs does have value.  In the next section, we specify the
   necessary procedures for incorporating PE-PE IPsec as a tunneling
   option for RFC2547 VPNs.

2. Specification

2.1. Technical Approach

   In short, the technical approach specified here is:

      1. Continue to use MPLS to identify a VPN-IP route, by continuing
         to add an MPLS label stack to the VPN packets. However, the
         label stack will carry only one label, the current "bottom

      2. An MPLS-in-IP encapsulation will be used to turn the above MPLS
         packet back into an IP packet. This in effect creates an IP
         tunnel between the ingress PE router and the egress PE router.

Rosen, et al.                                                   [Page 6]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

      3. IPsec Transport Mode will be used to secure the above-mentioned
         IP tunnels.

   The net effect is that an MPLS packet gets sent through an IPsec-
   secured IP tunnel.

   The following sub-sections attempt to flesh this out in more detail.

2.2. Selecting the Security Policy

   One might think that a given SP (or set of cooperating SPs) will
   decide either that they need to use IPsec for ALL PE-PE tunnels, or
   else that PE-PE IPsec is not needed at all.  But this simple "all or
   nothing" strategy does not really capture the set of considerations
   discussed in the Introduction.  For example, a very reasonable policy
   might be to use IPsec only for inter-provider PE-PE tunnels, while
   using MPLS for intra-provider PE-PE tunnels. Or one might decide to
   use IPsec only for certain inter-provider tunnels.  Or one might
   decide to use IPsec for certain intra-provider tunnels.

   In an RFC2547 VPN environment, it makes most sense to place control
   of the policies with the egress PE router. It is the egress PE which
   needs to know that it wants to process certain packets ONLY if they
   come through encrypted tunnels, and that it wants to discard those
   same packets if they don't come through encrypted tunnels. This means
   that we need to be able to configure a policy into the egress PE, and
   have it signal that policy to the ingress PE. RFC2547 already
   provides an egress-to-ingress signaling capability via BGP, and we
   will specify how to extend this to the signalling of security policy.

   Of course, there is nothing to stop an ingress PE router from being
   configured to use IPsec even if the egress PE has not signalled its
   desire for IPsec. This should work, as long as the necessary IPsec
   infrastructure is in place.  (However, in this sort of application
   the ingress PE and the egress PE are NOT really independent entities
   which might conceivably have different security policies.)

2.3. BGP Label, Route, and Policy Distribution

   Distribution of labeled VPN-IP routes by BGP is done exactly as at
   present, 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 tunnel.  In general, an ingress PE will not have to know

Rosen, et al.                                                   [Page 7]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   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. The obvious way to do this is the
   following. 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.

   Let's call this attribute the "IPsec Extended Community".  (It is
   possible that this will actually be encoded as a particular value or
   set of values of a more general "Tunnel Type Extended Community"; for
   the purposes of this draft, however, we will continue to refer to it
   as the "IPsec Extended Community".)

   It is conceivable that an egress PE in a particular SP's network will
   only want to receive IPsec-secured IP-tunneled traffic for those VPNs
   which have sites that are attached to other SPs.  In this case, one
   would want to be able to configure, on a per-VRF basis, whether
   routes exported from that VRF should have an IPsec Extended Community
   attribute or not.

   A more complex situation would arise if it were only desired to
   receive IPsec-secured IP-tunneled traffic for a particular VPN if
   that traffic has originated from a site which is attached to a
   different SP's network. That is,  one might want  to receive  inter-
   provider traffic  through an IPsec-secured IP tunnel, but to receive
   intra-provider traffic through an unsecured MPLS LSP. As long as an
   SP has a policy of never accepting MPLS packets from other SPs, this
   may provide the necessary security while minimizing the amount of
   cryptography that actually has to be used.

   One way to do this would be to map each exportable IP address prefix
   into two different VPN-IP prefixes, using two different RDs (say RD1
   and RD2).  Then two different RTs (say RT1 and RT2) would be used,
   one of which causes intra-provider distribution,  and one of  which
   causes inter-provider distribution. The prefixes with RD1 would be
   given RT1 as a route target; the prefixes with RD2 would be given RT2
   as a route target. If RT2 is the route target that causes inter-
   provider distribution, then only the routes with RT2 would carry the
   IPsec Extended Community.

   A simpler approach, perhaps, would be to use only a single set of
   VPN-IP prefixes, but to have a value of the IPsec Extended Community
   which encodes an SP identifier, and which means "only use IPsec if
   the ingress PE is in a different SP network than the one which is
   identified here". (Again, the assumption is that MPLS packets are not
   accepted from other SPs.)

Rosen, et al.                                                   [Page 8]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   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. It is even conceivable that it
   will want some traffic to arrive through an IPsec tunnel without
   being either encrypted or authenticated. The IPsec Extended Community
   attribute should have a value which specifies which of these are

   It may be desirable to allow the IPsec Extended Community to specify
   a set of policies, so that the ingress PE can choose from among them.

2.4. MPLS-in-IP Encapsulation by Ingress PE

   When a PE receives a packet from a CE, it looks up the packet's IP
   destination address in the VRF corresponding to that CE. This enables
   it to find a VPN-IP route. The VPN-IP route will have an associated
   MPLS label and an associated BGP Next Hop. The label is pushed on the
   packet. Then, if (and only if) the VPN-IP route has an IPsec Extended
   Community attribute, an IP encapsulation header is prepended to the
   packet, creating an MPLS-in-IP encapsulated packet.  The IP source
   address field of the encapsulation header will be an address of the
   ingress PE itself. The IP destination address field of the
   encapsulation header will contain the value of the associated BGP
   Next Hop attribute; this will be an IP address of the egress PE.

   (This description is not meant to specify an implementation strategy;
   any implementation procedure which produces the same result is

   N.B.: If the ingress PE and the egress PE are not in the same
   autonomous system, this requires that there be an EBGP connection
   between a router in one autonomous system and a router in another. If
   the two autonomous systems are not adjacent, this will need to be a
   multi-hop EBGP connection.

   The effect is to dynamically create an IP tunnel between the ingress
   and egress PE routers. No apriori configuration of the remote tunnel
   endpoints is needed. Note that these IP tunnels are NOT IGP-visible
   links, and routing adjacencies are not supported across these tunnel.
   Note also that the set of remote tunnel endpoints is NOT known in
   advance, but is learned dynamically via the BGP distribution of VPN-
   IP routes.

   These IP tunneled packets will then be associated with an IPsec
   Security Association (SA), and transported using IPsec transport
   mode. This is described in more detail in the next sub-section.

Rosen, et al.                                                   [Page 9]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

2.5. PE-PE IPsec (Application of IPsec by Ingress PE)

   A given ingress PE needs to have an IPsec SA with each PE router that
   is an egress PE for traffic which the ingress PE receives from a CE.

   In general, the set of egress PEs for a given ingress PE is not known
   in advance. This is determined dynamically by the BGP distribution of
   VPN-IP routes. This suggests that it will be very important to be
   able to set up IPsec SAs dynamically, and that static keying will not
   be a viable option.  There will need to be a key distribution
   infrastructure that supports multiple SPs, and IKE will need to be

   A number of different VPNs might need to have traffic carried from a
   particular ingress PE to a particular egress PE. It is thus natural
   to ask whether there should be one SA between the pair of PEs, or n
   SAs between the pair of PEs, where n is the number of VPNs.  Clearly,
   scalability is improved by having only a single SA for each pair of
   PEs. So the question is whether there is a significant security
   advantage to having a distinct SA for each VPN. There does not appear
   to be any such advantage. Since the SA is PE-to-PE, NOT CE-to-CE,
   having a different SA for each VPN does not appear to provide any
   additional protection.

   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.  But this is
   not the same as having a separate SA for each VPN.

   We assume that the PE router will contain an IPsec module (either a
   hardware or a software module) which is responsible for doing the key
   exchange, for setting up the IPsec SAs as needed, and for doing the

   As discussed in section 2.2, the PE router creates an MPLS-in-IP
   encapsulated packet. It does not simply send that packet to its next
   hop, rather, it delivers the packet, along with the corresponding
   IPsec Extended Community value, to the IPsec module. (As an
   implementation consideration, it is not really required to deliver an
   MPLS-in-IP encapsulated packet to the IPsec module; all that really
   needs to be delivered is the MPLS packet and the information (or
   pointer thereto) that would be needed to create the IP encapsulation

   The IPsec module will set up an IPsec SA to the packet's destination
   address, if one does not already exist. It will then apply the
   appropriate IPsec procedures, generating a packet with an IP header
   followed by an IPsec header followed by an MPLS label stack followed

Rosen, et al.                                                  [Page 10]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   by the original data packet. The IPsec module then delivers this
   packet, as if it were a brand new packet, to the routing module.  The
   routing module forwards it as an IP packet.

   While the IPsec SA is being set up, packets cannot be delivered
   through it.  Packets may be dropped during this time, though a
   sensible policy might be to queue the first packet and drop the rest
   (as is commonly done in ARP implementations while awaiting an ARP

   We do assume here that the IPsec module is subsidiary to the PE
   router, and does not function itself as an independent router in the
   network. A solution could be designed to support the latter case, but
   at a considerable increment in complexity.

   The procedure as specified above requires two routing lookups. Before
   IPsec processing, The original packet's destination address is looked
   up in a VRF.  After IPsec processing, the IPsec packet's destination
   address is looked up in the default routing table.  It is worth
   noting that the information obtained from the second lookup is really
   available at the time of the first lookup.  In some environments, it
   might be advantageous to forward this information, along with the
   packet, to the IPsec module; possibly this can be used to avoid the
   need for the second lookup. However, in some environments, it will be
   impossible to avoid the second lookup.

2.6. Application of IPsec by Egress PE

   We assume that every egress PE is also an ingress PE, and hence has
   the IPsec module which is mentioned in section 2.2. This module will
   handle the necessary IKE functions, SA and tunnel maintenance, etc.,
   etc, as well as handling arriving IPsec packets. The IPsec module
   will apply the necessary IPsec procedures to arriving IPsec packets,
   and will hence recover the contained MPLS-in-IP packets. The IPsec
   module should then strip off the encapsulating IP header to recover
   the MPLS packet, and should then deliver the resulting MPLS packet to
   the routing function for ordinary MPLS switching. (Of course, as an
   implementation matter, there is probably no need to put the
   encapsulating IP header on only to then take it off immediately.)

   There are subtle issues having to do with the proper handling of MPLS
   packets (rather than IPsec packets) which the PE router receives from
   P routers or from other PE routers. If the top label on a received
   MPLS packet corresponds to an IP route in the "default" routing
   table, "ordinary" MPLS switching is done.  But if the top label on a
   received MPLS packet corresponds to a VPN-IP route, there are a
   number of different cases to consider:

Rosen, et al.                                                  [Page 11]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

      a. The packet has just been removed from an IPsec SA by the IPsec
         module. In this case, ordinary MPLS switching should be done.
         (Well, ... see below for further qualifications.)

      b. The packet arrived from a neighboring P or PE router as an MPLS
         packet, with no IPsec encapsulation. Now we have some sub-

              i. The packet's top label corresponds to a VPN-IP route
                 which was not exported with the IPsec Extended
                 Community attribute. In this case, ordinary MPLS
                 switching is applied.

             ii. The packet's top label corresponds to a VPN-IP route
                 which was exported with the value of the IPsec Extended
                 Community attribute which indicates that IPsec is to be
                 used only when the ingress PE is in a different SP
                 network.  In this case, we assume that MPLS packets are
                 not being accepted from other networks, so ordinary
                 MPLS switching is applied.

            iii. The packet's top label corresponds to a VPN-IP route
                 which was exported with an IPsec Extended Community,
                 but case ii does not apply. In this case the packet
                 should be discarded; packets with this label are
                 supposed to be secured, but this packet was not
                 properly secured.

   Providing this functionality requires the use of two separate label
   lookup tables, one of which is used for packets that have been
   removed from IPsec SAs, and one of which is used for other packets.
   Labels which are only valid when they are carried within an IPsec
   packet would only appear in the former lookup table. This does imply
   that after a packet has been processed by the IPsec module, the
   contained MPLS packet is not simply returned to the routing lookup
   path; rather it must carry some indication of which label lookup
   table must be used to switch that packet. This also presupposes that
   there will be MPLS VPN code to properly populate the two different
   lookup tables.  Perhaps packets removed from IPsec SAs should appear,
   to the routing module, to be arriving on a particular virtual
   interface, rather than on the actual sub-interface over which they
   really arrived.  Then interface-specific label lookup tables could be

   In fact, it may be advantageous to have more than one label lookup
   table that is used for packets that have been removed from IPsec SAs.
   Certain VPN-IP routes will be exported to certain SPs, but not to
   others. Security can thus be improved by having one label lookup

Rosen, et al.                                                  [Page 12]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

   table for each such SP. The IPsec module would then have to say, for
   each packet, which SP it came from. I think that given a proper
   certificate authority infrastructure this can be inferred by the
   IPsec module from the information which the IKE procedure makes
   available to it. For this to work, the MPLS VPN code would have to be
   able to properly populate the various lookup tables.

3. Comparison with Using Part of SPI Field as a Label

   An alternative methodology that achieves similar results is the one
   described in [VPN-SPI].  The proposal described above was in fact
   inspired by that draft, and arose as a proposed improvement to it.

   In the current proposal, IPsec transport mode is applied to an MPLS-
   in-IP encapsulation, where the MPLS-in-IP encapsulation carries the
   BGP-distributed labels of RFC 2547. In [VPN-SPI], there is no MPLS-
   in-IP encapsulation. Rather:

     - IPsec tunnel mode is applied to the enduser's packet directly.

     - A subfield of the IPsec SPI field is used to provide the function
       of the BGP-distributed MPLS label. This either requires that BGP
       distribute a different kind of label (one that can fit into the
       SPI sub-field), or that an MPLS label be carried within the SPI

   The [VPN-SPI] proposal does have the advantage of making each packet
   4 bytes shorter, since an entire entry in the MPLS label stack is
   eliminated (replaced by the SPI sub-field).

   The current proposal, unlike that in [VPN-SPI], does not in any way
   alter the use or interpretation of the SPI field, and does not impact
   the IPsec or IKE protocols and procedures in any way. The current
   proposal also better preserves the distinction between fields that
   are meaningful to IPsec and fields that are meaningful to
   routing/forwarding.  Failure to preserve this layering could
   potentially lead to complications in the future (e.g., if BGP ever
   needed to distribute a stack of two MPLS labels, or if some
   enhancement to IPsec ever needed to reclaim the SPI sub-field used to
   carry the label, etc., etc.). Keeping the MPLS VPN functionality in
   the MPLS layer and out of the IPsec layer certainly seems worthwhile.

Rosen, et al.                                                  [Page 13]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

4. Summary for Sub-IP Area

4.1. Summary

   The base specification for RFC2547 VPNs, i.e., draft-rosen-
   rfc2547bis-03.txt, specifies the procedures for providing a
   particular style of VPN, using MPLS label switched paths between
   Provider Edge (PE) routers. The base specification does not discuss
   other types of tunnels between PE routers.

   This draft extends the base specification by specifying the
   procedures for providing the RFC2547 style of VPN using IPsec tunnels
   (rather than MPLS LSPs) between PE routers.

4.2. Where does it fit in the Picture of the Sub-IP Work

   This work fits squarely in the PPVPN box.

4.3. Why is it Targeted at this WG

   The WG is chartered with considering the RFC2547 style of VPN. This
   draft specifies procedures to allow that style of VPN to run on
   networks which do not implement MPLS in the core switches, and/or in
   environments in which increased security is needed.

   Thus the draft allows the RFC2547 style of VPN to meet additional
   requirements that are not met by the base specification.

4.4. Justification

   The WG should consider this document as it extends a style of VPN
   explicitly called out in the charter so that (a) additional security
   requirements can be met, (b) it becomes applicable to a wider range
   of IP-based backbone environments.

5. Authors' Addresses

     Eric C. Rosen
     Cisco Systems, Inc.
     250 Apollo Drive
     Chelmsford, MA, 01824
     Email: erosen@cisco.com

Rosen, et al.                                                  [Page 14]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

     Jeremy De Clercq
     Francis Wellesplein 1
     2018 Antwerpen, Belgium
     Phone: +32 3 240 4752
     Email: jeremy.de_clercq@alcatel.be

     Olivier Paridaens
     Francis Wellesplein 1
     2018 Antwerpen, Belgium
     Phone: +32 3 240 9320
     Email: olivier.paridaens@alcatel.be

     Yves T'Joens
     Francis Wellesplein 1
     2018 Antwerpen, Belgium
     Phone: +32 3 240 7890
     Email: yves.tjoens@alcatel.be

     Chandru Sargor
     CoSine Communications
     1200 Bridge Parkway
     Redwood City, CA 94065
     Email: csargor@cosinecom.com

6. References

   [RFC2547bis] BGP/MPLS VPNs, Rosen et. al., draft-rosen-rfc2547bis-
   03.txt, 2/01.

   [VPN-SPI] BGP/IPsec VPN, De Clercq et. al., draft-declercq-bgp-
   ipsec-vpn-01.txt, 2/01.

Rosen, et al.                                                  [Page 15]

Internet Draft    draft-rosen-ppvpn-ipsec-2547-00.txt          June 2001

Rosen, et al.                                                  [Page 16]