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

State Change Notice email list have been change to <tme@multicasttech.com>, <danny@arbor.net>, <rcallon@juniper.net> from <rick@rhwilder.net>, <rcallon@juniper.net>, <ronald.p.bonica@mci.com>

More detail on Russ' Discuss, with emphasis on what is actionable by the authors

-------- Original Message --------
Subject: Re: draft-ietf-l3vpn-ipsec-2547-05.txt
Date: Tue, 16 Jan 2007 13:17:58 -0500
From: Russ Housley
To: Mark Townsley
References: <45AD07ED.1070901@cisco.com>



= = = = = = = = =

> Russ Housley:
> Discuss:
> [2006-01-19]
>  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.

This is clearly actionable.  I'm willing to move it to a comment, but
that cannot be the reason for inactivity.

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

This seems actionable.  Do I need to propose an alternate title?

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

If I am correct, then say that IPsec ESP will encapsulate the MPLS
traffic, and make RFC 4303 a normative reference.

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

I think the action is clear here.  I'm willing to be talked out of a
diagram, but the stacks that are supported based on the text in
section 2 seem to be:

- IP/ESP/IP/MPLS (with VPN route label)

- IP/ESP/GRE/MPLS (with VPN route label)

I would expect that the Introduction to match this level of description,
but there is no mention of the MPLS-in-IP or MPLS-in-GRE encapsulation.

>  * 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?

This seems very clear to me.  I cannot think of anything to add.

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

Without the discussion, it is not clear that the document is providing a
solution that provides anti-spoofing.  I included this point so that the
authors can think about it when figuring out how to handle the SPD.

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

Maybe I am wrong.  Maybe the intent is to set up SAD entries.  If so,
tell me, and we will figure out the way forward.

>  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?

Two points here.  First, there seems to be a disconnect with RFC 4301 and
this document.  In RFC 4301, an SA offers a set of services for the
traffic, but the same services need to be applied to all of the packets
associated with that SA.  Second, I cannot understand why one would
ever want encryption without authentication.  I can understand why one
might want authentication without encryption.  So, I would like to see
Section 2.3 say: "It is conceivable that an egress PE will want some of
its IPsec-secured IP-tunneled VPN traffic to be authenticated and
encrypted, but will want some to be authenticated and not encrypted."
If this is done by selecting the appropriate SA, then there seems to be
a way forward that is compatible with RFC 4301.

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

I cannot think of anything to add to this comment.

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

I am asking for an explanation of the access control decisions that are
made by IPsec implementations and the access control decisions that are
made by other elements of the architecture.  I am also asking about the
information needed to make these access control decisions.  RFC 4301
provides this for IPsec, and it does not include MPLS labels as
selectors.  So, this must be in the other part.

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

I cannot think of anything to add to this comment.

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

I cannot think of anything to add to this comment.  I'm willing to
talk further about any one of these bullets, but they all relate to
this specification being used in a bigger system.

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

What bad things happen if the configuration is messed up?

> Comment:
> [2006-01-19]
>  If this document were on the standards-track, additional concerns
>  would be raised.  Since this document is intended for experimental,
>  these comments are provided for the authors consideration.

Heads up.  If this were on standards track, then the DISCUSS comments
would have been even longer.  I'm not sure there is anything to add.

>  Section 2.3 refers to "IPsec tunnels" even though earlier text says
>  that transport mode is to be used.  Presumably the Section 2.3
>  ought to refer to a GRE or IP tunnel, not an IPsec tunnel.
>
>  How does diff-serv fit?  If there is QoS or TE promised for any VPN,
>  the proposal for encapsulation in one IPsec tunnel needs to consider
>  how diff-serv signaling is handled.  RFC 4023 makes note of the
>  similarity of MPLS-in-IP and MPLS-in-GRE tunnels to IP-in-IP tunnels
>  described in RFC 2893, stating that the same considerations apply.
>  RFC 2893 says that, depending on the choice of pipe model or uniform
>  model, the DSCP at the egress of the tunnel might be the inner header
>  DSCP or the outer header DSCP.  RFC 3270 says that the MPLS shim EXP
>  field may encode PHB behavior, which can be mapped to DSCP behavior
>  at the egress.  So, has any consideration been given to the handling
>  if a packet with a DSCP is assigned to an MPLS LSP, which is then
>  encapsulated in IP and then assigned to an IPsec SA?  Perhaps the
>  view is that the other RFCs that cover these considerations of
>  diff-serv.  I'm not sure.
>
>  How is improper VPN joining prevented?  There is an opportunity for
>  a misconfigured router to join a VPN that it should not have joined
>  by attaching an export RT it should not be using to a route
>  announcement.  The reliance on careful configuration of the SP it
>  seems to me makes the system fragile to errors.  If a VPN crosses SP
>  boundaries, then a misconfiguration in one SP might result in effects
>  in the other SP.  There is an opportunity to avoid this situation by
>  attaching authorization to an IPsec SA.  If a single SA is established
>  between two PEs, intended to carry traffic for all VPNs common between
>  the two, then the credentials communicated in the SA establishment
>  might negotiate all the VPNs that the SA is intended to carry.  An
>  unauthorized VPN in subsequent traffic could cause the traffic to be
>  dropped.  This might be a security policy setting for the SA.
>  Unfortunately, this would also mean that the SA's list of allowed
>  VPNs would have to be updated as PEs joined new VPNs.  There is
>  already discussion of using route refresh to communicate a newly
>  available RT (as a result of 'a "VPN Join" operation'), so dynamics
>  like this are possible. If multiple SAs are established between two
>  PEs, one for each VPN, then the credentials could be affiliated with
>  authorization to join a particular VPN, and allow the establishment
>  of the SA.  This means that joining or leaving a VPN would not
>  require changes in the settings of other SAs.

[Ballot comment]
I agree with Russ's discuss.

One way to address the concerns about SPD configuration and IPsec
policy may be to include enough information in the extended community
attribute to configure the PAD and SPD.  This would probably include
the identity of the peers involved as well as enough information to
know what IP addresses would be used so the PAD entries could be
created.


I do wish the working group the best of luck in addressing these
issues; I believe this document is critical to providing customers
with an optionn for cryptographically isolated VPNs.

[Ballot comment]
If this document were on the standards-track, additional concerns
  would be raised.  Since this document is intended for experimental,
  these comments are provided for the authors consideration.

  Section 2.3 refers to "IPsec tunnels" even though earlier text says
  that transport mode is to be used.  Presumably the Section 2.3
  ought to refer to a GRE or IP tunnel, not an IPsec tunnel.

  How does diff-serv fit?  If there is QoS or TE promised for any VPN,
  the proposal for encapsulation in one IPsec tunnel needs to consider
  how diff-serv signaling is handled.  RFC 4023 makes note of the
  similarity of MPLS-in-IP and MPLS-in-GRE tunnels to IP-in-IP tunnels
  described in RFC 2893, stating that the same considerations apply.
  RFC 2893 says that, depending on the choice of pipe model or uniform
  model, the DSCP at the egress of the tunnel might be the inner header
  DSCP or the outer header DSCP.  RFC 3270 says that the MPLS shim EXP
  field may encode PHB behavior, which can be mapped to DSCP behavior
  at the egress.  So, has any consideration been given to the handling
  if a packet with a DSCP is assigned to an MPLS LSP, which is then
  encapsulated in IP and then assigned to an IPsec SA?  Perhaps the
  view is that the other RFCs that cover these considerations of
  diff-serv.  I'm not sure.

  How is improper VPN joining prevented?  There is an opportunity for
  a misconfigured router to join a VPN that it should not have joined
  by attaching an export RT it should not be using to a route
  announcement.  The reliance on careful configuration of the SP it
  seems to me makes the system fragile to errors.  If a VPN crosses SP
  boundaries, then a misconfiguration in one SP might result in effects
  in the other SP.  There is an opportunity to avoid this situation by
  attaching authorization to an IPsec SA.  If a single SA is established
  between two PEs, intended to carry traffic for all VPNs common between
  the two, then the credentials communicated in the SA establishment
  might negotiate all the VPNs that the SA is intended to carry.  An
  unauthorized VPN in subsequent traffic could cause the traffic to be
  dropped.  This might be a security policy setting for the SA.
  Unfortunately, this would also mean that the SA's list of allowed
  VPNs would have to be updated as PEs joined new VPNs.  There is
  already discussion of using route refresh to communicate a newly
  available RT (as a result of 'a "VPN Join" operation'), so dynamics
  like this are possible. If multiple SAs are established between two
  PEs, one for each VPN, then the credentials could be affiliated with
  authorization to join a particular VPN, and allow the establishment
  of the SA.  This means that joining or leaving a VPN would not
  require changes in the settings of other SAs.

[Ballot discuss]
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.

Proto Questionairre

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

        Yes

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

        The document has passed WG last call. Mark Duffy also reviewed
        the document.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

        No

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

        No

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

        All those who were interested approved. None objected.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

        No


  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

        Yes.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

        There is a normative reference to rfc2547bis. However, the
        referenced document is in the RFC editors queue and should
        be published soon.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

        N.A. This document is to be published as EXPERIMENTAL

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

  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.

  1.k) Note:

  I believe that this technology has been deployed, if not widely.