[secdir] secdir review of draft-ietf-dhc-relay-port-06

"Scott G. Kelly" <scott@hyperthought.com> Tue, 24 October 2017 16:18 UTC

Return-Path: <scott@hyperthought.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 61A4013943F for <secdir@ietfa.amsl.com>; Tue, 24 Oct 2017 09:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=unavailable autolearn_force=no
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 O-cCecD5JpZJ for <secdir@ietfa.amsl.com>; Tue, 24 Oct 2017 09:18:25 -0700 (PDT)
Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC4C13946F for <secdir@ietf.org>; Tue, 24 Oct 2017 09:18:25 -0700 (PDT)
Received: from smtp4.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EFF6B5AA5; Tue, 24 Oct 2017 12:18:21 -0400 (EDT)
Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DD4E05A98; Tue, 24 Oct 2017 12:18:21 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 24 Oct 2017 12:18:21 -0400
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id C9F99C0045; Tue, 24 Oct 2017 12:18:21 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 24 Oct 2017 09:18:21 -0700 (PDT)
X-Auth-ID: scott@hyperthought.com
Date: Tue, 24 Oct 2017 09:18:21 -0700
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-dhc-relay-port.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
Message-ID: <1508861901.825516724@apps.rackspace.com>
X-Mailer: webmail/12.9.6-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-HWV0d6UhSbSFermXaOYXn9r3KY>
Subject: [secdir] secdir review of draft-ietf-dhc-relay-port-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 24 Oct 2017 16:18:26 -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.

The summary of the review is "ready" with minor editorial nits.

From the abstract, this document proposes an extension to the DHCP protocols that allows a (DHCP) relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6.

Paraphrasing, it allows a relay agent to use any available source port for upstream communications, and to include a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

The security considerations section references [RFC3118] and [RFC3315], and adds that any firewalls in the path may need reconfiguration to allow DHCP flows from non-fixed addresses. I don't have anything to add, though I think that section could benefit from a little word-smithing. I'll defer to the RFC editor on that. 

The draft is clear, though a simple ascii diagram illustrating a client, relay, and server (including src/dst ports) might help readers to more immediately understand what this looks like topologically. I read it through, and then went back and drew myself a picture as I read, and that helped. Just a thought.

One minor (non-security) question I had: section 6 illustrates a cascaded IPv6 example wherein Relay1 is using a non-standard port, but Relay2 is not. What happens if both Relay1 and Relay2 are using non-standard source ports? Is this allowed? If not, you might want to call this out. If so, it might be good to describe a general case of n relays with m non-standard source ports.

--Scott