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

Brian Haberman <> Mon, 03 February 2014 14:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A05AC1A00EA for <>; Mon, 3 Feb 2014 06:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BhTZZ6epIY3b for <>; Mon, 3 Feb 2014 06:52:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A791A1A0115 for <>; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id EBBC2880D1; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 74DD31368157; Mon, 3 Feb 2014 06:52:10 -0800 (PST)
Message-ID: <>
Date: Mon, 03 Feb 2014 09:52:17 -0500
From: Brian Haberman <>
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 <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1TjxWWkxuNQ9iUOT3cGnuAvSG2iQMEW0M"
Cc: " WG" <>,
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>
> 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.


>> 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.