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

From: Suping ZHAI <[email-masked]>
Date: Thu, 23 Oct 2008 10:07:32 +0800

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?

Best Regards,
Suping
---original message---
From: [email-masked]
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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec

---

From: Varjonen Samu <[email-masked]>
Date: Thu, 23 Oct 2008 14:09:46 +0300

Hi,

> 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…

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

---

From: "Feng Cao (fcao)" <[email-masked]>
Date: Thu, 23 Oct 2008 10:57:30 -0700

Hi Suping,

LOCATOR is another option to carrying geo-location. But there are some
drawbacks for using LOCATOR. For example, there is a need to provide
geo-location  request, where GEOLOC_REQ is more clear and specific
(instead of creating new  LOCATOR_REQ only for geo-location).  There are
also some incompatible fields in LOCATOR, such as the limit of locator
length and P-bit. Additionally,  LOCATOR or location may generate
confusion for its scope among various users, so geo-location sounds to
be direct and clear.

We stick to GEOLOC and GEOLOC_REQ for now (and are open to other
options), unless that HIP WG reaches the consensus.

Thanks,

--Feng

-----Original Message-----
From: Suping ZHAI [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 7:08 PM
To: Feng Cao (fcao); [email-masked]
Subject: Re: [Hipsec] submission of a new I-D:"Delivering Geographic
Location in Host Identity Protocol (HIP)"

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?

Best Regards,
Suping
---original message---
From: [email-masked]
Sent: 2008-10-22 10:21:00
Subject:[Hipsec] submission of a new I-D:"Delivering Geographic Location
in Host Identity Protocol (HIP)"

>In addition, geo-location privacy is also protected with the help of 
>the ENCRYPTED parameter.
>
>Thanks,
>
>--Feng

---

From: "Feng Cao (fcao)" <[email-masked]>
Date: Thu, 23 Oct 2008 11:44:54 -0700

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:[email-masked]] 
Sent: Thursday, October 23, 2008 4:10 AM
To: Suping ZHAI
Cc: Feng Cao (fcao); [email-masked]
Subject: Re: [Hipsec] submission of a new I-D:"Delivering Geographic

Hi,

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

	...

Security considerations:

BR,
Samu Varjonen

> Subject:[Hipsec] submission of a new I-D:"Delivering Geographic
> 
>> Hi all,
>>
>> A new I-D, draft-cao-hip-geolocation-00, was just submitted to IETF 
>> HIP WG. Your comments are always welcome.
>>