Last Call Review of draft-ietf-l3vpn-end-system-04
review-ietf-l3vpn-end-system-04-secdir-lc-weis-2014-12-11-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

This subject of this document is "BGP-signaled end-system IP/VPNs”, which
defines a system where an L3VPN system is supported  on “end systems", which
means servers sitting in a data center. It describes how the L2VPN control
plane and forwarding plane can be implemented in a network virtualization
environment. Three actors are described, which together implement the L3VPN PE
role.

The security goal of the L3VPN is to maintain isolation between sets of users
(e.g., customers of a provider). A new XMPP-based signaling protocol is
described in order for two of the actors (“End System” and “End System Route
Server”) to pass IP reachability information for each set of users.

The Security Considerations section is fairly light. It should be a bit more
verbose in describing the new threats that this system have over and above a
traditional L3VPN. The following comments try to tease out what those threats
might be.

1. The first paragraph of Security Considerations says “It is important to
secure the end-system access to End-System Route Servers and the BGP
infrastructure itself.” I’m not sure if this is intended to mean that the
end-system (and it’s virtual machines) aren’t trusted and should be isolated
from the RSs and BGP infrastructure, or if this a preamble to the next
paragraph stating that the XMPP session needs to be secured.

But in either case since the L3VPN PE functionality is now no longer physically
isolated form the customer images, it is important to describe what new threats
this approach adds to the PE role.  Maybe the last paragraph in the section is
trying to make the point that there are new threats, but if so should say more
about the need for separation of virtual and infrastructure traffic. E.g., this
mitigates traffic from a  virtual machine attacking the infrastructure traffic
or creating a denial of service by clogging up the infrastructure with frames.

2. The second paragraph of Security Considerations mentions that the XMPP
session needs to be secured. It describes the use of certificates, but this
isn’t enough. Certificates need to be used with a protocol that uses
certificates for peer authentication. I think it’s common to protect XMPP with
TLS, for example so you might want to look into that. Once a peer is
authenticated with its certificate, then the router server can perform
authorization. It is important to give at least one complete example of a
method to secure the session.

3. The third paragraph of Security Considerations mentions a couple of
conventional methods for securing BGP. Is this more than what is typically
recommended within an L3VPN BGP (as opposed to a BGP speaker connected to
another provider)? If so, it would be good to say what are the additional
threats that require more security.

4. Section 6 mentions external Forwarders, and says that in this case "VPN
routing information received from the Route Server(s) SHOULD NOT be propagated
to the end-system.” Is there a security consideration here?

Brian