Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

Brian Haberman <brian@innovationslab.net> Mon, 03 February 2014 14:52 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05AC1A00EA for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 06:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham
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 BhTZZ6epIY3b for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 06:52:12 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A791A1A0115 for <dhcwg@ietf.org>; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id EBBC2880D1; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Received: from 10252516.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 74DD31368157; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Message-ID: <52EFAD21.6040901@innovationslab.net>
Date: Mon, 03 Feb 2014 09:52:17 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>
References: <52EBC3EA.1020104@innovationslab.net> <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com> <52EFA4E8.2040404@innovationslab.net> <D4ECE269-E79C-41A7-9AD1-82E04AB02432@nominum.com>
In-Reply-To: <D4ECE269-E79C-41A7-9AD1-82E04AB02432@nominum.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M"
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-unknown-msg@tools.ietf.org
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Feb 2014 14:52:13 -0000


On 2/3/14 9:48 AM, Ted Lemon wrote:
> On Feb 3, 2014, at 9:17 AM, Brian Haberman <brian@innovationslab.net>
> wrote:
>> Hmm... The text above talks about messages from servers to relays. 
>> Would these messages be coming from servers *not* identified in
>> the relay's configuration?  That is, do you envision relays seeing
>> messages from servers that the relay is not configured to use for
>> received client messages?  If not, shouldn't the guidance be that
>> relays should silently drop them?  If they can receive messages
>> from servers they don't know about, the relays will forward these
>> messages to *other* servers and they should drop them.
> 
> Yes, I had a bit of a think about that when replying to your review
> yesterday, and thought about it some more just now.   I don't think
> we can address that here—we don't know what these messages will look
> like, or even if they will be defined, so trying to anticipate their
> security implications is a bit futile.   I think the language I
> proposed is adequate for the time being, and does the right thing in
> the case of unknown messages.   E.g., a server implemented according
> to the existing spec would not do a bad thing with such a message,
> because it wouldn't recognize it, and the document defining that
> message ought to specify how the server should handle it in the case
> you've described.

Ok.

> 
>> Almost sounds like DHCP needs a capabilities negotiation between
>> servers and relays. :)
> 
> Perish the thought.  :)

Duly noted.

> 
>> If the pairing of a client and relay agent is not expected, this
>> may not be an issue.
> 
> It's certainly a plausible configuration—I've even proposed something
> like this in homenet.   But I think that the way this would work
> would again be something that could be documented in the spec
> describing how it works.   And homenet doesn't seem very interested
> in solving the problem this way anyway.
> 

Ok. Just wanted to check.

When a new version pops out, I will review it and start IETF LC.

Regards,
Brian