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

"Adrian Farrel" <> Tue, 09 December 2014 12:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EDBE1A0451; Tue, 9 Dec 2014 04:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8cvg7jaG8O6o; Tue, 9 Dec 2014 04:58:39 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C12581A0382; Tue, 9 Dec 2014 04:58:38 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id sB9CwXtJ020027; Tue, 9 Dec 2014 12:58:34 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id sB9CwWOc019954 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 12:58:33 GMT
From: "Adrian Farrel" <>
To: "'Brian Weis \(bew\)'" <>, <>, "'The IESG'" <>
References: <>
In-Reply-To: <>
Date: Tue, 9 Dec 2014 12:58:28 -0000
Message-ID: <03b501d013af$d3d831b0$7b889510$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIJn+TKigYJrUPuhhBd0T9Q0sVJqZwUH0WQ
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--16.562-10.0-31-10
X-imss-scan-details: No--16.562-10.0-31-10
X-TMASE-MatchedRID: rYpa/RC+czGnykMun0J1wlaOpp/sV5nVOhJ9m53n4aB94HxmQFPHy80y BterFDqMTWLw2jvbfpxcQYBu5oPw5eyt+a9Mtf+eY1bQMCMvmn5u/Xr6CKXiN+lbXcFLWE8Nnyh q6lBOGcPxffyXmzOSajaRX1a76aO+fmfYZ4AgHuf87vS8PQu3wEDwj88nLgRT+fSAR8SgE2/2Ff tIOGQdVRamW28UkvWj1DnYAC+kmPQLazoQyrpm0mgws6g0ewz2IWrhso05H/UoDMZ3xV44iAdqb 5fC0EclT5dYubiiJHlbi0xMSjgYy/c+5H0kOor6bO8iLwtqcBpimi8LvNfmr23D6f6IpbLIjIPC JAAhgXOJbzYit3edRXUnFuXHTdk7EZG6oCaQzfaIED/RsFAua1AI6wCVrE3vyPQR7DhM3jbSnGT DBuqUfUjH681EJoCobxvtht9+1IqmR/fjfo0BcBMxKDqgAFSzq8zHTxACKxZfIVH4zHfuZxr7Fy aVZKQrHijGu6j9ufeDGa0p6svLIwx5TL3qCTgEngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcRA JRT6POOhzOa6g8KrXDnVpFD1AD09WJqbyZEN6TGgkAWKBZcDRE7qfqKIrKQ/oFj1EY1BAs=
Subject: Re: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Dec 2014 12:58:41 -0000

Thanks Brian,

Authors: please develop updates or a response.


> -----Original Message-----
> From: iesg [] On Behalf Of Brian Weis (bew)
> Sent: 09 December 2014 03:19
> To:; The IESG
> Cc:
> Subject: Secdir review of draft-ietf-l3vpn-end-system-04
> I have reviewed this document as part of the security directorate's ongoing
> to review all IETF documents being processed by the IESG. These comments
> were written primarily for the benefit of the security area directors.
> editors and WG chairs should treat these comments just like any other last
> 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
> 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
> in describing the new threats that this system have over and above a
> 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
> 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
> 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
> session needs to be secured.
> But in either case since the L3VPN PE functionality is now no longer
> isolated form the customer images, it is important to describe what new
> 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.,
> mitigates traffic from a  virtual machine attacking the infrastructure traffic
> 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
> enough. Certificates need to be used with a protocol that uses certificates
> 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
> 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
> that require more security.
> 4. Section 6 mentions external Forwarders, and says that in this case "VPN
> information received from the Route Server(s) SHOULD NOT be propagated to
> the end-system." Is there a security consideration here?
> Brian