Re: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04

["Adrian Farrel" <[e-mail]>]

Thanks Brian,

Authors: please develop updates or a response.

Thanks,
Adrian

> -----Original Message-----
> From: iesg [mailto:[e-mail]] On Behalf Of Brian Weis (bew)
> Sent: 09 December 2014 03:19
> To: [e-mail]; The IESG
> Cc: [e-mail]
> Subject: Secdir review of draft-ietf-l3vpn-end-system-04
> 
> 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
>