Re: [secdir] SECDIR review of draft-ietf-geopriv-dhcp-lbyr-uri-option-15

James Polk <> Tue, 10 July 2012 15:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 958D221F8622; Tue, 10 Jul 2012 08:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.505
X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VgrSpr12K02C; Tue, 10 Jul 2012 08:37:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CC3F921F8621; Tue, 10 Jul 2012 08:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6302; q=dns/txt; s=iport; t=1341934664; x=1343144264; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=cPkeG3BjEfbHLOzTGqQxJmYkLEgg5o2i79Q6Y5wW1+M=; b=aNkLslDHOFdd1v/rDlys+HO4+Po3pfErm1OLhJ3uEG4ztY5e/YLSCj+b dji2Te0Ndn/UQqPOLUdFbSqPcrEhe1zVibKtUGK51aSfjJ1S+6tWC6Dn4 jY7mDB+EZNgMBstTOA08VOWgG17jOwT7kPigfE401GfQ1wGWMaKO6u3I8 8=;
X-IronPort-AV: E=Sophos;i="4.77,559,1336348800"; d="scan'208";a="48437537"
Received: from ([]) by with ESMTP; 10 Jul 2012 15:37:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q6AFbiCP000308; Tue, 10 Jul 2012 15:37:44 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 10 Jul 2012 10:37:43 -0500
To: Chris Lonvick <>, <>, <>, <>
From: James Polk <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Tue, 10 Jul 2012 08:42:51 -0700
Subject: Re: [secdir] SECDIR review of draft-ietf-geopriv-dhcp-lbyr-uri-option-15
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2012 15:37:17 -0000

pesky little details...

I love the last one below... d`oh!  ;-)

of course I'll address these.


At 09:29 AM 7/10/2012, Chris Lonvick wrote:
>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  These comments were written primarily for the benefit of the
>security area directors.  Document editors and WG chairs should treat
>these comments just like any other last call comments.
>Overall, I can see where the document is going and I feel that the 
>security considerations section appropriately matches it.
>In my scan of the document, I did find a number of editorial issues. 
>Perhaps another scrub of the document would be in order.  Below are 
>some of the items that I had issues with.
>In the sentence,
>    The DHCP implementation of the client can then
>    make this location information available to upper layer protocols
>    for their usage.
>Would it be more appropriate to replace "upper layer protocols" with 
>"other applications"?  Then just remove "using upper layer 
>protocols" from the following paragraph for consistency.
>PIDF-LO is not defined or referenced until its third use.  It may 
>just be best to swap paragraphs 4 and 3 in that section as the text 
>flow seems to be a bit more logical that way.  That would also then 
>have an appropriate reference to the first use of PIDF-LO.
>The LS will grant permission to location inquires based on the rules
>The LS will grant permission to location inquiries based on the rules
>                                          ^^^^^^^^^
>The following two paragraphs should be combined.
>    Server operators should consider the relation between the Valid-For
>    time and the lease time.  Clients typically request a lease refresh
>    when half the lease time is up. If the Valid-For time is less than
>    the typical refresh rate (i.e., half the lease time), then for the
>    remaining interval, clients will run the risk of not having a usable
>    location URI for applications.  If the Valid-For time is less than
>    half the typical refresh rate, it is a near certainty clients will
>    not have a usable location URI for the interval between the
>    Valid-For time and the typical refresh time for applications.
>    For example, if a lease is set to 24 hours, the typical refresh
>    request is set to initiate at the 12 hour mark. If the Valid-For
>    timer is set to less than 24 hours, but more than 12 hours (in this
>    example), the client might not be refreshed at the 12 hour mark and
>    runs the risk of not have a location URI for applications that
>    request it.  If, on the other hand, the Valid-For timer is less than
>    12 hours (in this example, which is before a typical client would
>    ask for a refresh, applications will be without a usable location
>    URI until the full refresh has been received.
>In the following sentence, maybe s/identities/identifies ?
>    In the <presence> element of a PIDF-LO document, there is an
>    'entity' attribute that identities what entity *this* document
>    (including the associated location) refers to.
>Beyond that, it is unclear how the term "document" is being used in 
>this context.  Perhaps use "this specification" when appropriate?
>The first part of the following sentence indicates that there is one 
>model.  The second half of that sentence indicates that there are 
>multiple models but doesn't indicate the context (models of 
>what?).  Can you clear that up?
>    o  The authorization vs. possession security model can be found in
>       [RFC5808], describing what is expected in each model of
>       operation.
>First, the following sentence needs to be straightened out.  Second, 
>just because IANA registers them doesn't mean that URI schemes or 
>types cannot be misused or will not be harmful.
>    Instead of listing all the types of URIs and URLs that can be
>    misused or potentially have harmful effects, Section 3.3 IANA
>    registers acceptable location URI schemes (or types).
>In most places you quote the uri type but in the following you don't 
>quote "pres:" in the following:
>    See RFC 3922 [RFC3922] for using the pres: URI with XMPP.
>Maybe that should be:
>    See RFC 3922 [RFC3922] for using the "pres:" URI with XMPP.
>I have an issue with the following:
>    When implementing a DHCP server that will serve clients across an
>    uncontrolled network, one should consider the potential security
>    risks therein.
>Actually, this is the section to describe all these risks.  You may 
>consider referencing RFC 3552 and restate as:
>    In some cases a DHCp server may be implemented across an uncontrolled
>    network.  In those cases, it would be appropriate for a network
>    administrator to perform a threat analysis (see RFC 3552) and take
>    precautions as needed.
>Is "revelation" common nomenclature for this?
>    "security properties before location revelation"
>Perhaps revise as:
>    "security properties before location assertion"
>The acronym "LCI" is not defined in the text.
>    In enterprise networks, if a known location is assigned to each
>    individual Ethernet port in the network, a device that attaches to
>    the network a wall-jack
>    In enterprise networks, if a known location is assigned to each
>    individual Ethernet port in the network, a device that attaches to
>    the network, such as a wall-jack,
>                 ^^^^^^^^
>The acronym "RIAO" not defined in the text.
>current (Yoda speak?)  ;-) :
>    A real concern with RFC 3118 it is that not widely deployed because
>A real concern with RFC 3118 is that it is not widely deployed because
>                             ^^^^^^^^^^^^^^
>You use LocationURI once but never reference that to luri.  It might 
>be nice to reference it once to people unfamiliar with this work (such as I :)
>In the following, is that supposed to be aTlanta?