Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency

Ted Lemon <ted.lemon@nominum.com> Sat, 19 October 2013 23:17 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191011E82E2 for <v6ops@ietfa.amsl.com>; Sat, 19 Oct 2013 16:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.592
X-Spam-Level:
X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dtrU00xRX92 for <v6ops@ietfa.amsl.com>; Sat, 19 Oct 2013 16:17:17 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67511E82D6 for <v6ops@ietf.org>; Sat, 19 Oct 2013 16:17:17 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUmMS/IMhXLPp5Fa9+EF3qum1xPHPxHVe@postini.com; Sat, 19 Oct 2013 16:17:17 PDT
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 DE78C1B82CB for <v6ops@ietf.org>; Sat, 19 Oct 2013 16:17:15 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (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 ESMTPS id BEE16190060; Sat, 19 Oct 2013 16:17:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 19 Oct 2013 16:17:09 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com>
Date: Sat, 19 Oct 2013 19:17:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <3FA123B5-FC2C-4934-BD64-87D3E515D333@nominum.com>
References: <201307301245.r6UCj0k13216@ftpeng-update.cisco.com>
To: "Fred Baker (fred)" <fred@cisco.com>
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: draft-smith-v6ops-ce-dhcpv6-transparency@tools.ietf.org, IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-smith-v6ops-ce-dhcpv6-transparency
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Oct 2013 23:17:23 -0000

On Jul 30, 2013, at 8:45 AM, fred@cisco.com wrote:
> A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency. Please take a look at it and comment.

Very belated reply—sorry.

This document is sort of close, but there are a few issues.   First of all, there should be no relay; rather, the CE router should, when it receives a request, issue _its own_ information request to the PE relay.   It would provide no information about the client to the PE relay, but instead would use its own information.   This model would be followed both for stateless and stateful.

This is necessary for two reasons.   First, some DHCP parameters need to come from the CE router, not the provider.   Second, as is noted in this document's security considerations section, revealing information about clients on the local network is a privacy issue, and should be avoided.

Of course, this solution creates some problems in cases where for example vendor-specific options need to be communicated upstream, but realistically the provider isn't going to have custom configuration information like that in their DHCP server or, if they do, for devices like a provider-specific VoIP device, it should be handled with a specific extension that ensures that _only_ such information as is necessary is communicated upstream.

Aside from these comments, the general flow of the proposed solution seems right.   It probably make sense to decouple information requests and use caching and information refresh timers to maintain local information for local clients, but that's the only substantial change I'd suggest.   This would provide some degree of control over revealing information about the comings and goings of users of devices on the home network.   It does add complexity to the implementation, though, particularly in the case where device-specific configuration information needs to be maintained, such as in the case where the device asks to send a vendor class identifier upstream.