Re: [Hipsec] submission of a new I-D:"Delivering Geographic Location in Host Identity Protocol (HIP)"

Varjonen Samu <samu.varjonen@hiit.fi> Thu, 23 October 2008 11:34 UTC

Return-Path: <hipsec-bounces@ietf.org>
X-Original-To: hip-archive@lists.ietf.org
Delivered-To: ietfarch-hip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88DB28C198; Thu, 23 Oct 2008 04:34:42 -0700 (PDT)
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F367D3A67A6 for <hipsec@core3.amsl.com>; Thu, 23 Oct 2008 04:34:41 -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=[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 fl5La6qtSBvb for <hipsec@core3.amsl.com>; Thu, 23 Oct 2008 04:34:33 -0700 (PDT)
Received: from creon.otaverkko.fi (creon.otaverkko.fi [212.68.0.5]) by core3.amsl.com (Postfix) with ESMTP id 91F3E3A69A8 for <hipsec@ietf.org>; Thu, 23 Oct 2008 04:34:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by creon.otaverkko.fi (Postfix) with ESMTP id C4FF421AF54; Thu, 23 Oct 2008 14:09:56 +0300 (EEST)
Received: from creon.otaverkko.fi ([127.0.0.1]) by localhost (creon.otaverkko.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04236-09; Thu, 23 Oct 2008 14:09:46 +0300 (EEST)
Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by creon.otaverkko.fi (Postfix) with ESMTP id C023921AF3C; Thu, 23 Oct 2008 14:09:46 +0300 (EEST)
Received: from [193.167.187.93] (ip93.infrahip.net [193.167.187.93]) by argo.otaverkko.fi (Postfix) with ESMTP id B861B25ED06; Thu, 23 Oct 2008 14:09:46 +0300 (EEST)
Message-ID: <49005B7A.2020900@hiit.fi>
Date: Thu, 23 Oct 2008 14:09:46 +0300
From: Varjonen Samu <samu.varjonen@hiit.fi>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Suping ZHAI <zhaisuping@huawei.com>
References: <0K9600IP85WE6S@szxml03-in.huawei.com>
In-Reply-To: <0K9600IP85WE6S@szxml03-in.huawei.com>
X-Virus-Scanned: amavisd-new at otaverkko.fi
Cc: "hipsec@ietf.org" <hipsec@ietf.org>, "Feng Cao \(fcao\)" <fcao@cisco.com>
Subject: Re: [Hipsec] submission of a new I-D:"Delivering Geographic Location in Host Identity Protocol (HIP)"
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: hipsec-bounces@ietf.org
Errors-To: hipsec-bounces@ietf.org

Hi,

Suping ZHAI wrote:
> Hi Feng,
> One comment with respect of the parameter geolocation. In the location-based services, the location can be identified by the LOCATOR which is defined in RFC5206, it can also provide the privacy and authentication. So what's the preference of the GEOLOCATION comparing with the LOCATOR?
> 

Also to me the LOCATOR seems like a better place for this stuff as 
geo-loc information is a "locator". If IPs are used as the means to 
offer location LOCATOR would be straight forward. What if the location 
is based on GPS coordinates, well, lets add a new type to LOCATOR to 
inform about geographical location and define that these are NOT to be 
used for sending traffic.

I would have liked to see a use case about why would I want to send 
geoloc information in HIP control packets. To me it seems that the 
application using HIP is more interested in the geoloc information. Or 
is this something that could be used with HIP Bone to offer locality 
based optimation for the overlay? Anyway some motivational stuff in the 
beginning would be nice.

In introduction, in the end, ENCRYPTED not ENCRPTED.

In the terminology I found that defining HIT is useless because if you 
need this draft you probably already know about HITs. But it does no 
harm in the list.

In the terminology I noticed a term Peer connection. It sounded a lot 
like Host Association. Should it be HA?

Also about the terminology usage in the draft, RFC 5204 defines 
Rendezvous extension not Rendevous extension. At least in sections 4.2, 
4.3, 4.4, 4.5 and 5, the "z" char is missing.

I would remove all the new words from the paper. They did not give any 
extra information on the parameter. To my opinion it can be just like 
"this paper describes parameter called GEOLOC". The newness of the 
parameter does not offer anything.

In the figs correct the explanations, for example in fig 1 (which does 
not have a label) the Length is explained as 16, yes it is 16 bits long 
but it would be nicer to see it like "Length in octets, excluding Type, 
and Padding". Same goes for the LocationFormat. The length can be read 
from the fig. Could also be mentioned in the fig but after the content 
explanation.

About the LocationFormat, should the bit defining LbyV/LbyR be separated 
from it because it does not change the location format. It changes how 
you use the LocationPayload and the LocationFormat would just say how 
you read it.

Now
	...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        LocationFormat         |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
	...
After
	...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |L|      LocationFormat         |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
	...
	L 	LbyV if 0 and LbyR if 1
	...
Or
	...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |L|          Reserved           |        LocationFormat 
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

	...
	L 	LbyV if 0 and LbyR if 1

I would lose the quotation marks from around the field names.

The fig for ENCRYPTED can be seen in RFC 5201 in section 5.2.15 and 
reference to that should do the trick. It was quite clear the the 
Encrypted payload was the GEOLOC parameter even without the fig.

Section 3.4. "The (new) GEOLOC_REQ parameter are defined" There is only 
one GEOLOC_REQ so "is" not "are" and the fig does not have a label.

About the usage of the GEOLOC_REQ. Is it always used with the RVS or can 
I ask CNs location.

Whose location can I ask from RVS? There is HIT present but can it be 
any HIT RVS knows.

What if the HIT queried does not support GEOLOC, how RVS answers then?

Section 4.3. "RVS can server as Location" should be "can serve as"

"It is similar that GEOLOC can be embedded..." is repeated three times 
in the text in sections 4.3., 4.4. and 4.5. It is already stated in 
section 3.3. and it is NOT necessary to repeat it.

Security considerations:

   You can always rate limit the control packets (quick and dirty
   solution).

   How about if one is lying about the location?

BR,
Samu Varjonen

> Best Regards,
> Suping
> ---original message---
> From: fcao@cisco.com
> Sent: 2008-10-22 10:21:00
> Subject:[Hipsec] submission of a new I-D:"Delivering Geographic Location	in Host Identity Protocol (HIP)"
> 
>> Hi all,
>>
>> A new I-D, draft-cao-hip-geolocation-00, was just submitted to IETF HIP
>> WG. Your comments are always welcome.
>>
>> Here is the staging URL for now: 
>> http://www3.ietf.org/proceedings/staging/draft-cao-hip-geolocation-00.tx
>> t
>> <http://www3.ietf.org/proceedings/staging/draft-cao-hip-geolocation-00.t
>> xt> 
>>
>> Abstract: This document defines a new parameter for delivering
>> geographic location in Host Identity Protocol (HIP). For mobile users
>> using HIP, one generic mechanism is proposed to share or update their
>> geo- location information with either rendezvous servers or their peers.
>> In addition, geo-location privacy is also protected with the help of the
>> ENCRYPTED parameter.
>>
>> Thanks,
>>
>> --Feng
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
> 
> 
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec