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

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 09 December 2014 12:58 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBE1A0451; Tue, 9 Dec 2014 04:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cvg7jaG8O6o; Tue, 9 Dec 2014 04:58:39 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12581A0382; Tue, 9 Dec 2014 04:58:38 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id sB9CwXtJ020027; Tue, 9 Dec 2014 12:58:34 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (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" <adrian@olddog.co.uk>
To: "'Brian Weis \(bew\)'" <bew@cisco.com>, <secdir@ietf.org>, "'The IESG'" <iesg@ietf.org>
References: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com>
In-Reply-To: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com>
Date: Tue, 9 Dec 2014 12:58:28 -0000
Message-ID: <03b501d013af$d3d831b0$7b889510$@olddog.co.uk>
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-7.1.0.1576-7.5.0.1018-21160.007
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=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/I6OwU--SZmehLWVgIXq877egIpY
Cc: draft-ietf-l3vpn-end-system.all@tools.ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 12:58:41 -0000

Thanks Brian,

Authors: please develop updates or a response.

Thanks,
Adrian

> -----Original Message-----
> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Brian Weis (bew)
> Sent: 09 December 2014 03:19
> To: secdir@ietf.org; The IESG
> Cc: draft-ietf-l3vpn-end-system.all@tools.ietf.org
> 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
>