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

Ted Lemon <ted.lemon@nominum.com> Mon, 03 February 2014 14:48 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 0FE831A0124 for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 06:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] 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 asusqfuLZBYO for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 06:48:18 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 590621A011B for <dhcwg@ietf.org>; Mon, 3 Feb 2014 06:48:18 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUu+sMoP1xvh29CGTVofcmiFe98VFVEtc@postini.com; Mon, 03 Feb 2014 06:48:18 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 305BA1B82F5 for <dhcwg@ietf.org>; Mon, 3 Feb 2014 06:48:18 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2930B190052; Mon, 3 Feb 2014 06:48:18 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 06:48:18 -0800
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <52EFA4E8.2040404@innovationslab.net>
Date: Mon, 03 Feb 2014 09:48:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <D4ECE269-E79C-41A7-9AD1-82E04AB02432@nominum.com>
References: <52EBC3EA.1020104@innovationslab.net> <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com> <52EFA4E8.2040404@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
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:48:20 -0000

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.

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

Perish the thought.  :)

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