Subject: [P2PSIP] Usages and Overlay Operation in RELOAD

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 14 Nov 2008 23:58:21 -0800

At the moment, some of the overlay operation semantics in RELOAD are not usage agnostic and there is also an inherent assumption that all nodes in the overlay support the same set of usages and kinds.  One big problem with this is that it will then require a flag day to upgrade all nodes when usages evolve to continue having a functional overlay.  This is quite unrealistic in a distributed system and hence, there is a huge benefit to keeping the overlay level operations themselves usage agnostic.  This also nicely allows creation of multi and heterogeneous usage overlays - i.e., not all nodes will then be required to support all usages (or the same usage versions) in the overlay.  

In order to avoid writing a long email to explain the problem and potential solutions, I wrote it up in a draft instead.  For now, I've posted it at http://www.geocities.com/hellovidya/draft-vidya-p2psip-usage-agnostic-reload-00.txt.  

It is a very quick and dirty writeup - so, apologies for any oversights and blatant errors.  The main body of the draft is reasonably short - I'd appreciate people reading and sending their thoughts on the issues and proposed solutions to those. 

Thanks,
Vidya
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 17 Nov 2008 00:28:30 -0500

Vidya,

Thanks for writing up your thoughts on the usage-agnostic draft.  It
might have been put together fast, but it's more than enough to get
started with.

I shouldn't speak for him, but Henning, in particular among the
authors, has some thoughts about the data model along these lines.  We
made a few changes a couple revisions ago (I think going into
draft-ietf-p2psip-reload-00) in the direction of allowing dynamic data
models, but like you said in your draft, the picture isn't clear in
reload.  I think your draft does a good job starting a conversation
about the issue.

<tangent>
First, I want to try to be careful about terminology here.  A usage
defines certain kinds, and the permissions model is specific to that
kind (which can be important if it's used in a second usage).  So I
think I would say that what you propose is a kind-agnostic permissions
model.  (And I freely admit that the base draft may not be completely
consistent in its usage of these terms, either.)  There's an
implementation detail that it may be a usage-plugin implementing the
security model, but that's somewhat separate from the protocol.
</tangent>

As I understand your draft, it proposes a data permissions model where
the resource-id is calculated with a known fixed formula and where all
data stored is required to be signed by the identity (user name) used
to calculate the resource-id.  Please correct me if that's an
incorrect summary.  (and will probably have to disregard the remainder
of this email)

That's a very valid model that solves the problems you've identified,
but I'm not sure it's sufficient for all purposes.  For example, how
could you implement voicemail stored in the overlay for offline
users?  If Bob leaves a message for Alice, he can maybe store the
message keyed under his own username, but still needs to somehow store
a pointer to that message in something alice knows to check.  I can't
figure out how that could be done with your permissions model.

The other problem with allowing dynamic kind-id usage is that it offers
a very easy way to DoS the overlay, since a single rogue peer can
flood the overlay with an unbounded number of resources.  Of course,
if all resource id's are calculated the same way, then a single peer
winds up being responsible for them, so it only DoSes a single peer at
a time, but that's still not a good result.

Having said that, I think there are very valid use-cases for this type
of model.  Here's a possibility:

- an overlay should have a default data permissions model specified in
  the overlay configuration.  These could be usage-defined-kinds-only,
  default-open-security (no requirement of identity ownership for
  storing a resource), or default-identity-security (what your draft
  describes)

- in all three models, a usage can define its own data permissions
  model that is different than the default

I think that allows flexibility to meet the security requirements of
different deployments.

In an overlay with usage-defined-kinds-only security, there's still
the question of how you migrate to requiring a new kind on the
overlay.  ASP had a sketch of a solution for upgrading protocols that
essentially maintained two separate overlays until a sufficient
portion of peers had updated at which point the old overlay was
discontinued.  I think you could do something with having peers
periodically check the overlay configuration (or another source) to
see if new kind-ids are going to be required and apply appropriate
updates to their software.  The overlay could run with the two
different kind-ids being used until a sufficient amount of time had
passed.  That's a little complicated, but I think it would work.  I
don't see a need to define it as part of the base protocol right now,
since I don't think all deployments will need it (and it's pretty
complicated).

Bruce

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 16 Nov 2008 23:43:55 -0800

Bruce,
I'll just respond to a few quick things here for clarification.  I haven't heard from the chairs yet, but, I'm hoping that we can have a more in-depth discussion at the meeting.   

> -----Original Message-----
> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Sunday, November 16, 2008 9:29 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [P2PSIP] Usages and Overlay Operation in RELOAD
> 
> Vidya,
> 
> Thanks for writing up your thoughts on the usage-agnostic 
> draft.  It might have been put together fast, but it's more 
> than enough to get started with.
> 
> I shouldn't speak for him, but Henning, in particular among 
> the authors, has some thoughts about the data model along 
> these lines.  We made a few changes a couple revisions ago (I 
> think going into
> draft-ietf-p2psip-reload-00) in the direction of allowing 
> dynamic data models, but like you said in your draft, the 
> picture isn't clear in reload.  I think your draft does a 
> good job starting a conversation about the issue.
> 
> <tangent>
> First, I want to try to be careful about terminology here.  A 
> usage defines certain kinds, and the permissions model is 
> specific to that kind (which can be important if it's used in 
> a second usage).  So I think I would say that what you 
> propose is a kind-agnostic permissions model.  (And I freely 
> admit that the base draft may not be completely consistent in 
> its usage of these terms, either.)  There's an implementation 
> detail that it may be a usage-plugin implementing the 
> As I understand your draft, it proposes a data permissions 
> model where the resource-id is calculated with a known fixed 
> formula and where all data stored is required to be signed by 
> the identity (user name) used to calculate the resource-id.  
> Please correct me if that's an incorrect summary.  (and will 
> probably have to disregard the remainder of this email)
> 

This is partly correct.  From what I understand, this is also the model in RELOAD for the currently defined kinds with one difference - here, I talk about allowing the data to be spread around by using the identity as only one part of the input to the hash function used to compute the resource-id. I also propose authorization at the value level, rather than the resource-id level to allow easy querying - more on that below. 

> That's a very valid model that solves the problems you've 
> identified, but I'm not sure it's sufficient for all 
> purposes.  For example, how could you implement voicemail 
> stored in the overlay for offline users?  If Bob leaves a 
> message for Alice, he can maybe store the message keyed under 
> his own username, but still needs to somehow store a pointer 
> to that message in something alice knows to check.  

Yes, and these type of scenarios are the reason I have the following requirement: 

"The overlay MUST provide the ability for a querier to look up a
      service without having prior knowledge of the user name or node id
      of the entity offering the service.  For e.g., a node looking for
      TURN services cannot be realistically expected to know the
      corresponding user names or node ids." 

I gave the TURN service as an example where the querier doesn't know what identity to look for, but, voicemail is also a perfectly good example as you say. 

> I can't 

I talk about applying the authorization at the value level rather than the resource-id level to address this.  See paragraph 3 of section 4.2. 

> The other problem with allowing dynamic kind-id usage is that 

What is a dynamic kind-id usage? 

> it offers a very easy way to DoS the overlay, since a single 
> rogue peer can flood the overlay with an unbounded number of 
> resources.  Of course, if all resource id's are calculated 
> the same way, then a single peer winds up being responsible 
> for them, so it only DoSes a single peer at a time, but 
> that's still not a good result.
> 

I hope we are not taking on the mission of eliminating DoS attacks :)  

> Having said that, I think there are very valid use-cases for 
> this type of model.  Here's a possibility:
> 
> I think that allows flexibility to meet the security 
> requirements of different deployments.
> 

I don't think this is the level at which we should be supporting flexibility.  This comes at the cost of having various ways of providing basic overlay primitives which is not good.  

> In an overlay with usage-defined-kinds-only security, there's 
> still the question of how you migrate to requiring a new kind 
> on the overlay.  ASP had a sketch of a solution for upgrading 
> protocols that essentially maintained two separate overlays 
> until a sufficient portion of peers had updated at which 
> point the old overlay was discontinued.  I think you could do 
> something with having peers periodically check the overlay 
> configuration (or another source) to see if new kind-ids are 
> going to be required and apply appropriate updates to their 
> software.  The overlay could run with the two different 
> kind-ids being used until a sufficient amount of time had 
> passed.  That's a little complicated, but I think it would 
> work.  I don't see a need to define it as part of the base 
> protocol right now, since I don't think all deployments will 
> need it (and it's pretty complicated).
> 

I think the notion of having separate overlays to handle every upgrade must not be entertained - especially not for proper functioning of the overlay primitives itself, which fundamentally have nothing to do with the usages or kinds.  We are conflating DHTs with application level data and creating an unnecessary interwoven relationship between the two.  The notion of separate overlays during upgrades may still be needed in some extreme cases and DHT upgrades itself, but, that should not be the expectation for adding new usages or upgrading usages in the system. 

Vidya

> > At the moment, some of the overlay operation semantics in 
> RELOAD are not usage agnostic and there is also an inherent 
> assumption that all nodes in the overlay support the same set 
> of usages and kinds.  One big problem with this is that it 
> will then require a flag day to upgrade all nodes when usages 
> evolve to continue having a functional overlay.  This is 
> quite unrealistic in a distributed system and hence, there is 
> a huge benefit to keeping the overlay level operations 
> themselves usage agnostic.  This also nicely allows creation 
> of multi and heterogeneous usage overlays - i.e., not all 
> nodes will then be required to support all usages (or the 
> same usage versions) in the overlay.
> >
> > In order to avoid writing a long email to explain the 
> problem and potential solutions, I wrote it up in a draft 
> instead.  For now, I've posted it at 
> http://www.geocities.com/hellovidya/draft-vidya-p2psip-usage-a
gnostic-reload-00.txt.
> >
> > It is a very quick and dirty writeup - so, apologies for 
> any oversights and blatant errors.  The main body of the 
> draft is reasonably short - I'd appreciate people reading and 
> sending their thoughts on the issues and proposed solutions to those.
> >
> > Thanks,
> > Vidya