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

Ralph Droms <rdroms.ietf@gmail.com> Mon, 03 February 2014 15:06 UTC

Return-Path: <rdroms.ietf@gmail.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 AFEFC1A00F4 for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 07:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 IeSEgRYhEqee for <dhcwg@ietfa.amsl.com>; Mon, 3 Feb 2014 07:06:35 -0800 (PST)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BD1C71A00F2 for <dhcwg@ietf.org>; Mon, 3 Feb 2014 07:06:35 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id ii20so10087880qab.33 for <dhcwg@ietf.org>; Mon, 03 Feb 2014 07:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oez8p5Rr+bq0pm/fBYbql+TTTSWcGL+VmD8h1phRou0=; b=JnTYFp+pxMfiOmcwlvjsPFXx1T4avv6zb22gbxErLGKkwJX07Mpg6zhArFFmIG1OXS JNqugxESJhW9oLw717T4CA0W2ChHQDOp4VdLhc0Fal244KVgSS81CrQ+sIvuruHIQRDg +bLp8e2qCvyYykrr8esrwwTPTWFiVdeasRZwqKvy7/j7iVDMDtqFwFuNtksy+XIEJR8c bkn7Mrk1Wv/ZUJ5scw/kxV9Cd58utwepduKWYsPUKAPx5oIX3Hye8f5Mjh1uDyFLDACq 1tKTFoZXve24iaiJXXnmZq80b17wBZUrflPMy2ecWLrd/Sfj6tg54RkNyDdwYRtI1gQy lyYA==
X-Received: by 10.224.89.4 with SMTP id c4mr57674224qam.64.1391439995486; Mon, 03 Feb 2014 07:06:35 -0800 (PST)
Received: from ?IPv6:2001:420:2c52:1316:a12a:883:79cf:6178? ([2001:420:2c52:1316:a12a:883:79cf:6178]) by mx.google.com with ESMTPSA id k107sm27438083qgk.5.2014.02.03.07.06.34 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Feb 2014 07:06:34 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <D4ECE269-E79C-41A7-9AD1-82E04AB02432@nominum.com>
Date: Mon, 3 Feb 2014 10:06:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8ED0F0BC-B198-42C2-B725-A8CB77893278@gmail.com>
References: <52EBC3EA.1020104@innovationslab.net> <CFA19E62-0F9A-4358-AB7C-E4A910BF4874@nominum.com> <52EFA4E8.2040404@innovationslab.net> <D4ECE269-E79C-41A7-9AD1-82E04AB02432@nominum.com>
To: Ted Lemon <ted.lemon@nominum.com>
X-Mailer: Apple Mail (2.1510)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, Haberman Brian <brian@innovationslab.net>, 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 15:06:37 -0000

On Feb 3, 2014, at 9:48 AM 2/3/14, Ted Lemon <ted.lemon@nominum.com> 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 don't think we can count on the relay agent explciitly knowing all of the servers for which it is configured. The default configuration for a realy agent is to forward messages to a multicast address.

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

We'll get on that as soon as we finish a HA server-server protocol.

> 
>> If the pairing of a client and relay agent is not expected, this may not
>> be an issue.

Perhaps I'm insufficiently caffeinated this AM, but I don't understand "pairing of a client and relay agent"...

- Ralph

> 
> 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.
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg