An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec
draft-ietf-l3vpn-ce-based-03

[Ballot comment]
In draft-ietf-l3vpn-ce-based, Section 3.2 instead of 'secured SNMP' better use 'SNMPv3 with the security options enabled.

In draft-declercq-l3vpn-ce-based-as, Section 14.4, the following shows up:

  The CE device must support the necessary security architecture,
  allowing for eventual dual-management, firewall support etc.


This requirement is not clear, What is the 'necessary security architecture', what does dual-management mean, what kind of firewall support is required?

[Ballot discuss]
This is a borderline DISCUSS, because of the nature
of the documents. I'm hoping the below issues can
be easily addressed with an RFC Editor note. If not,
I may be persuaded to move them to COMMENTs instead.

> After completion of the IKE tear-down
> process, the peering CE devices should not attempt to re-establish
> the deleted SA.

This seems a bit extreme. CEs may have to reboot etc, and doing
so will involve IKE tear-down, at least if the devices are doing
it in a controlled manner. This should not block other CEs
from re-attempting to establish connections. In particular,
if two communicating CEs are both brought down as a part of
the same system-wide reboot/power loss, I'm not sure how they
can be brought up again.

Suggested edit: change to "After completion of the IKE
tear-down process, the CE device in question should refuse
connection attempts from its peering CE devices.", or
something to that effect.

> Note that IPsec tunnels might unintentionally terminate or break. For
> example, the CE device on one end point of an IPsec tunnel might
> fail, or one end point might become unreachable from the other end
> due to a failure of IP routing in the intermediate infrastructure.
> When dynamic routing is not supported through the inter-site VPN
> tunnels, this may have serious consequences if VPN membership and VPN
> routing information are not changed accordingly within the VPN.
> Indeed, where static routing is used the unnoticed termination of a
> VPN tunnel can result in the creation of black holes.
>
> This means that a mechanism must exist to monitor the state of the
> VPN tunnels. When dynamic inter-site VPN routing is used, the routing
> protocol that runs on top of the IPsec VPN tunnels will serve that
> purpose. When dynamic inter-site routing is not used, alternatives
> are possible such as the use of an IPsec-specific keep-alive
> mechanism [IPSEC-DPD] or a SP-proprietary mechanism.

Merely detecting the problem does not appear to be
sufficient. You also have to change the path of the
packets to some other destination. Perhaps you could
change s/[IPSEC-DPD]/[IPSEC-DPD] combined with a local
forwarding change in the device/

> Note that the CE device needs to maintain this same IP
> address (s) at least for the duration of its VPN membership.

This does not appear to be true, at least not for the
provider addresses. It would be sufficient for the
devices to acquire addresses dynamically (as the document
itself says elsewhere), as long as the central database
server knew who is where. Ongoing sessions can be moved
with IKE NAT-T or MOBIKE. Suggested edit:

Note that the CE device needs to maintain this same
IP address(es), or be capable of reporting such
changes to the central VPN database and to peers
with established connections (e.g., via [RFC 4555]).

[Ballot comment]
I agree that "for the record" disclaimer should be added to the l3vpn-ce-based draft, if it's published as is.  It's hard to read and difficult to determine exactly what it exists for.  The applicability statement document doesn't have the same level of problems.

If ietf-l3vpn-ce-based referred normatively to the individual submission (the applicability statement) for its security considerations, that would probably address some of Sam and Russ's concerns on the topic, but certainly not all.

Some further comments in case there's any energy to revise the architecture draft...

The most important aspect of this draft is that when the SP is provisioning CE devices in order to make VPNs work, the SP needs to have, and host, a lot of VPN information.  The draft talks about the SP's "VPN Server" mostly, but sometimes about the SP's "VPN database" and in a couple cases talks about downloading the VPN "configuration file". 
- The terminology should be consistent
- The chosen terminology, and associated wording, probably shouldn't assume one particular approach. A database or configuration file assumes a passive approach where the CE polls for changes, whereas another VPN provisioning solution might actually involve a controlling agent that actively pushes changes to CE devices.  "VPN Server" is probably acceptable terminology for being sufficiently vague here unless there's something specific meant by that phrase.
- The SP's VPN server, VPN Database or VPN configuration file server, whatever it is, might be *the* most important entity to show in the reference model.  The entities that do appear in the SP in the reference model, "Customer management function" and "Network management function" are never defined or explained.

Although IPSec is considered important enough to be part of the title of the draft, it's hard to see why (what impact this has on any architectural decisions) until quite far into the draft.  One thing that would be useful to know early on (e.g. extending the last paragraph of the Introduction) is exactly what part of a packet's route the IPSec protects, and who hosts the SA information.  The explanation of what part of the route is protected (and from whom) must be derived logically I think, as I couldn't find it in the draft.  The explanation of who hosts the SA information does appear later in the draft, after a bunch of material that depends on that assumption.

Figures 2 and 3 are very confusing in that the inclusion of IPSec in the diagram does not relate to the routing and forwarding logic that is being illustrated by the two figures, and thus makes the figures more complicated for no purpose.

The last paragraph in section 2.2 states that the approach enables backdoor routes between CE devices.  Are there other approaches which prevent backdoor routes? 

The sixth paragraph in section 3.4 states that a new CE establishes VPN tunnel SA's to *every peer CE device* -- a fully-connected graph. I suspect this is wrong anyway, but it's certainly inconsistent, on the face of it, with the last paragraph of section 3.4, which allows CE devices to have different roles and different numbers of connections.

There's an implication in section 3.4 (paragraph 10 starting with "Alternatively") that dynamic intra-VPN inter-site routing is always incompatible with dynamic (traffic-driven) SA establishment.  To me, that implication is not clear.  I don't know if a general reader could use an explanation there or if it's more obvious to others with more background.

BTW the assertion in the last paragraph of 4.3 was explained nicely right there.

I personally came away from reading this document without any clue how IPSec in transport mode differed from IPSec in tunnel mode.  I don't know that it's the responsibility of this draft to clear that up, but a reference would have been nice.  I agree with Sam's concern -- if the security considerations of these two approaches are different, that really needs to be called out.

Thanks -- Lisa

[Ballot discuss]
I believe two issues are not adequately documented.

First, there is a significant difference between an IPIP tunnel inside
IPsec transport mode and an IPsec tunnel mode SA.  With an IPsec
tunnel mode SA, the IPsec SPD sets access control rules.  Packets will
not be accepted into a SA unless those packets meet the SA policy.
Similarly at the receieving end the policy is checked.

However in the tunnel within transport mode SA case, the security
policy is not negotiated end-to-end by IKE.  There may be access
lists, but typically the policies are much more open than in the IPsec
tunnel case.

You also need to discuss the interactions of IPsec tunnel mode SAs
with dynamic routing protocols.  If the best path for a route becomes
over a SA that cannot accept some of the source traffic that will flow
over that path, then loops or discarded traffic can result.
Similarly, it is not clear to me that you can run dynamic routing
protocols over IPsec tunnel mode SAs.  There are all sorts of problems
doing so.  Many implementations do not treat tunnel mode SAs as
interfaces.  Many routing protocols depend on multicast or otherwise
on sending packets that would not fall within the security policy.

All these issues need to be discussed.

[Ballot comment]
I support Brian's comment, and I believe that we should generally mark documents as "for the historical record" when publishing them for that purposes.

[Ballot comment]
The writeup says "these documents are being advanced as Informational for the
historical record."

I'd be happy to see this stated in the Abstract and Introduction of both of them.

[Ballot discuss]
SecDir Review of draft-ietf-l3vpn-ce-based-03 by Angelos Keromytis
  included the following comments, and there was no response to them:
  >
  > I would urge the authors to either consider/describe SP-provisioned
  > VPNs where the authentication material are *not* obtained from the
  > Service Provider, or to spend a paragraph or two in the Security
  > Considerations section discussing the risk posed by malicious SPs
  > (or malicious employees thereof).  Similar concerns arise with some
  > of the configuration parameters that the SP supplies (e.g.,
  > encryption algorithm) ...perhaps it would be wise to discuss how a
  > customer may verify that the tunnels are set up according to
  > policy / service agreement?  If the SP is trusted to not misbehave
  > (for the purposes of this document), that should be clearly stated
  > early on.
  >
  Please add the requested discussion to the Security Considerations.

  SecDir Review of draft-ietf-l3vpn-ce-based-03 by Barbra Fraser
  included the following comments, and there was no response to them:
  >
  > The document is silent about establishing unique authentication 
  > per customer or customer-edge device. It should be clearly stated 
  > that the service provider should not use the same credentials for 
  > multiple customers.
  >
  At a minimum, this should be discussed in the Security Considerations.

  Barbara also said (and, again there was no reply):
  >
  > The security considerations section is light and points to another 
  > document, RFC4111. However, I looked at RFC4111 and there is nothing 
  > in the document that relates the various threats and risks to a CE-
  > based provider provisioned IPsec VPN. So, if this document is to go 
  > forward, it should include relevant content from RFC4111 since 
  > there's no way for RFC4111 to be amended to make it clear which 
  > threats/risks apply to CE-based VPNs.
  >
  One way to handle this might be to point to the PPVPN discussion, and
  indicate which aspects apply to CE-based solutions.

  Barbara also said (and, again there was no reply):
  >
  > The security considerations section should, in addition to 
  > describing the fact that the SP controls keys, etc.,  also include 
  > something along the lines of: the security of this solution will be 
  > affected by the practices of the service provider, since the service 
  > provider has access to the CE device, and therefore access to the 
  > unencrypted traffic. It's very likely that staff access to the 
  > credential db/PKI/whatever will be more restricted than staff access 
  > to arbitrary provider-controlled CE boxes.
  >
  Please add a short discussion of this issue to the Security
  Considerations section.

  Tero Kivinen made the following comments on
  draft-declercq-l3vpn-ce-based-as-00, and there was no response to them:
  >
  > 13. QoS, SLA
  >
  > Note, that if packets having different QoS parameters are put inside
  > one IPsec SA tunnel, and the packets are really processed differently
  > by the network, this may cause the responder to drop all low priority
  > packets as the high priority packets which have passed those low
  > priority packets in the network have already made replay window to go
  > too far. I.e. low priority packets might take too long to travel
  > inside the network so that when they finally end to the destination
  > the destination cannot process them as they are outside the replay
  > protection window.
  >
  > The solution to this in the RFC 4301 IPsec Security Architecture is to
  > create multiple IPsec SAs between the nodes and send only traffic
  > having similar QoS parameters to one SA.
  >
  > This does affect the scalability (i.e. section 12) as it raises the
  > number of IPsec SAs, but each of those IPsec SA can share the same IKE
  > SA and interface, routing information etc.
  >
  > I think something about this should be mentioned in the section 13.
  >
  Please add a discussion of this issue to the document.

  Tero also pointed out:
  >
  > The references section does not have normative / informative
  > references split, and I think it should have references at least to
  > IPsec architecture RFC 4301, and IKEv2 RFC 4306.
  >
  Please add the needed references, and put the normative references in
  one section and the informative references in another section.

[Ballot comment]
SecDir Review of draft-ietf-l3vpn-ce-based-03 by Angelos Keromytis
  included the following comment:
  >
  > Nit: in Section 5, you probably don't mean "LAN network" (which is
  > redundant, anyway) but "CE network" or something similar instead.

  Tero Kivinen made the following comments on
  draft-declercq-l3vpn-ce-based-as-00:
  >
  > This document really should expand CE when it is used first time in
  > the abstract...
  >
  This comment applies to draft-ietf-l3vpn-ce-based-03 as well.

[Ballot discuss]
SecDir Review of draft-ietf-l3vpn-ce-based-03 by Angelos Keromytis
  included the following comments, and there was no response to them:
  >
  > I would urge the authors to either consider/describe SP-provisioned
  > VPNs where the authentication material are *not* obtained from the
  > Service Provider, or to spend a paragraph or two in the Security
  > Considerations section discussing the risk posed by malicious SPs
  > (or malicious employees thereof).  Similar concerns arise with some
  > of the configuration parameters that the SP supplies (e.g.,
  > encryption algorithm) ...perhaps it would be wise to discuss how a
  > customer may verify that the tunnels are set up according to
  > policy / service agreement?  If the SP is trusted to not misbehave
  > (for the purposes of this document), that should be clearly stated
  > early on.
  >
  Please add the requested discussion to the Security Considerations.

  SecDir Review of draft-ietf-l3vpn-ce-based-03 by Barbra Fraser
  included the following comments, and there was no response to them:
  >
  > The document is silent about establishing unique authentication 
  > per customer or customer-edge device. It should be clearly stated 
  > that the service provider should not use the same credentials for 
  > multiple customers.
  >
  At a minimum, this should be discussed in the Security Considerations.

  Barbara also said (and, again there was no reply):
  >
  > The security considerations section is light and points to another 
  > document, RFC4111. However, I looked at RFC4111 and there is nothing 
  > in the document that relates the various threats and risks to a CE-
  > based provider provisioned IPsec VPN. So, if this document is to go 
  > forward, it should include relevant content from RFC4111 since 
  > there's no way for RFC4111 to be amended to make it clear which 
  > threats/risks apply to CE-based VPNs.
  >
  One way to handle this might be to point to the PPVPN discussion, and
  indicate which aspects apply to CE-based solutions.

  Barbara also said (and, again there was no reply):
  >
  > The security considerations section should, in addition to 
  > describing the fact that the SP controls keys, etc.,  also include 
  > something along the lines of: the security of this solution will be 
  > affected by the practices of the service provider, since the service 
  > provider has access to the CE device, and therefore access to the 
  > unencrypted traffic. It's very likely that staff access to the 
  > credential db/PKI/whatever will be more restricted than staff access 
  > to arbitrary provider-controlled CE boxes.
  >
  Please add a short discussion of this issue to the Security
  Considerations section.

  Tero Kivinen made the following comments on
  draft-declercq-l3vpn-ce-based-as-00, and there was no response to them:
  >
  > 13. QoS, SLA
  >
  > Note, that if packets having different QoS parameters are put inside
  > one IPsec SA tunnel, and the packets are really processed differently
  > by the network, this may cause the responder to drop all low priority
  > packets as the high priority packets which have passed those low
  > priority packets in the network have already made replay window to go
  > too far. I.e. low priority packets might take too long to travel
  > inside the network so that when they finally end to the destination
  > the destination cannot process them as they are outside the replay
  > protection window.
  >
  > The solution to this in the RFC 4301 IPsec Security Architecture is to
  > create multiple IPsec SAs between the nodes and send only traffic
  > having similar QoS parameters to one SA.
  >
  > This does affect the scalability (i.e. section 12) as it raises the
  > number of IPsec SAs, but each of those IPsec SA can share the same IKE
  > SA and interface, routing information etc.
  >
  > I think something about this should be mentioned in the section 13.
  >
  Please add a discussion of this issue to the document.

  Tero also pointed out:
  >
  > The references section does not have normative / informative
  > references split, and I think it should have references at least to
  > IPsec architecture RFC 4301, and IKEv2 RFC 4306.
  >
  Please add the needed references, and put the normative references in
  one section and the informative references in another section.

  COMMENT

  SecDir Review of draft-ietf-l3vpn-ce-based-03 by Angelos Keromytis
  included the following comment:
  >
  > Nit: in Section 5, you probably don't mean "LAN network" (which is
  > redundant, anyway) but "CE network" or something similar instead.

  Tero Kivinen made the following comments on
  draft-declercq-l3vpn-ce-based-as-00:
  >
  > This document really should expand CE when it is used first time in
  > the abstract...
  >
  This comment applies to draft-ietf-l3vpn-ce-based-03 as well.

[Note]: 'draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together, currently this draft is gated by draft-declercq. Rick on the Hook to see if the PROTO is up to date' added by Mark Townsley

[Note]: 'draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together, currently this draft is gated by draft-declercq.

Rick on the Hook to see if the PROTO is up to date' added by Mark Townsley

PROTO

> Date: Wed, 21 Dec 2005 10:53:44 -0500
> To: townsley@cisco.com, margaret@thingmagic.com, zinin@psg.com
> From: Ross Callon
> Subject: draft-ietf-l3vpn-ce-based-03.txt
> Cc: rick.wilder@alcatel.com, rbonica@juniper.net, rcallon@juniper.net
>
>
>    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.
>
>    1.b) Has the document had adequate review from both key WG members
>        and key non-WG members?
>
> Yes.
>
>        Do you have any concerns about the
>        depth or breadth of the reviews that have been performed?
>
> I think that the security ADs should take a quick look at this. I
> believe that the use of IPsec is straightforward and follows
> existing practice. Nonetheless I am not sufficiently versed in
> IPsec details to verify this, and similarly I do not assume that
> the L3VPN working group has encryption expertise.
>
>    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.)?
>
> I feel that the security ADs should look at this.
>
>    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. 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 straightforward document which I believe is well understood.
>
> There is some difference of opinion regarding the best way to support
> L3 VPN services. Some providers prefer to use CE-based devices
> (where each CE-based device is dedicated to a particular VPN), with
> IPSec used between CE devices. This approach has been deployed
> for many years. This document provides an informational description
> of how this approach works.
>
>    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. There were no problems found.
>
>    1.h) Is the document split into normative and informative references?
>
> All references are listed as informational.
>
>        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.
>
>    1.i) For Standards Track and BCP documents, the IESG approval
>        announcement includes a write-up section with the following
>        sections:
>
>        *    Technical Summary
>
> This informational document describes how a service provider can
> supply VPN services using provider-provisioned CE-based devices
> which make use of IPsec for tunneling across the provider network
> between the CE based devices.
>
>        *    Working Group Summary
>
> There are no WG conflicts regarding this draft.
>
>        *    Protocol Quality
>
> My personal opinion is that this draft is well done.

[Note]: '2004-08-25: draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together. Need to better
understand what wording/changes are needed to make clear that these
documents are not a protocol spec from which one can achieve
interoperability. Waiting for WG Chair Writeup. Pinged chairs 2/20/2006.
' added by Mark Townsley

[Note]: '2004-08-25: draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together. Need to better
understand what wording/changes are needed to make clear that these
documents are not a protocol spec from which one can achieve
interoperability. Waiting for WG Chair Writeup. Pinged chairs 2/20/2006.
' added by Mark Townsley

[Note]: '2004-08-25: draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together. Need to better
understand what wording/changes are needed to make clear that these
documents are not a protocol spec from which one can achieve
interoperability. Waiting for WG Chair Writeup.
' added by Mark Townsley

-------- Original Message --------
Subject: Re: draft-ietf-l3vpn-ce-based-02.txt
Date: Wed, 21 Sep 2005 20:36:11 -0400
From: Ross Callon
To: Mark Townsley
CC: rcallon@juniper.net, Rick Wilder , Ronald Bonica


For this one the author is (unless I am confused) in the process
of updating this based on comments that I sent a few weeks ago.

I will wait for the update before sending in the writeup.

I forwarded the list of nits just a few minutes ago, which of
course should also be fixed in the same update.

Thanks, Ross

At 06:17 PM 9/18/2005 +0200, Mark Townsley wrote:

>Writeup for this one as well.
>
>Thanks,
>
>- Mark

[Note]: '2004-08-25: draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together. Need to better
understand what wording/changes are needed to make clear that these
documents are not a protocol spec from which one can achieve
interoperability.

Waiting for WG Chair Writeup.
' added by Mark Townsley

State Change Notice email list have been change to rick@rhwilder.net, rcallon@juniper.net, rbonica@juniper.net, jeremy.de_clercq@alcatel.be, olivier.paridaens@alcatel.be, cliff.wang@us.army.mil from rick@rhwilder.net, rcallon@juniper.net, ronald.p.bonica@mci.com, jeremy.de_clercq@alcatel.be, olivier.paridaens@alcatel.be, cliff.wang@us.army.mil

[Note]: '2004-08-25: draft-ietf-l3vpn-ce-based-02.txt &
draft-declercq-l3vpn-ce-based-as-00.txt go together. Need to better
understand what wording/changes are needed to make clear that these
documents are not a protocol spec from which one can achieve
interoperability.
' added by Thomas Narten