Re: [Gen-art] Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14

Ben Campbell <ben@estacado.net> Tue, 09 June 2009 19:12 UTC

Return-Path: <ben@estacado.net>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9713A6D64; Tue, 9 Jun 2009 12:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRWxTCJZBzx7; Tue, 9 Jun 2009 12:12:51 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 792883A6D21; Tue, 9 Jun 2009 12:12:50 -0700 (PDT)
Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n59JAoWO007312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Jun 2009 14:10:50 -0500 (CDT) (envelope-from ben@estacado.net)
Message-Id: <23863D3D-27FF-48CE-89A9-5B00A25A2410@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: Mary Barnes <mary.barnes@nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E64FBA5@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 09 Jun 2009 14:10:49 -0500
References: <E0E6661F-D91F-45B3-9136-B7FFDDFE5D80@estacado.net> <1ECE0EB50388174790F9694F77522CCF1E64FBA5@zrc2hxm0.corp.nortel.com>
X-Mailer: Apple Mail (2.935.3)
Cc: Cullen Jennings <fluffy@cisco.com>, ietf@ietf.org, Richard Barnes <rbarnes@bbn.com>, General Area Review Team <gen-art@ietf.org>, barbara.stark@att.com, acooper@cdt.org, james.winterbottom@andrew.com, martin.thomson@andrew.com
Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2009 19:12:51 -0000

Hi Mary,

Responses inline. I've edited out sections that I think we have  
closure on.

On Jun 8, 2009, at 1:55 PM, Mary Barnes wrote:

[...]

>
> -- Section 6.2, value list:
>
> -- In my previous review, I was confused as to the relationship  
> between
> the geodetic/civic and LoBV/LoBR choices. I think it's worth some
> clarification in this section that geodetic and civic imply LoBV.
>
> [MB] Okay, how about the following:
> OLD:
>   geodetic:  The LIS SHOULD return a geodetic location for the Target.
>   civic:  The LIS SHOULD return a civic address for the Target.
>
> NEW:
>   geodetic:  The LIS SHOULD return a location by value in the form  
> of a
>
>              geodetic location for the Target.
>   civic:  The LIS SHOULD return a location by value in the form of
>           a civic address for the Target.

Thanks, that helps.

>
> -- section 9.3, 5th paragraph: "A temporary spoofing of IP address  
> could
> mean that a device could request a Location Object or Location URI  
> that
> would result in another Device's location."
>
> It might be worth clarifying that (if I understand correctly) that  
> this
> is more than a spoofing attack, in that the attacker must not only  
> spoof
> its source address, but must be able to receive packets sent to the
> spoofed address?
>
> [MB] That statement was intended to include both those items, I'd
> propose to clarify as follows:
> NEW:
> A temporary spoofing of IP address could mean that a device could
> request a Location Object or Location URI that would result in  
> receiving
> another Device's location if the attacker is able to receive packets
> sent to the spoofed address.

Thanks, that helps.

>
>
> -- same paragraph: "... re-use of the Device's
>    IP address could result in another Device receiving the original
>    Device's location rather than its own location."
>
> It seems like this problem is pretty unlikely to occur by _accident_
> when HELD is used over TCP (the only binding right now), right? And
> certain not to happen over TLS? Might be worth a "mitigating" mention.
> [MB] Certainly, it is fairly unlikely (if not impossible in most
> situations), but the recommendations in the bullet points further  
> reduce
> the potential for problems in the off chance that this occurs.  It's  
> not
> entirely clear to me why you suggest this is certain not to happen  
> over
> TLS since this is talking about a device that has dropped and thus the
> connection would drop and it would seem there's a window for another
> device (although quite unlikely) to use that same IP address. But,
> perhaps, qualifying the statement as follows would address your  
> concern:
> OLD:
>  These exposures are limited by the following:
>
> NEW:
>  While these situations are fairly unlikely to occur (in particular
> with the use of TCP/TLS), the exposures can be further limited by the
> following:
>
>

On reflection, it's probably better to err on the side of caution  
here, rather than try to dilute the warning. I withdraw my comment,  
and think the original text is fine here. Sorry for the flip-flop.

Thanks!

Ben.