[secdir] secdir review of draft-ietf-netext-logical-interface-support-12

"Scott G. Kelly" <scott@hyperthought.com> Wed, 03 February 2016 00:43 UTC

Return-Path: <scott@hyperthought.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 E043D1ACE8B for <secdir@ietfa.amsl.com>; Tue, 2 Feb 2016 16:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
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 DyTq28KwoMPx for <secdir@ietfa.amsl.com>; Tue, 2 Feb 2016 16:43:27 -0800 (PST)
Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECA51ACE88 for <secdir@ietf.org>; Tue, 2 Feb 2016 16:43:26 -0800 (PST)
Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C31B4380537; Tue, 2 Feb 2016 19:43:25 -0500 (EST)
Received: from app2.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B38F738050D; Tue, 2 Feb 2016 19:43:25 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app2.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Tue, 02 Feb 2016 19:43:25 -0500
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app2.wa-webapps.iad3a (Postfix) with ESMTP id A1166280D91; Tue, 2 Feb 2016 19:43:25 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 2 Feb 2016 16:43:25 -0800 (PST)
Date: Tue, 2 Feb 2016 16:43:25 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-netext-logical-interface-support.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
X-Auth-ID: scott@hyperthought.com
Message-ID: <1454460205.658219841@apps.rackspace.com>
X-Mailer: webmail/12.0.0-RC
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/YdUiCUTLGD1Mew1RhWZuq73iXtw>
Subject: [secdir] secdir review of draft-ietf-netext-logical-interface-support-12
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 03 Feb 2016 00:43:28 -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.

From the abstract, this Informational document explains the operational details of [sic] Logical-interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks.

The brief security considerations section says the implementation on the host is not visible to the network and does not require any special security considerations. One thing that occurred to me when I read this is that if someone is depending on link layer security (e.g. 802.11i) for any reason, then there may be security implications to switching the exit interface. Not sure if this is important - I'll leave it to the ADs to decide.