Subject: [Geopriv] Comments for draft-winterbottom-geopriv-held-context-00.txt

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jul 2007 15:03:06 +0200

I have read this draft and here a some high-level comments.

Summary: The document allows contraints to be put along with an LbyR. 
Currently, this document lists only a single element, namely lifetime.
Furthermore, thoughts are spend about the extensibility mechanism.

I believe it is important to put constraints on the reference to 
location information. Namely, the lifetime of the reference, putting 
constraints on the usage of the usage of it and the ability to delete a 
reference (sort of revocation of the reference). I think that this 
functionality already starts with basic features like saying "this 
reference refers to my current location only instead of allowing the 
dereferencing node to fetch the most recent location information".

The extensibility concept seems to be fine as well.

I thought that the document was quite long and difficult to read given 
that it introduces a pretty simple concept. There might be the 
possibility to reduce the number of pages to ensure that the document is 
read. I guess I am the first person that posted comments to the list. 
The term "context" might also confuse people a bit.

Regarding the lifetime mechanism you need to indicate that the LCS may 
reduce the suggested lifetime by the client by including the "correct" 
value into the response message. The functionality for doing this is 
already in the base HELD specification.

The security mechanisms are also pretty simple and rely on a handle to 
the state information via the <id> element. Given that there is TLS 
protection I believe that this should be more than sufficient.

"
   The context id provided by the LCS to the End-Point in the
   <contextResponse> MUST be unique per context, and SHOULD be different
   from the identifier provided in any generated location URI.  This
   latter constraint ensures that possession of a location URI does not
   automatically provide access and control over the internals of the
   context.
"

I think you want to say that the <id> element should contain a random 
value with at least 128 bits of  entrophy.

At some places you speak about denial of service attacks through an 
overload on contexts. I couldn't quite see the denial of service aspect 
here unless you refer to the fact that a client may create many 
different LbyRs and provides some context information with them. Is that 
the type of attack you see?

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 09:30:59 -0500

Hi Hannes,

Thanks very much for the useful comments.
I deliberately tried to keep the draft simple by keeping the base
functionality to a minimum, but with clear extensibility guidelines, so
I am pleased that this part at least came out. 

Other comments inline.

> dereferencing node to fetch the most recent location information".

[AJW] I agree that this is a good use-case. I would see this as an
extension to the general context framework however.

> already in the base HELD specification.

[AJW] Good point. I shall add this to the document.

>    automatically provide access and control over the internals of the

[AJW] Okay.

> value with at least 128 bits of  entrophy.

[AJW] Okay.

> the type of attack you see?

[AJW] Yes, this is how I was seeing it. You don't want an end-point for
example creating thousands of long lasting contexts and bringing down
the server. But it may be reasonable for a host to have more than one.

> Hannes

Cheers
James
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 12:04:03 +0200

Describing properties of the URL sounds like a service description to 
me, i.e., meta data related to the URL. Managing the content of the URL 
seems like a completely different problem. Rather than inventing a 
completely new architecture and mechanisms, it would be worthwhile to 
look what others have done, e.g., in the WebDAV space.