Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks
draft-ietf-l3vpn-gre-ip-2547-05

Met with Sam in person on 6/28/2006 to discuss how to move forward. Proposed advacing this document and the ipsec-2547 document forward as Experimental. Sam said he would writeup text that would help satisfy the secdir's security considerations, assuming that the gre-ip and ipsec documents would both move forward as experimental.

PROTO

-------- Original Message --------
Subject: NITs checked, Re: draft-ietf-l3vpn-gre-ip-2547-05.txt
Date: Sat, 17 Dec 2005 23:14:20 -0500
From: Ross Callon
To: townsley@cisco.com, margaret@thingmagic.com, zinin@psg.com
CC: Rick Wilder , rbonica@juniper.net, rcallon@juniper.net


A small update to my writeup regarding draft-ietf-l3vpn-gre-ip-2547-05.txt.

I have now run the automated Idnits tool, and the draft checks out
fine with no nits found.

Thanks, Ross

At 11:49 PM 12/16/2005 -0500, Ross Callon wrote:
>    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, Ross has reviewed the specification. Ron is co-author.
>
>    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?
>
>Yes, I believe so.
>
>    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
>
>In the past there was inadequate discussion of security issues,
>particularly wrt spoofed packets. I believe that the text that has
>been recently added clears up this deficiency. Otherwise the
>approach is pretty straightforward and well documented.
>
>    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?
>
>This is a pretty simple document which I believe is well understood.
>
>Most deployments of BGP/MPLS L3 VPNs will use MPLS on a PE
>to P to PE basis, and thus won't need this approach.
>
>There have in the past been service providers interested in providing
>BGP/MPLS L3 VPNs over an IP-only core. This has become of less
>interest as MPLS is more widely deployed. I think that in those rare
>cases that anyone wants to do this, the approach outlined in this
>document is accepted as the right way forward. This *might* become
>more important in the future as inter-AS VPNs become more common
>(ie, if service providers are nervous about inter-domain LSPs -- although
>there are other options where MPLS is used within a domain, but
>not between domains).
>
>    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).
>
>Not yet. I will do this.
>
>    1.h) Is the document split into normative and informative references?
>
>There are normative references. There are no informative references.
>Looking over the documents referenced, I agree that these should
>be normative.
>
>        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.)
>
>No. The only ID to which there is an normative reference is
>already in the RFC editors queue (other references are to RFCs).
>
>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
>This draft describes an implementation strategy for BGP/MPLS Layer 3
>Virtual Private Networks (VPNs) in which the outermost MPLS label
>(i.e., the tunnel label) is replaced with either an IP header or an IP header
>with Generic Routing Encapsulation (GRE). This enables the deployment
>of BGP/MPLS IP VPN technology in networks whose edge devices are
>MPLS and VPN aware, but whose interior devices are not.
>
>        *    Working Group Summary
>
>There are no WG conflicts regarding this draft.
>
>        *    Protocol Quality
>
>My personal opinion is that this draft is well done.

  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, Ross has reviewed the specification. Ron is co-author.

  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?

Yes, I believe so.

  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

In the past there was inadequate discussion of security issues,
particularly wrt spoofed packets. I believe that the text that has
been recently added clears up this deficiency. Otherwise the
approach is pretty straightforward and well documented.

  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?

This is a pretty simple document which I believe is well understood.

Most deployments of BGP/MPLS L3 VPNs will use MPLS on a PE
to P to PE basis, and thus won't need this approach.

There have in the past been service providers interested in providing
BGP/MPLS L3 VPNs over an IP-only core. This has become of less
interest as MPLS is more widely deployed. I think that in those rare
cases that anyone wants to do this, the approach outlined in this
document is accepted as the right way forward. This *might* become
more important in the future as inter-AS VPNs become more common
(ie, if service providers are nervous about inter-domain LSPs -- although
there are other options where MPLS is used within a domain, but
not between domains).

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

Not yet. I will do this.

  1.h) Is the document split into normative and informative references?

There are normative references. There are no informative references.
Looking over the documents referenced, I agree that these should
be normative.

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

No. The only ID to which there is an normative reference is
already in the RFC editors queue (other references are to RFCs).

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

        *    Technical Summary

This draft describes an implementation strategy for BGP/MPLS Layer 3
Virtual Private Networks (VPNs) in which the outermost MPLS label
(i.e., the tunnel label) is replaced with either an IP header or an IP header
with Generic Routing Encapsulation (GRE). This enables the deployment
of BGP/MPLS IP VPN technology in networks whose edge devices are
MPLS and VPN aware, but whose interior devices are not.

        *    Working Group Summary

There are no WG conflicts regarding this draft.

        *    Protocol Quality

My personal opinion is that this draft is well done.

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, yakov@juniper.net, erosen@cisco.com from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, yakov@juniper.net, erosen@cisco.com

[Ballot comment]
I wish Defers resulted in showing the document as returning (even one as memorious as I
can forget :)

I'm going to give a No (Further) Objection, but as TSV, my concern is with the
non-statement of the additional dilution of possible QoS interactions.  2547 is
a routing technology, but 2547 has a comment about constructing QoS or TE
based on managing the MPLS in the customer premises and linking it to TE or
QoS measures in the Service Provider.  (See below for the section from 2547bis,
which states that QoS is a key factor for VPN use, as its first sentence).  If there
is a dynamic, who-knows-what-nature, tunnel hop, that is invisible and unannounced
to the customer, then 2547bis with these tunnels has lower service potentials than
2547bis without them.  The paragraph:

  Although not the focus of this paper, Quality of Service is a key
  component of any VPN service.  In MPLS/BGP VPNs, existing L3 QoS
  capabilities can be applied to labeled packets through the use of the
  "experimental" bits in the shim header [MPLS-ENCAPS], or, where ATM
  is used as the backbone, through the use of ATM QoS capabilities.
  The traffic engineering work discussed in [MPLS-RSVP] is also
  directly applicable to MPLS/BGP VPNs.  Traffic engineering could even
  be used to establish label switched paths with particular QoS
  characteristics between particular pairs of sites, if that is
  desirable.  Where an MPLS/BGP VPN spans multiple SPs, the
  architecture described in [PASTE] may be useful.  An SP may apply
  either intserv (Integrated Services) or diffserv (Differentiated
  Services) capabilities to a particular VPN, as appropriate.

[Ballot discuss]
This protocol does not seem to have a mandatory-to-implment secure
mode of operation.  It doesn't even really seem to have an
optional-to-implement mode of operation  that  provides security
similar to the  existing MPLS VPN solutions. 

Steve/Russ's discuss imply that the problem can be fixed with security
considerations text similar to that in section 8.1 of
draft-ietf-mpls-in-ip.    I don't think this is true.    I think you
need all the detail of draft-ietf-l3vpn-ipsec-2547, which appears to
be a good start at the solution to the security problems of this
draft. 

Proposals for going forward:

1) Finish up draft-ietf-ipsec-2547 and add an optional mode where
GRE/IP or IP/IP is used but no IPsec is applied.

2) Describe the problems with this approach and publish as
informational pointing to option 1 as a long-term solution once it is
finished.

[Ballot comment]
I am abstaining because I can't figure out whether this is something with "no more danger than what people ordinarily do" or something that exposes users to a significant additional risk.

Reviewed by Mary Barnes, Gen-ART

Her review:

Overall, from an editorial perspective, this document appears ready for publication. However, although I'm not an SME in this area, I too share some of the concerns and comments raised around the security issues and the limited applicability (single SP).  I would think publishing this as Informational/BCP as to how one could do this sort of functionality if it were deemed useful in this restrictive situation would be better than publishing as Proposed Standard.

[Ballot discuss]
I agreed to pick up Steve Bellovin's DISCUSS.  He said:

    This spec scares me.  Section 6 more or less says "if you don't get
    this right you're risking all sorts of trouble, and it's very hard
    to get this right."
   
    Not only must all inputs to the provider network filter out all
    packets with such source addresses, the MPLS label inside a packet
    must correspond to the source address of that packet.  Otherwise,
    anyone can spoof anyone else.

[Ballot comment]
> 4. Motivations
...
>  In this procedure, the ingress and egress PE routers themselves MUST
>  support MPLS, but that is not an issue, as those routers MUST
>  necessarily have BGP/MPLS IP VPN support, whereas the transit routers
>  arguably should be able to be "vanilla" routers with no special MPLS
>  or VPN support.

The two upper-case MUSTs above don't seem to be normative and should be
lower-cased.

[Ballot comment]
From Pekka Savola, OPS directorate:

I share Steve's concerns (in the tracker).

FWIW, I tried to get some better text in
draft-ietf-mpls-in-ip-or-gre-08.txt (which is used as a building block
here) which would have somewhat mitigated the problems (so that packet
injection would have been impossible inside single-provider networks),
but in the end I was overrun.

(I think that spec needed better discussion of source/destination
address spoofing concerns, and I'd have wanted to require that the
decapsulators check that the source address of the tunnel packet is
coming from a valid peer (=source address), not just anyone at all.)

[Ballot comment]
This text in section 6:

  The filtering described in the previous paragraph works only within a
  single SP network. It is not clear whether (and how) this filtering
  could be extended to support multiple SP networks. That makes the
  scheme described in this document fairly problematic in the multi-
  provider environment. makes me wonder at the overall utility of this.

causes me to abstain from this document.  I am generally concerned with
the over-dependence on tunnels and overlay networks, and this restriction
just convinces me the utlity of this is too small.

[Ballot discuss]
This spec scares me.  Section 6 more or less says "if you don't get this right you're risking all sorts of trouble, and it's very hard to get this right."

Not only must all inputs to the provider network filter out all packets with such source addresses, the MPLS label inside a packet must correspond to the source address of that packet.  Otherwise, anyone can spoof anyone else.