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

"Brian Weis (bew)" <bew@cisco.com> Tue, 09 December 2014 03:18 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B810A1A07BE; Mon, 8 Dec 2014 19:18:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iTJHIyVC3cm5; Mon, 8 Dec 2014 19:18:40 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9C51A0052; Mon, 8 Dec 2014 19:18:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3513; q=dns/txt; s=iport; t=1418095121; x=1419304721; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=i/2ZWO8TBuY2dxgsigqaAFIy6FULfhJxwLL4j0v/ZJk=; b=Ddhx19abiYsfO4ulJjK0SUwpDqhAT7wxWzxemQKCjGrmoo24r5AcfzHg p5FP/tApxiUuMhRsYXVd82V5Z2Lxq89F3DTtzryBl8kWklPXEMfyVzwlI tl2Tpw9tbVebO/eeUe9chSTfo+H3X25J/PzdT81DyCUi5/CxLCbdP47vX s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,542,1413244800"; d="scan'208";a="103833958"
Received: from alln-core-6.cisco.com ([]) by alln-iport-1.cisco.com with ESMTP; 09 Dec 2014 03:18:40 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com []) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB93IdcW009606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 03:18:39 GMT
Received: from xmb-aln-x04.cisco.com ([]) by xhc-rcd-x08.cisco.com ([]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 21:18:38 -0600
From: "Brian Weis (bew)" <bew@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-l3vpn-end-system-04
Thread-Index: AQHQE17Th68HkvC4CUyzb2E6TowKjg==
Date: Tue, 9 Dec 2014 03:18:38 +0000
Message-ID: <6BAB7B9A-1A70-4957-ADC2-1836F22A4219@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <A9FEB155E2537C41BC8C7218FCCEC9CB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EBaz-JicYlyFOxgXJ6QO7Ow2XKU
Cc: "draft-ietf-l3vpn-end-system.all@tools.ietf.org" <draft-ietf-l3vpn-end-system.all@tools.ietf.org>
Subject: [secdir] Secdir review of draft-ietf-l3vpn-end-system-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 03:18:41 -0000

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?