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

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

  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.

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.