[secdir] SecDir review of draft-ietf-trill-o-pw-03
Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 12 December 2013 21:58 UTC
Return-Path: <yaronf.ietf@gmail.com>
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 EB7B41AE00C; Thu, 12 Dec 2013 13:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 8zZD-d9VKmlO; Thu, 12 Dec 2013 13:58:21 -0800 (PST)
Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9F01AD8E2; Thu, 12 Dec 2013 13:58:20 -0800 (PST)
Received: by mail-ea0-f173.google.com with SMTP id o10so515157eaj.32 for <multiple recipients>; Thu, 12 Dec 2013 13:58:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=SpP3gVHQpny2sR9W06JOM33VsHnv38oT/bsusq9gDbE=; b=wCRuOykotqXApybvcqYJRyK44svL2qyM0zAIPNV8rZrPvHEpi9bC3Hy6l4QyJ8ma12 oZYhbooATgtpqwDQZgWbh9fjggQpyfGppf9x5D47WNbMTFhjKpeuaQsJ/9BJyXNyRi05 45beKUhaXH27EjjjsCwfQOwlHnrd5YFbhJwd3uVoyK2jcArynRkHAKcHo9mjf1kebilh 5/A4BE8n1nxjE+rt7I51giKP51+YBurGlOF3LQ2z0p4VAuIm3luw4MrjpN58t1e+VSE9 vYXkw3ktU6nC8TGpz9zNUnqorWa9Oa4LpsRPBjWn0thvIZRzsvBkhuuuoDrM+gPeo7zh 7few==
X-Received: by 10.14.47.75 with SMTP id s51mr10286714eeb.97.1386885493786; Thu, 12 Dec 2013 13:58:13 -0800 (PST)
Received: from [10.0.0.2] (bzq-109-65-142-155.red.bezeqint.net. [109.65.142.155]) by mx.google.com with ESMTPSA id g47sm70872940eeo.19.2013.12.12.13.58.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 13:58:13 -0800 (PST)
Message-ID: <52AA3173.8040100@gmail.com>
Date: Thu, 12 Dec 2013 23:58:11 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-trill-o-pw.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [secdir] SecDir review of draft-ietf-trill-o-pw-03
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: Thu, 12 Dec 2013 21:58:23 -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 document specifies how multiple networks running TRILL can be connected using pseudowires. Summary Coming from the L3 security community, I am very worried by this document and its predecessors. It seems to me that we are creating the infrastructure for larger and larger L2 networks, often spanning large geographical distances, but the security mechanisms are not keeping up with this wider scope. I am not familiar with either the TRILL or PWE3 standards. Nor am I familiar with their real-life implementations. If secure deployments are common, I will be happy to be proven wrong (though I would expect such best practices to be documented and standardized). Details - This document copies the following text from the analogous PPP transport RFC: "not all implementations need to include specific security mechanisms at the pseudowire layer, for example if they are designed to be deployed only in cases where the networking environment is trusted or where other layers provide adequate security. A complete enumeration of possible deployment scenarios and associated threats and options is not possible and is outside the scope of this document.' I beg to differ. I think Security Considerations should recommend such solutions, and discuss the specific issues that come up when deploying them in this context: how should endpoints be authenticated? What protocol information should be protected? How do TRILL identities map to identities authenticated by the selected security protocol etc. In general, although not ALL implementations need security mechanisms, I assume an overwhelming majority of them does. - Moreover, text such as the following (RFC 6325) strongly hints that this traffic will be passing under the radar of many security devices: "TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes." - The Security Considerations recommend end-to-end security as a replacement for link-level security. Though attractive from a security point of view, such solutions (security protocols between end hosts) are far from ubiquitous in large networks and so cannot replace link-level mechanisms. - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL islands. RFC 6361 does in fact discuss specific security mechanisms (yes, one wonders about CHAP being recommended in a 2011 document). The current document does not do so. Thanks, Yaron
- [secdir] SecDir review of draft-ietf-trill-o-pw-03 Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-trill-o-… Donald Eastlake
- Re: [secdir] SecDir review of draft-ietf-trill-o-… Ted Lemon
- Re: [secdir] SecDir review of draft-ietf-trill-o-… Yaron Sheffer