Re: [dhcwg] Last Call: <draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt> (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed Standard

Alissa Cooper <> Wed, 27 June 2012 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 692C121F8661; Wed, 27 Jun 2012 14:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.262
X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cvNjXYsCfwSC; Wed, 27 Jun 2012 14:27:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E38121F865D; Wed, 27 Jun 2012 14:27:42 -0700 (PDT)
X-Footer: Y2R0Lm9yZw==
Received: from localhost ([]) by (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 27 Jun 2012 17:27:39 -0400
Subject: Re: [dhcwg] Last Call: <draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt> (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 27 Jun 2012 17:27:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1084)
Cc: GEOPRIV WG <>, " WG" <>, IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jun 2012 21:27:43 -0000

Hi Ted,

On Jun 22, 2012, at 4:11 PM, Ted Lemon wrote:

> On Jun 22, 2012, at 3:59 PM, Alissa Cooper wrote:
>> My understanding is that the option is encoded this way both for extensibility and because the Valid-For parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a sub-option? 
> What's in the draft is not suboptions—it's a whole special format requiring new code on all servers that implement it.   Suboptions don't exist in DHCPv6—just encapsulations of regular options, which I don't think make sense here either.
>> It may have been before I was paying attention, but I get the impression that related ground has already been trod in DHC, given that it also came up in GEOPRIV.
> When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated internal option structure with lots of special code required in the server to implement.   But given that only one Location URI option is allowed, there's no need for suboptions.

If we split it into two options, that eliminates the future possibility of supporting multiple URIs per client. So we will need to take this back to the GEOPRIV WG to make sure folks are okay with foreclosing that.

>>> Section 3.2 suggests that options shouldn't contain certain potentially harmful values, but this is a toothless restriction, since an attacker can simply ignore it.   In order for it to be effective, Section 3.2 should insist that DHCP clients reject forbidden URI formats.   Of course, this too is somewhat toothless, since any list of forbidden URI formats will necessarily fail to mention any future potentially harmful URIs that could arise.   It would be better to list which URIs _are_ permitted, and require the client to reject any URI that is not permitted.   The document is already set up to do this, but doesn't _actually_ do it, so fixing this should be quite easy.
>> In 3.3, I suggest replacing the following:
>> "This section specifies which URI types are acceptable as a location
>>  URI scheme (or type) for this DHCP Option:"
>> with
>> "URIs carried by this DHCP Option MUST have one of the following URI schemes:"
> That's just as toothless.   Unless the client MUST reject these options, it MAY accept them.

Okay, will add MUST reject language.