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]<mailto:[email protected]>) may contain an IP address to reach that AOR. Eve, a misbehaving user, may store some other junk at h([email protected]<mailto:[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]<mailto:[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
