Last Call Review of draft-ietf-l3vpn-end-system-04

Request Review of draft-ietf-l3vpn-end-system
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-12-08
Requested 2014-11-27
Authors Stuart Mackie, Luyuan Fang, Nischal Sheth, Maria Napierala, Nabil Bitar
Draft last updated 2014-12-11
Completed reviews Genart Last Call review of -04 by Peter Yee (diff)
Secdir Last Call review of -04 by Brian Weis (diff)
Assignment Reviewer Brian Weis 
State Completed
Review review-ietf-l3vpn-end-system-04-secdir-lc-weis-2014-12-11
Reviewed rev. 04 (document currently at 06)
Review result Has Issues
Review completed: 2014-12-11


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?