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 PROTECTED] > Sent: Sunday, November 16, 2008 9:29 PM > To: Narayanan, Vidya > Cc: [email protected] > 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 > 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) > 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 > figure out how that could be done with your permissions model. > 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: > > - 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. > 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 > Bruce > > > > > > > On Sat, Nov 15, 2008 at 2:58 AM, Narayanan, Vidya > <[EMAIL PROTECTED]> wrote: > > > > 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 > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
