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

Chris Lonvick <clonvick@cisco.com> Tue, 10 July 2012 14:29 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 026AA21F876D; Tue, 10 Jul 2012 07:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CzAzFaSl2gGq; Tue, 10 Jul 2012 07:29:32 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3E6CF21F86EC; Tue, 10 Jul 2012 07:29:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=6005; q=dns/txt; s=iport; t=1341930600; x=1343140200; h=date:from:to:subject:message-id:mime-version; bh=DS2RCBDHMLWtqyI8pdJsEQoxhqxO1EH/S+4AYpds4A4=; b=eQrUIXD6wvRdZndaWqPGehQ4qxY/LwaAjia6rOLrnkkvc9HK1mzVKJUl Rsx6rkhhcXrRfVydvG5SYoCpNABuAGo5aJWLwEEdQPJP8WwvRCiq3YPrW wL4pwoOS6G9iTB8pNRapI2EivY+n9Wgxd5c8hY+SrWjACyJpp5zmUnyst A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAGU7/E+rRDoH/2dsb2JhbABFt3WBB4I5ASUCOIFGEiKHapxPoDiRYgOISZsMgWaCfw
X-IronPort-AV: E=Sophos;i="4.77,559,1336348800"; d="scan'208";a="51464423"
Received: from mtv-core-2.cisco.com ([]) by mtv-iport-4.cisco.com with ESMTP; 10 Jul 2012 14:29:58 +0000
Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com []) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6AETwCK009060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 14:29:58 GMT
Date: Tue, 10 Jul 2012 07:29:57 -0700 (PDT)
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option.all@tools.ietf.org
Message-ID: <alpine.LRH.2.00.1207100721460.8658@sjc-xdm-114.cisco.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [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 14:29:33 -0000


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

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?