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

Versions: 00 01 02 03 04 05

Network Working Group                                      Eric C. Rosen
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: February 2006
                                                        Jeremy De Clercq
                                                       Olivier Paridaens
                                                            Yves T'Joens
                                                                 Alcatel

                                                          Chandru Sargor


                                                             August 2005


  Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs


                   draft-ietf-l3vpn-ipsec-2547-05.txt

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.











Rosen, et al.                                                   [Page 1]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


Abstract

   In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets
   traveling from one Provider Edge (PE) router to another generally
   carry two MPLS labels, an "inner" label that corresponds to a VPN-
   specific route, and an "outer" label that corresponds to a Label
   Switched Path (LSP) between the PE routers.  In some circumstances,
   it is desirable to support the same type of VPN architecture, but
   using an IPsec Security Association in place of that LSP.  The
   "outer" MPLS label would thus be replaced by an IP/IPsec header.
   This enables the VPN packets to be carried securely over non-MPLS
   networks, using standard IPsec authentication and/or encryption
   functions to protect them.  This draft specifies the procedures which
   are specific to support of BGP/MPLS IP VPNs using the IPsec
   encapsulation.



Table of Contents

    1      Introduction  ...........................................   3
    1.1    Issue: Protection Against Spoofed Packets  ..............   4
    1.2    Issue: Protection Against Misbehavior by Transit Nodes  .   5
    1.3    Issue: Limitations on Multi-Provider Misconfigurations  .   5
    1.4    Issue: Privacy for VPN Data  ............................   6
    1.5    Non-Issue: General Protection against Misconfiguration  .   7
    1.6    Conclusion  .............................................   7
    2      Specification  ..........................................   7
    2.1    Technical Approach  .....................................   7
    2.2    Selecting the Security Policy  ..........................   8
    2.3    BGP Label, Route, and Policy Distribution  ..............   9
    2.4    MPLS-in-IP/GRE Encapsulation by Ingress PE  .............  10
    2.5    MPLS-in-IP vs. MPLS-in-GRE  .............................  11
    2.6    PE-PE IPsec (Application of IPsec by Ingress PE)  .......  11
    2.7    Application of IPsec by Egress PE  ......................  13
    3      Comparison with Using Part of SPI Field as a Label  .....  15
    4      Security Considerations  ................................  16
    5      IANA Considerations  ....................................  16
    6      Acknowledgments  ........................................  16
    7      Authors' Addresses  .....................................  16
    8      Normative References  ...................................  17
    9      Informative References  .................................  17
   10      Full Copyright Statement  ...............................  17
   11      Intellectual Property  ..................................  18







Rosen, et al.                                                   [Page 2]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


1. Introduction

   The present document uses terminology from [RFC2547bis], and
   presupposes familiarity with that document and its terminology.

   In BGP/MPLS IP VPNs, when an ingress PE router receives a packet from
   a CE router, it looks up the packet's destination IP address in a VRF
   ("VPN Routing and Forwarding Table").  As a result of this lookup, it
   learns the output interface on which the packet must be sent, and it
   also learns the set of headers which must be prepended to the packet
   before it is sent on that interface.  In "conventional" BGP/MPLS IP
   VPNs, this set of headers consists of a data link layer header
   followed by (possibly) an MPLS label stack.  If the packet is going
   out an interface to a CE router (i.e. the ingress PE is the same as
   the egress PE), no MPLS label stack is needed.  If the packet's
   egress PE router is directly adjacent to the ingress PE, the MPLS
   label stack will have one or more entries.  In other cases, the MPLS
   label stack has two or more entries.

   Unless the packet goes directly to a CE router on the same PE, the
   MPLS label stack will contain a label that 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, and we will
   call it the "VPN route label".  Directly above the VPN route label is
   a label which represents a route across the backbone to the egress PE
   router.  We will call this label the "backbone route label".

   The backbone route label may or may not be the packet's top label;
   additional entries may also be pushed on the label stack, if
   additional MPLS services (e.g., traffic engineering) are used to
   carry traffic to the egress PE.  These additional labels may be
   pushed on by the ingress PE, or by a P router somewhere along the
   path.

   This document specifies procedures for replacing the backbone route
   label with an IPsec encapsulation.  In effect, this creates an MPLS-
   in-IPsec encapsulation, in which the VPN route label is carried
   across the network within an IPsec encapsulation.  By "within an
   IPsec encapsulation", we mean "in a packet containing an IP header
   and an IPsec header".  This IPsec encapsulation corresponds to an
   IPsec Security Association (SA) whose two endpoints are the ingress
   PE router and the egress PE router.  The payload of the IPsec
   encapsulation is an authenticated and/or encrypted MPLS packet, whose
   label stack contains a single entry, viz., the VPN route label.  The
   payload of this MPLS packet is the user data packet being sent within
   the VPN.

   The IP/IPsec encapsulation will be used even if the ingress PE and



Rosen, et al.                                                   [Page 3]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   the egress PE are directly adjacent, i.e., even in the case where a
   backbone route label might not be used.  However, no IP/IPsec
   encapsulation is applied if the ingress PE is the same device as the
   egress PE.

   If additional MPLS services, such as traffic engineering, are used in
   the backbone network, an MPLS label stack will appear above the IP
   header.  This is orthogonal to any issues discussed in the present
   document.  This results in an MPLS packet containing an IP packet
   containing an IPsec packet containing an MPLS packet; the latter MPLS
   packet may have only a single label, the VPN route label.

   This document 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 in this manner.


1.1. Issue: Protection Against Spoofed Packets

   According to [RFC2547bis]:

       "Before a customer data packet travels across the Service
       Provider's backbone, it is encapsulated with the MPLS label that
       corresponds, in the customer's VPN, to the route that is the best
       match to the packet's destination address.  This MPLS packet is
       further encapsulated (e.g., with another MPLS label, or with an
       IP or GRE ("Generic Routing Encapsulation" tunnel header [MPLS-
       in-IP-GRE]) so that it gets tunneled across the backbone to the
       proper PE router."

   This explicitly allows the use of three different tunnel
   encapsulations:  MPLS, MPLS-in-IP, and MPLS-in-GRE.  [MPLS-in-L2TPv3]
   allows a fourth.  The latter three encapsulations all require the
   packets to have an IP header in which the address of the egress PE
   appears in the destination IP address field.  However, it then
   becomes quite difficult, in general, 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).  However, this does depend on the assumption that the SP
   network is not serving as a transit network for arbitrary MPLS
   packets from other networks.



Rosen, et al.                                                   [Page 4]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   Protection against spoofed IP packets requires having all the
   boundary routers perform filtering; either (a) filtering out packets
   from "outside" which are addressed to PE routers, or (b) filtering
   out packets from "outside" which have source addresses that belong
   "inside", and having PE routers refuse to accept packets addressed to
   them but with "outside" source addresses.  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.  Further, these filtering techniques may
   be difficult to apply in the case of multi-provider VPNs, because in
   multi-provider VPNs, packets from outside an SP's network can
   legitimately be addressed to its PE routers.

   If, on the other hand, the backbone route label is replaced by an
   IPsec encapsulation, protection against spoofed packets does not rely
   on any sort of filtering at the border.  The cryptographic
   authentication features of IPsec enable an egress PE to detect and
   discard packets for a particular VPN that were not generated by a
   valid ingress PE for that VPN. Thus spoofing protection is managed
   entirely 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

   Cryptographic 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.  As the VPN route label is
   part of the IPsec packet payload, the egress PE will know that the
   VPN route label was placed in the packet by a valid ingress PE.


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




Rosen, et al.                                                   [Page 5]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   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
   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.  Therefore 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 a valuable measure of 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 one way to handle this, it is not
   the only way. An alternative would be to use an encrypted tunnel to
   connect 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



Rosen, et al.                                                   [Page 6]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   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.


1.5. Non-Issue: General Protection against Misconfiguration

   In general, the integrity of a BGP/MPLS IP VPN depends upon the SP
   having properly configured the PE routers.  The SP must be careful
   not to incorrectly create a VPN containing sites that are not
   supposed to communicate with each other.

   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
   BGP/MPLS IP VPNs does have value.  In the next section, we specify
   the necessary procedures for incorporating PE-PE IPsec as a tunneling
   option for BGP/MPLS IP VPNs.


2. Specification

2.1. Technical Approach

   In short, the technical approach specified here is:

      1. Use the standard technique [RFC2547bis] of using an MPLS label
         to represent a VPN route, by prepending an MPLS label stack to
         the VPN packets. However, the label stack will contain only one
         label, the VPN route label.







Rosen, et al.                                                   [Page 7]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


      2. Use an MPLS-in-IP or MPLS-in-GRE encapsulation to turn the
         above MPLS packet back into an IP packet. This in effect
         creates an "IP tunnel" or a "GRE tunnel" between the ingress PE
         router and the egress PE router.

      3. Use IPsec Transport Mode to secure the above-mentioned IP
         tunnels.

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

   The following sub-sections specify this procedure in greater 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.

   The architecture therefore supports more finely grained policies than
   "all or nothing".  However, in order to support the more finely
   grained policies, an SP must, at its border routers, discard all
   labeled packets that originate from outside its network.  Otherwise
   it is difficult, if not impossible, to know for sure that a packet
   which is not protected by IPsec originated from a trusted PE within a
   trusted area of the network.  If it is not feasible or desirable to
   discard all labeled packets received at the border routers, then both
   intra-provider and inter-provider tunnels would have to be protected
   by IPsec.

   In a BGP/MPLS IP VPN environment, if it is desired to use IPsec
   between a pair of PEs, one might expect that the ingress PE and the
   egress PE are each configured to ensure that traffic to the other is
   sent via IPsec.

   If the ingress PE is configured to use IPsec but the egress PE is
   not, then the ingress PE will attempt to set up an SA to the egress
   PE, and the egress PE will either cooperate or not.  In the former
   case, the SA gets set up, and traffic can be sent from ingress to
   egress in accord with the policy configured into the ingress.




Rosen, et al.                                                   [Page 8]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   If the egress PE is configured to use IPsec but the egress PE is not,
   then successful transmission of the traffic cannot occur unless there
   is some way for the egress to signal its policy to the ingress.
   [RFC2547bis] already provides an egress-to-ingress signaling
   capability via BGP, and we specify below how to extend this to the
   signalling of security policy.


2.3. BGP Label, Route, and Policy Distribution

   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.

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




Rosen, et al.                                                   [Page 9]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


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

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

   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/GRE 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 or GRE encapsulation header is prepended
   to the packet, creating an MPLS-in-IP or MPLS-in-GRE 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
   acceptable.)




Rosen, et al.                                                  [Page 10]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   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.


2.5. MPLS-in-IP vs. MPLS-in-GRE

   The MPLS-in-IP encapsulation header is shorter than the MPLS-in-GRE
   encapsulation header, and, in theory at least, the latter offers no
   advantages to compensate for its use of a longer header.

   In practice, implementation considerations of various sorts may make
   the MPLS-in-GRE encapsulation preferable.


2.6. 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
   used.

   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



Rosen, et al.                                                  [Page 11]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   advantage to having a distinct SA for each VPN. Since the SA is PE-
   to-PE, NOT CE-to-CE, having a different SA for each VPN does not
   provide any additional privacy.  On the other hand, when multiple
   VPNs share an SA, the compromise of a key has a greater impact, and
   an attack on the security of one VPN may become an attack on the
   security of all the VPNs sharing the SA.  Nevertheless, the use of
   one SA for multiple VPNs seems to be a reasonable tradeoff of
   additional overhead against additional security.

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

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

   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
   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
   resolution).

   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



Rosen, et al.                                                  [Page 12]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   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 routers, 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 routers, it will be impossible to
   avoid the second lookup.


2.7. 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 or MPLS-in-GRE
   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:

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

      b. The packet arrived from a neighboring P or PE router as an MPLS
         packet, with no IPsec encapsulation. There are a number of
         sub-cases:

              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.





Rosen, et al.                                                  [Page 13]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


             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
                 indicating that IPsec is to be used in all cases. 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
   used.

   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
   table for each such SP. The IPsec module would then have to say, for
   each packet, which SP it came from. 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.
   Of course, all this presupposes that the VPN code is capable of
   properly populating the various lookup tables.

   It should be noted that when two PEs negotiate (via IKE) an SA, they
   specify the traffic to be covered, identifying the traffic with the
   triple <source address, destination address, protocol>.  This means
   that if any MPLS-in-IP/GRE traffic between the two addresses is sent
   through the SA, then all MPLS-in-IP/GRE traffic between the two
   addresses is sent through the SA.  If it is desired that some such



Rosen, et al.                                                  [Page 14]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


   traffic be sent in the clear, then it may be necessary to use a
   different source and/or destination address for the cleartext traffic
   than is used for the protected traffic.



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 [RFC2547bis]. 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 (Security Parameters Index) 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 field.

   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.). Failure to preserve the layering also
   complicates the situation in which the transport is sometimes IPsec
   and sometimes MPLS.  Keeping the MPLS VPN functionality in the MPLS
   layer and out of the IPsec layer certainly seems worthwhile.









Rosen, et al.                                                  [Page 15]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


4. Security Considerations

   Security considerations are discussed throughout the document.


5. IANA Considerations

   This document defines no encodings, hence there are no IANA
   considerations.


6. Acknowledgments

   The authors would like to thank Mark Duffy for his comments.


7. Authors' Addresses


     Eric C. Rosen
     Cisco Systems, Inc.
     1414 Massachusetts Avenue
     Boxborough, MA 01719
     Email: erosen@cisco.com



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



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









Rosen, et al.                                                  [Page 16]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005



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



     Chandru Sargor



8. Normative References

   [RFC2547bis] BGP/MPLS IP VPNs, Rosen et. al., draft-ietf-l3vpn-
   rfc2547bis-03.txt, October 2004


9. Informative References

   [MPLS-in-IP/GRE] "Encapsulating MPLS in IP or GRE",, Worster et. al.,
   RFC 4023, March 2005

   [MPLS-in-L2TPv3] "Encapsulation of MPLS over Layer 2 Tunneling
   Protocol Version 3", draft-ietf-mpls-over-l2tpv3-00.txt, Townsley,
   Seely, Young, October 2004

   [VPN-SPI] BGP/IPsec VPN, J. De Clercq, O. Paridaens, Y. T'Joens, C.
   Sargor, February 2001, expired internet-draft


10. Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

   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.



Rosen, et al.                                                  [Page 17]

Internet Draft     draft-ietf-l3vpn-ipsec-2547-05.txt        August 2005


11. Intellectual Property

   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.




























Rosen, et al.                                                  [Page 18]


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