On Wed, Mar 25, 2009 at 1:04 AM, Narayanan, Vidya <[email protected]> wrote: > Hi Bruce, > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:[email protected]] >> Sent: Tuesday, March 24, 2009 6:55 PM >> To: Narayanan, Vidya >> Cc: [email protected] >> Subject: Re: [P2PSIP] Configuration Updates in RELOAD >> >> 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. > > 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. >
There is a clear separation. The only thing linking the two is the need to have the key used to sign the configuration document. >> Such a manager would also have contact with the overlay and the >> 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. > I'm assuming it has a means to communicate with a peer on the overlay. Don't particularly care what it is. >> 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. >> > > 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. >> - 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. >> > > 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. > 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 >> 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. >> > > 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 > >> Bruce >> >> >> >> 2009/3/23 Narayanan, Vidya <[email protected]>: >> > 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 protected]) may contain an IP address >> to >> > reach that AOR. Eve, a misbehaving user, may store some other junk >> at >> > h([email protected]) 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 protected]) 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 protected] >> > https://www.ietf.org/mailman/listinfo/p2psip >> > >> > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
