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

Charlie Kaufman <charliek@microsoft.com> Thu, 11 July 2013 05:22 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 13AA521F9E28; Wed, 10 Jul 2013 22:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.533
X-Spam-Level: *
X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zfuhxjXjHj-1; Wed, 10 Jul 2013 22:22:36 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2B72B21F935A; Wed, 10 Jul 2013 22:22:35 -0700 (PDT)
Received: from BL2FFO11FD011.protection.gbl ( by BL2FFO11HUB040.protection.gbl ( with Microsoft SMTP Server (TLS) id 15.0.717.3; Thu, 11 Jul 2013 05:22:34 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com ( by BL2FFO11FD011.mail.protection.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Thu, 11 Jul 2013 05:22:34 +0000
Received: from ch1outboundpool.messaging.microsoft.com ( by mail.microsoft.com ( with Microsoft SMTP Server (TLS) id; Thu, 11 Jul 2013 05:20:53 +0000
Received: from mail100-ch1-R.bigfish.com ( by CH1EHSOBE005.bigfish.com ( with Microsoft SMTP Server id; Thu, 11 Jul 2013 05:20:52 +0000
Received: from mail100-ch1 (localhost []) by mail100-ch1-R.bigfish.com (Postfix) with ESMTP id B953F600C7; Thu, 11 Jul 2013 05:20:52 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: 2
X-BigFish: PS2(zzzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h)
Received-SPF: softfail (mail100-ch1: transitioning domain of microsoft.com does not designate as permitted sender) client-ip=; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(76176001)(77096001)(46102001)(56776001)(74316001)(51856001)(76482001)(80022001)(79102001)(56816003)(76796001)(76576001)(59766001)(49866001)(53806001)(69226001)(74366001)(74502001)(54356001)(83072001)(76786001)(63696002)(4396001)(16406001)(65816001)(33646001)(74876001)(66066001)(74662001)(54316002)(31966008)(50986001)(47736001)(47976001)(81342001)(47446002)(77982001)(81542001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail100-ch1 (localhost.localdomain []) by mail100-ch1 (MessageSwitch) id 1373520050457693_7752; Thu, 11 Jul 2013 05:20:50 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com []) by mail100-ch1.bigfish.com (Postfix) with ESMTP id 69F25A004D; Thu, 11 Jul 2013 05:20:50 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com ( by CH1EHSMHS016.bigfish.com ( with Microsoft SMTP Server (TLS) id; Thu, 11 Jul 2013 05:20:48 +0000
Received: from BL2PR03MB592.namprd03.prod.outlook.com ( by BL2PRD0310HT005.namprd03.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 14.16.329.3; Thu, 11 Jul 2013 05:20:48 +0000
Received: from BL2PR03MB592.namprd03.prod.outlook.com ( by BL2PR03MB592.namprd03.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.731.11; Thu, 11 Jul 2013 05:20:47 +0000
Received: from BL2PR03MB592.namprd03.prod.outlook.com ([]) by BL2PR03MB592.namprd03.prod.outlook.com ([]) with mapi id 15.00.0731.000; Thu, 11 Jul 2013 05:20:47 +0000
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-trill-directory-framework.all@tools.ietf.org" <draft-ietf-trill-directory-framework.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-trill-directory-framework-05
Thread-Index: Ac598XBBv+Y+ucf3RaayD+kk4dv1wQ==
Date: Thu, 11 Jul 2013 05:20:46 +0000
Message-ID: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0904004ECB
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PR03MB592.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(77096001)(74876001)(50986001)(76176001)(54316002)(20776003)(49866001)(76786001)(47976001)(56816003)(47776003)(74366001)(77982001)(47736001)(65816001)(44976004)(76796001)(76576001)(59766001)(4396001)(81342001)(80022001)(83072001)(6806004)(16676001)(63696002)(74316001)(76482001)(74502001)(53806001)(66066001)(47446002)(74662001)(50466002)(23756003)(54356001)(81542001)(56776001)(51856001)(69226001)(46102001)(74706001)(33646001)(79102001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB040; H:TK5EX14HUBC106.redmond.corp.microsoft.com; CLIP:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0904004ECB
Subject: [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: Thu, 11 Jul 2013 05:22:43 -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 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.

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.


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