Re: [secdir] secdir review of draft-ietf-trill-directory-framework-05

Donald Eastlake <d3e3e3@gmail.com> Sat, 13 July 2013 00:59 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A821F9D62; Fri, 12 Jul 2013 17:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.454
X-Spam-Level:
X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccbbTtKsT8tn; Fri, 12 Jul 2013 17:59:56 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6337921F9D0D; Fri, 12 Jul 2013 17:59:56 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id ef5so12076966obb.1 for <multiple recipients>; Fri, 12 Jul 2013 17:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2zX+0xY7Oaun8HOTgQcGhZmv9qnWyc5eerMViBZfudc=; b=fYF8pIgWFTuUbNs2hO/180qUJGto16pc9LF9gE+ZMMxDsR1E1lF4xbsqugXrr3Diwf O4y1WPyK/Xs5nBdo9pyQk8gWVG9TbJtafldtxVLILcMBY+nPW1hV9shlFzH4m1lIiIRs aTSLLH/57qmkB14JuMx2y1ZJJTtOlmnf7oeqef4HnM8dytHGK7A6QA/BCd2iutiOggl5 pD48ihdg6Lryo9Z3CZXPOAEkMKCpWsjSOXWp5wPbyPs7a470BLsOL45cx+vqjdmtVghe sybu76zWf3cJR0h9XEj0DT8sqsn7TrArnY/JPsHpYnhu6gFyg8jIMkdza+BeSU0t4BLc 5EOg==
X-Received: by 10.182.72.137 with SMTP id d9mr36880844obv.99.1373677194851; Fri, 12 Jul 2013 17:59:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.73.106 with HTTP; Fri, 12 Jul 2013 17:59:34 -0700 (PDT)
In-Reply-To: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com>
References: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 12 Jul 2013 20:59:34 -0400
Message-ID: <CAF4+nEEiWEez1mS+_YsoCsA8zePhK16hohUhA+qHGrRLu9rwZQ@mail.gmail.com>
To: Charlie Kaufman <charliek@microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-trill-directory-framework.all@tools.ietf.org" <draft-ietf-trill-directory-framework.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-trill-directory-framework-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 13 Jul 2013 00:59:57 -0000

Hi Charlie,

Thanks for the review, I believe I agree with all your points!

See below.

On Thu, Jul 11, 2013 at 1:20 AM, Charlie Kaufman <charliek@microsoft.com>; wrote:
> 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 describes a framework for adding a central control mechanism to trill to replace or supplement its autoconfiguring mechanism of dynamically learning the locations of all addresses on the LAN. The specific protocols for supplying and consuming this configuration information will presumably appear in future specs. This sort of configuration control is useful in a datacenter where all connections are carefully configured rather than being plug and play. It is particularly applicable in a "cloud" environment where virtual machines are moved between physical machines by some sort of Virtual Machine Management System that will also assign addresses and place them.
>
> The Security Considerations section of this document is very bland, noting that reachability depends on the correct delivery of information and stating that there may be security considerations specific to particular directory assistance mechanisms. The feature is designed to improve performance rather than security. I believe this seriously understates the security advantages that are possible if a central control mechanism replaces the autoconfiguration mechanism. In particular, the main protection/isolation mechanisms available today on a LAN concern partitioning by VLAN. Within a VLAN, any node can impersonate any other and can arrange to receive traffic addressed to another node. This can be prevented if the network learns the addresses belonging to each physical connection port not from looking at what the node transmits but rather from a central controller. A node cannot receive traffic addressed to someone else simply by sending a packet from that address or responding to an ARP searching for an IP address. In fact, such packets can be blocked by the ingress Rbridge. So control is much more fine-grained than with VLANs. The network guarantees the authenticity of the source address of each incoming packet.

Right.

> The directory framework could be made more useful in serving this security functionality if its configuration included in each entry not simply the IP address, MAC/VLAN, and list of attached Rbridges, but also a port identifier for each attached RBridge. Egress RBridges could use this information to impose more precise limits. If this information is not in the database, a central controlling mechanism would need a separate protocol and communications path to communicate this information to the Egress RBridges. The current spec allows such information to be included in the directory, but does not require it.

Another good point. How about if we replace the Security
Considerations Section as follows:

OLD
   Accurate mapping of IP addresses into MAC addresses and of MAC
   addresses to the RBridge from which they are reachable is important
   to the correct delivery of information. The security of specific
   directory assisted mechanisms will be discussed in the document or
   documents specifying those mechanisms.

   For general TRILL security considerations, see [RFC6325].

NEW
   For general TRILL security considerations, see Section 6 of
   [RFC6325].

   Accurate mapping of IP addresses into MAC addresses and of MAC
   addresses to the RBridges from which they are reachable is important
   to the correct delivery of information. The security of specific
   directory assisted mechanisms for delivering such information will be
   discussed in the document or documents specifying those mechanisms.

   Directory assisted TRILL edge can substantially improve on the
   security of the default MAC address learning from the data plane used
   in a TRILL campus. With that data plane learning, any node can
   impersonate any other in the same data label (VLAN or FGL [FGL]) and
   can arrange to receive traffic addressed to another node.

   This can be prevented by disabling data plane MAC address learning
   and using trusted directory services, espeically if, when
   appropriate, ARP and ND messages are intercepted and responded too
   locally. Then end stations cannot receive traffic addressed to
   someone else simply by sending a packet from that MAC address or
   responding to an ARP or ND searching for an IP address. (Security ND
   or use of secure ESADI [ESADI] may also be helpful to security.) In
   fact, such possibly malicious packets can be blocked by the ingress
   RBridge. So control is much more fine-grained than the scope of a
   data labels, limiting spoofing to imposters directly connected to the
   same RBridge or, if RBrige port information is also provided by the
   directory, to on-link imposters.

and also add just a few words earlier on mentioning improved security
with a reference to the Security Considerations Section?

> Nits:
>
> Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence"

OK.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com