Re: [dhcwg] Mirja Kühlewind's No Objection on draft-ietf-dhc-relay-port-07: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 13 November 2017 05:38 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C531A129493 for <dhcwg@ietfa.amsl.com>; Sun, 12 Nov 2017 21:38:50 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 jR_Cqs5Hhf_t for <dhcwg@ietfa.amsl.com>; Sun, 12 Nov 2017 21:38:48 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1088129485 for <dhcwg@ietf.org>; Sun, 12 Nov 2017 21:38:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=fj7azWthtqbrBMpUt9J1usOvVzsMAf4OnWI3UiU31EhlsBplP9bINHEto9sefg3G/PMWAI0YSDPj3VE2tDCfOGuJGioYE/pqpFEwEmx6DR83r9pC6tASBF2t11XI2lMS+n71dTU+40ahOnXQv/DNi9w/hSE/tCyS95I7OPcxc5U=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 15873 invoked from network); 13 Nov 2017 06:38:37 +0100
Received: from dhcp-80f9.meeting.ietf.org (31.133.128.249) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 13 Nov 2017 06:38:37 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <013E8E09-72FF-4EB5-85B7-4EC62F58F8F2@cisco.com>
Date: Mon, 13 Nov 2017 13:38:34 +0800
Cc: "draft-ietf-dhc-relay-port@ietf.org" <draft-ietf-dhc-relay-port@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, The IESG <iesg@ietf.org>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A4450C0-EAFB-4506-9FFA-BA01E76AFD50@kuehlewind.net>
References: <151054482655.21370.2657580358462340178.idtracker@ietfa.amsl.com> <013E8E09-72FF-4EB5-85B7-4EC62F58F8F2@cisco.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171113053837.15865.29528@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/oLk-EweE9ArqSs3nfNznSQpFDew>
Subject: Re: [dhcwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-dhc-relay-port-07=3A_=28with_COMMENT=29?=
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 05:38:51 -0000

Hi Bernie,


> Am 13.11.2017 um 11:57 schrieb Bernie Volz (volz) <volz@cisco.com>;:
> 
> Hi:
> 
> A DHCP Server does not need to listen on other ports. Only the relay that wants to use an alternative port for responses needs to listen on alternate port(s).

Right. And you don’t think that that has any new security implications?
> 
> Regarding the updates issue, this is always a complex question - does a new DHCP option update these documents? I believe that updates should be used for required changes to a protocol (or corrections), not for extensions. It is too bad there is no “extends” tag to indicate extensions.

I agree the option would not require an update but the text changes do.

Mirja


> 
> - Bernie
> 
> On Nov 13, 2017, at 11:47 AM, Mirja Kühlewind <ietf@kuehlewind.net>; wrote:
> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-dhc-relay-port-07: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-port/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> I really think this document should update RFC2131 and RFC3315 as it proposed
>> concrete changes to both RFCs. The point is that, while the use of the
>> described mechanism and options is optional, I think the updates of the texts
>> apply more generally.
>> 
>> Further, I would think that if a DHCP server now has to listen on all ports for
>> incoming traffic, that this would raise additional security considerations.
>> However, didn’t think enough about it to name a specific threat.
>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg