Re: [secdir] SECDIR review of draft-ietf-geopriv-dhcp-lbyr-uri-option-15
James Polk <jmpolk@cisco.com> Tue, 10 July 2012 15:37 UTC
Return-Path: <jmpolk@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958D221F8622; Tue, 10 Jul 2012 08:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.505
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgrSpr12K02C; Tue, 10 Jul 2012 08:37:16 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F921F8621; Tue, 10 Jul 2012 08:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; 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 mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 10 Jul 2012 15:37:44 +0000
Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6AFbiCP000308; Tue, 10 Jul 2012 15:37:44 GMT
Message-Id: <201207101537.q6AFbiCP000308@mtv-core-3.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 10 Jul 2012 10:37:43 -0500
To: Chris Lonvick <clonvick@cisco.com>, iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option.all@tools.ietf.org
From: James Polk <jmpolk@cisco.com>
In-Reply-To: <alpine.LRH.2.00.1207100721460.8658@sjc-xdm-114.cisco.com>
References: <alpine.LRH.2.00.1207100721460.8658@sjc-xdm-114.cisco.com>
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-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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. James At 09:29 AM 7/10/2012, Chris Lonvick wrote: >Hi, > >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. > > >current: >The LS will grant permission to location inquires based on the rules >suggested: >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. > > >current: > 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 >suggested: > 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 >suggested: >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? >sips:aliceisat123mainstalantageorgiaus@example.com > > >Thanks, >Chris
- [secdir] SECDIR review of draft-ietf-geopriv-dhcp… Chris Lonvick
- Re: [secdir] SECDIR review of draft-ietf-geopriv-… James Polk