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

Hi Varjonen,

Thanks for your review and good catches on the errors. Will incorporate
most of your comments and submit the updated draft.

--Feng

-----Original Message-----
From: Varjonen Samu [mailto:samu.varjonen@hiit.fi] 
Sent: Thursday, October 23, 2008 4:10 AM
To: Suping ZHAI
Cc: Feng Cao (fcao); hipsec@ietf.org
Subject: Re: [Hipsec] submission of a new I-D:"Delivering Geographic
Location in Host Identity Protocol (HIP)"

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-0
>> 0.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