Subject: [P2PSIP] Configuration Updates in RELOAD

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 23 Mar 2009 11:00:51 -0700

The current RELOAD draft assumes that the configuration document specifies the kinds, the associated data models and authorization rules that are applicable for the overlay.  While it may be okay to specify the kinds the overlay supports (thereby giving a notion of available services and applications on the overlay), the other two things make this configuration document relevant during the operation of an overlay itself (rather than configuration just being a one-time thing prior to joining the overlay).  This is undesirable in my view.  For one, this involves the enrollment server into the overlay functional aspects, which departs from the notion of enrollment being a one-time thing (and the enrollment server itself not being a part of the overlay).  It also brings the question of how the latest configuration document is made available on the overlay - the enrollment server is not necessarily a peer or a client that can publish information on the overlay.

On the other hand, I think that this role for the configuration document in normal overlay operations can be eliminated if the requirement for knowledge of kind to authorization rule mapping is lifted for performing the authorization itself.  The storing node technically only needs to know the particular authorization rule that has been used for the data to be stored and verify that it passes authorization.  The enforcement of whether that is the right authorization for that kind can be done by the actual kind itself (or the usage that uses that kind).  The downside of this is that a particular misbehaving node may use a different authorization rule than what is expected for a given kind.  This may at best result in garbage being stored along with other data at a particular resource id.  For instance, if Alice is well behaved, h([email-masked]<mailto:[email-masked]>) may contain an IP address to reach that AOR.  Eve, a misbehaving user, may store some other junk at h([email-masked]<mailto:[email-masked]>) using a more flexible authorization rule (at the moment, assuming a good hash function, I can only see this being feasible using the rule that places no constraints on resource id generation).  By ensuring that data from one creator doesn't overwrite data from another node, except explicitly authorized by the creator, h([email-masked]<mailto:[email-masked]>) will now have data corresponding to multiple creators.  When the data is retrieved for consumption by a usage, it can apply an additional check to ensure that only the data with the correct authorization model is actually consumed.   It is also possible to place that restriction at the time of retrieval to prevent all junk from being transported (to save bandwidth, for e.g.).

There doesn't appear to be much downside in doing the above.  However, I'm open to other solutions that can take the configuration document out of the overlay operation semantics.   I'd like to keep the enrollment server (or any other centralized entity) to the role it is actually meant for - the more we engage these entities in overlay operations or kinds or usages, we start placing more restrictions and make it difficult to use the same design with self-signed certs and so on.

Vidya

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 24 Mar 2009 21:54:48 -0400

Hi Vidya,

So one of the key questions here is what are the use cases for
updating configuration documents.

- a managed overlay, where what the overlay supports is determined by
the entity managing the overlay.  In this case, the manager is the
only entity that should be able to authorize new kinds on the overlay.
 Such a manager would also have contact with the overlay and the
ability to inject a new configuration document.  Such a document will
propagate very fast once it is introduced on only a single peer.
There's no requirement that the actual "enrollment server" be on the
overlay, only that a document signed with the appropriate key can be
introduced onto a peer.  Given a CE overlay, for example, one could
imagine new versions of the product (or products) being issued new
configuration documents as new kinds are required.  The result is that
the CE devices automatically update to the newest config document
whenever a new device appears on the overlay, and thus before any new
kind is used on the overlay.

- The choice of self-signed peer certificates is orthogonal to the
question of the key used to sign the configuration document.
However, if you choose to deploy an overlay where anyone can generate
a new config document, I think you're right that there could be a
problem.  I could imagine a solution where any peer that notices its
resource is not in the current configuration updates the config file,
but I'm not convinced there is a significant need for this type of
scenario.  I'd be interested in use cases you believe would be
deployed this way.

I don't believe that the security issues of not having a list of
auhorized kinds, even simply registering garbage in the overlay, can
be ignored for many or even most overlays.

Bruce

2009/3/23 Narayanan, Vidya <[email-masked]>:
> The current RELOAD draft assumes that the configuration document specifies
> the kinds, the associated data models and authorization rules that are
> applicable for the overlay.  While it may be okay to specify the kinds the
> overlay supports (thereby giving a notion of available services and
> applications on the overlay), the other two things make this configuration
> document relevant during the operation of an overlay itself (rather than
> configuration just being a one-time thing prior to joining the overlay).
> This is undesirable in my view.  For one, this involves the enrollment
> server into the overlay functional aspects, which departs from the notion of
> enrollment being a one-time thing (and the enrollment server itself not
> being a part of the overlay).  It also brings the question of how the latest
> configuration document is made available on the overlay – the enrollment
> server is not necessarily a peer or a client that can publish information on
> the overlay.
>
>
>
> On the other hand, I think that this role for the configuration document in
> normal overlay operations can be eliminated if the requirement for knowledge
> of kind to authorization rule mapping is lifted for performing the
> authorization itself.  The storing node technically only needs to know the
> particular authorization rule that has been used for the data to be stored
> and verify that it passes authorization.  The enforcement of whether that is
> the right authorization for that kind can be done by the actual kind itself
> (or the usage that uses that kind).  The downside of this is that a
> particular misbehaving node may use a different authorization rule than what
> is expected for a given kind.  This may at best result in garbage being
> stored along with other data at a particular resource id.  For instance, if
> Alice is well behaved, h([email-masked]) may contain an IP address to
> reach that AOR.  Eve, a misbehaving user, may store some other junk at
> h([email-masked]) using a more flexible authorization rule (at the
> moment, assuming a good hash function, I can only see this being feasible
> using the rule that places no constraints on resource id generation).  By
> ensuring that data from one creator doesn’t overwrite data from another
> node, except explicitly authorized by the creator, h([email-masked]) will
> now have data corresponding to multiple creators.  When the data is
> retrieved for consumption by a usage, it can apply an additional check to
> ensure that only the data with the correct authorization model is actually
> consumed.   It is also possible to place that restriction at the time of
> retrieval to prevent all junk from being transported (to save bandwidth, for
> e.g.).
>
>
>
> There doesn’t appear to be much downside in doing the above.  However, I’m
> open to other solutions that can take the configuration document out of the
> overlay operation semantics.   I’d like to keep the enrollment server (or
> any other centralized entity) to the role it is actually meant for – the
> more we engage these entities in overlay operations or kinds or usages, we
> start placing more restrictions and make it difficult to use the same design
> with self-signed certs and so on.
>
>
>
> Vidya
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Mar 2009 22:04:00 -0700

Hi Bruce,

> -----Original Message-----
> From: Bruce Lowekamp [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2009 6:55 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [P2PSIP] Configuration Updates in RELOAD
> 
> Hi Vidya,
> 

This may be one model, but I certainly don't think this is the only model possible for managed overlays. I think we are being way too narrow here with our views on how this may get deployed. I can envision several types of managed overlays, especially ones where the enrollment, as a function, may be provided by some entity that is completely different from the service providers on those overlays that are offering services/applications.  I'd like to see a clear separation in functionality between the enrollment server and any involvement in actual operations of the overlay, including the types of services that are offered on the overlay.  I think this functional separation is essential to ensure that we provide flexible deployment options.  

> ability to inject a new configuration document.  

You are assuming here that the manager communicates with a node on the overlay potentially via out-of-band means to do this.  

> Such a document will

Pardon my ignorance - what's a CE overlay? 

> scenario.  I'd be interested in use cases you believe would be

Are you asking for use cases that will be deployed with self-signed certs at all or use cases that operate with self-signed certs where the peers are updating config files?  Of course, there are plenty of use cases for just the former.  For the latter, I'd argue that the config file serves no purpose other than strict config parameters and hence, should never need to be updated as part of the overlay operations. 

> be ignored for many or even most overlays.

Actually, I don't think so.  Storing garbage on the overlay is feasible anyway and an authorized node could also do this.  So, I don't think removing this kind-specific authorization requirement at the overlay level is going to make any significantly worse.  The additional authorization steps that can be applied at the kind and/or data retrieval level can always remedy it too - so, I am not seeing a great risk here. 

Vidya

---

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 25 Mar 2009 08:11:24 -0400

> This may be one model, but I certainly don't think this is the only model possible for managed overlays. I think we are being way too narrow here with our views on how this may get deployed. I can…

There is a clear separation.   The only thing linking the two is the
need to have the key used to sign the configuration document.

> You are assuming here that the manager communicates with a node on the overlay potentially via out-of-band means to do this.

I'm assuming it has a means to communicate with a peer on the overlay.
 Don't particularly care what it is.

> Pardon my ignorance - what's a CE overlay?

Sorry, consumer electronics.  So suppose KodMinNik offers both cameras
and digital picture frames that form an overlay in the home.  The
first generation products all have the same types, and thus the same
overlay config file signed by KodMinNik.  When the second generation
of products are released, there are a couple new types, and thus a new
config file signed by KodMinNik.  When a 2nd generation product is
introduced into a home for the first time, the 1st generation devices
will see the new config file and update their copy.  Even though
KodMinNik has no direct contact with the individual overlay, any
device that requires the new types will have a signed config document
that all the old devices would recognize, so the overlay is managed
and reliability is ensured by KodMinNik without an active presence.

> Are you asking for use cases that will be deployed with self-signed certs at all or use cases that operate with self-signed certs where the peers are updating config files?  Of course, there are pl…

I was asking for use cases where there is a need for multiple peers to
introduce new types that would somehow not be known to the peer
starting the overlay.  i.e. please give a specific use case where the
config update mechanism in the current base draft presents a problem.

Bruce

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 25 Mar 2009 09:50:46 -0700

<snip>

>  I'd like to see a clear separation
> in functionality between the enrollment server and any involvement in
> actual operations of the overlay, including the types of services that
> are offered on the overlay.  I think this functional separation is
> essential to ensure that we provide flexible deployment options.
> >
> 

That doesn't sound like clear separation to me.  Let me put it another way - I'm looking for no dependencies between the operation of kinds/usages on an overlay and the overlay management itself (configuration being one aspect of the latter).  These functions may be provided and managed by different entities and we need to allow for such a model. 

<snip>

> and reliability is ensured by KodMinNik without an active presence.

Interesting that you explain overlay as an element provided and managed by entities that offer devices and see the overlay as operating just among those devices.  I look at it entirely differently.  Consider the case of a Kodak camera, a Sony TV, my Verizon phone, my PC at home that is on the Comcast network all forming an overlay.  This is an overlay of all my personal devices.  This is also a perfect candidate for not needing an enrollment server at all - a shared secret based admission control works fine.  However, when a new photo display application pops up, for instance, I'd like my camera and TV to support it such that I can display the photos from my camera on my TV.  Once I get the necessary upgrades to support the new kinds, from say, the provider of this photo display app, Foo, there is no reason why my PC or phone or any other part of the overlay functions on my camera or TV even should trust a certificate signed by Foo.  The only entities that need to trust it are the new usage instances on the camera and TV.  

Imagine the overlay to be analogous to the Internet.  All usages on the overlay are like services on the Internet.  You may need access control to get on the overlay (just like you need to log into Comcast or Yahoo to get on the Internet) - but, that provider has nothing to do with the services that run on it.  Ultimately, you trust Amazon's certificate when you are using Amazon's services; not Comcast's.  

The point in all this is clearly not to debate particular deployment models or what will eventually succeed - but, it is that we must be making different deployment models feasible.  

Best,
Vidya

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 26 Mar 2009 08:11:27 -0400

> That doesn't sound like clear separation to me.  Let me put it another way - I'm looking for no dependencies between the operation of kinds/usages on an overlay and the overlay management itself (c…

So let's break this up into two questions:

First, is the entity that forms the overlay the one that decides what
goes in it?

I would say the answer to this is clearly yes.  I hope we can agree on
that, subject to the second question.

Second question is whether that entity can decide that what they
really want to do is support an anything-goes overlay?

I'm actually OK with this, I just think that the result of the process
needs to be that there is a configuration document that gets updated
reflecting what's going on in the overlay.  The short summary, I
think, is what we would need would be a draft specifying how a group
of peers decide to update the overlay config in a completely ad hoc
case where there is no central administrator of any type (not even the
home owner running a control panel on their PC).

Here's why I think this is important.  Split the kinds into two types
based on whether they're IANA registered or not.

If they are IANA registered, then the data-model and access-control
attributes are predefined.  The only ones that are allowed to vary by
overlay are max-count and max-size.  Personally, I think these are
useful to specify, but I don't think it would be that big a deal if
they weren't in unmanaged cases.  So the only purpose of the
configuration file here is so that devices don't need to constantly
query IANA for the complete list of all registered kinds, even ones
they don't care about.

More importantly, let's look at non-IANA kinds.  Here the
configuration file serves two purposes:
- define the access control
- establish the kind-id to be used on the overlay.

I still disagree that access control can be defined on a per-user
basis, since I think there will be lots of problems if two devices
arrive expecting different access control policies for the same kind,
and I think allowing this opens up a number of other security attacks
that don't exist otherwise.

But, more importantly, how do you determine kind-ids without a config
document that is updated either by an overlay manager or by a
distributed algorithm?  If two devices from the same manufacturer are
on the same overlay, they need to be using the same kind-id if there
is any intent to share data.

So, I'm OK without a central overlay manager, but I think the only
alternative is to write a protocol for distributed generation of the
config file.

Bruce

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 26 Mar 2009 17:10:43 -0700

> really want to do is support an anything-goes overlay?

I'm afraid there is a fundamental difference here between what we are saying.  Unfortunately, my answer to your first (and second) question(s) is no.  

Going back to my Internet analogy, the entity providing identities and credentials to access the overlay may be entirely different from the one or more entities that may be providing services on the overlay.  Clubbing the two is analogous to saying that the entity that provides me with an IP address today gets to tell me what applications or web sites to access on my laptop.  Certainly, that would be undesirable.  Even in the mobile market, things are going the other way.  What applications run on the iPhone or the GPhone are not really determined by the operator any more (of course, outside the North American market, this has been true for a while now).  

An overlay configuration document handled by the overlay provider must not have anything to do with kinds or usages on the overlay which may be coming from various services offered on the overlay from different providers. Otherwise, we are creating a model which is going to limit deployment options and I don't think our intent here is to create a walled garden for overlays. 

Best,
Vidya

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 26 Mar 2009 22:42:36 -0400

Let's make sure we're talking about the same thing.

If someone wants to (I don't, but some do) create a competitor to
Skype, and they deploy the appropriate servers, I want them to be able
to specify exactly what may be stored on their overlay (in this case
the resources that their application uses, with exactly their rules).

Similarly, if someone wants to deploy another OpenDHT, I think they
should be able to.  (I don't want to do this either, FTR.)

Your answer seems to say that a provider should not be able to use
this protocol to deploy an overlay that only stores what they want it
to do.  Is that really what you're saying?   Philosophically, I guess
we could have a debate whether a provider *should* do this, but I
don't believe we should try to forbid it within the protocol.

Bruce

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Mar 2009 10:04:30 -0700

I'm not talking about restricting the cases where an overlay operator also wants to have control on what's allowed on the overlay.  However, I'm talking about not restricting that to be the only deployment possibility. 

By mingling kinds and usages into the overlay configuration document, we are placing that restriction.  If we separated those out, a particular deployment can always collocate it into the same entity and it is not a problem. 

Vidya

> Sent: Thursday, March 26, 2009 7:43 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: Separation of identity assignment and service provider
> roles (RE: [P2PSIP] Configuration Updates in RELOAD)
> 
> > I'm afraid there is a fundamental difference here between what we are
> saying.  Unfortunately, my answer to your first (and second)
> question(s) is no.
> >
> > Going back to my Internet analogy, the entity providing identities
> and credentials to access the overlay may be entirely different from
> the one or more entities that may be providing services on the overlay.
>  Clubbing the two is analogous to saying that the entity that provides
> me with an IP address today gets to tell me what applications or web
> sites to access on my laptop.  Certainly, that would be undesirable.
>  Even in the mobile market, things are going the other way.  What
> applications run on the iPhone or the GPhone are not really determined
> by the operator any more (of course, outside the North American market,
> this has been true for a while now).
> >
> > An overlay configuration document handled by the overlay provider
> must not have anything to do with kinds or usages on the overlay which
> may be coming from various services offered on the overlay from
> different providers. Otherwise, we are creating a model which is going
> to limit deployment options and I don't think our intent here is to
> create a walled garden for overlays.
> >
> > Best,
> > Vidya
> >