Subject: [P2PSIP] Dynamically introducing new types

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Dec 2008 08:44:21 -0800

One of the topics that came up a number of times in the RELOAD design
discussions, and then was recently raised by Vidya was the introduction
of new kinds. There are actually two issues here:

1. How to tell peers in a running overlay that they are now 
   required to support a new kind.
2. How to introduce new kinds that peers aren't necessarily 
   assumed to know about.

Problem (1) is a notification problem. Problem (2) is a problem of
adding enough richness to the configuration document that it can
describe new kinds to peers that don't already have software that
implements them. Note that problem (1) can exist even independent
of (2), if, for instance, you want to add a new kind defined in
some RFC, but that wasn't initially part of the overlay config.
It also applies if (for instance) you want to change the size
limits on a given kind.

INTRODUCING NEW KINDS
Let's deal with issue (2) first. 

S 11.2 currently specifies the following information in each
"required-kind" production in the configuration document.

      *  name:  a string representing the kind.
      *  max-count:  the maximum number of values which members of the
         overlay must support.
      *  max-size:  the maximum size of individual values.

I think when we defined "name" we were intending it to match up to some
name in an IANA registry, so you could look up the kind definition,
but it's unclear.

In any case, I think what we want to do is the following:

(a) Some kinds are defined in RFCs and they get defined names and
    code points.
(b) Some large fraction of the code point space is reserved for 
    overlay-specific kinds that can be introduced by the overlay
    configuration without IANA registration.
(c) The overlay configuration language is rich enough to allow the
    definition of new kinds that are generally like the kinds we
    already have.

Note that I'm not suggesting that arbitrary non-configuration server
nodes be able to introduce new kinds. That seems to me to break the
security model (though see below for configuration update).

In order to accomplish (c), then, we need to allow the configuration
document to specify the information in 6.3.5.3, namely:

   o  The meaning of the data to be stored.
   o  The Kind-ID.
   o  The data model (single value, array, dictionary, etc.)
   o  Access control rules for indicating what credentials are allowed
      to read and write that Kind-ID at a given location.

The first element is just a freeform string. The second is an integer.
The third is just one of the data models. So, it's easy to specify
XML for all of these, but I won't try to do that here.

This leaves us with the access control model. Rather than specify
a new language, I propose that we simply allow some finite (and small)
list of access control policies that map to what we know we are
currently using. Any more complicated access control policy requires
a new RFC (or something) to register the kind or the policy. Here's
the policies I think make sense:

   - User must have a certificate with H(user_name) == Resource-ID
     in order to write or delete.
   - User must have a certificate with H(user_name) == Resource-ID
     in order to write or delete and Node-Id matches the dictionary
     key [used for SIP Registration]
   - User must have a certificate with H(NodeID)    == Resource-ID
     in order to write or delete.
   - User must have a certificate with H(NodeID || integer) == Resource-ID
     for integer < X in order to write or delete. [used for TURN service]
   - Any user may write. User must have a certificate with H(user_name)
     == Resource-ID in order to overwrite or delete [allegedly useful
     for voice mail.]

This list is deliberately minimal, and I could be convinced to add or
delete one or two of these. My thought was we would just define these
by name (or number). Then you would introduce new kinds by saying,
for instance:

     <required-kind name="NEW-KIND" 
      kind-id="55555", data-model="single-value" 
      access-policy="username-match"  max-values="10"
      max-size="1000"/>

UPDATING RUNNING OVERLAYS
The other problem is how to update a running overlay to indicate that
a new kind needs to be supported. There are a number of possibilities
here. 

- Simply update the configuration management document and force 
  nodes to go back as needed (e.g., whenever they see an unknown
  kind.)
- Update the configuration management document and have some 
  overlay-based notification protocol.
- Have some way to get the configuration document out of the overlay.

The first two have the difficulty that they require a fairly high level
of uptime from the configuration server. In addition, the first potentially
creates a lot of load on it from a misbehaving nodes which repeatedly
send bogus kind-ids. So, I lean towards the third option, but this requires
two new technical capabilities:

(1) The ability to fetch the configuration document from an arbitrary node.
(2) A signature over the configuration document.

(2) is easy and just requires protocol definitions. I can imagine a number
of ways to do (1), but the most natural seems to be that we define a
new method/kind-id/something that lets a node say "give me the latest
copy of the config document you have" to any other node. This would
let you poll, and also when a node asks you to store new kind-id 5555, it 
presumptively knows about that kind-id and you can ask for a new config
document from it.

As I said above, config documents need to be signed, presumably by the
certificate that the config server would use for TLS. However, if you
wanted to operate an overlay where anyone could introduce new kinds
(effectively where all are trusted), you could presumably operate
with unsigned config documents.

-Ekr

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 24 Dec 2008 13:05:26 -0800

What you are suggesting is to still do kind-specific data authorization and access control, but allow dynamic addition of new kinds.  I think this works, but, it is simpler to just do this at the overlay level - this means indicating the type of authorization used in the protocol (say, we define the 5 or so rules you have below and allow that to be signaled in the protocol).  Having it tied to the kind allows additional verification that the particular authorization model is indeed the right one to use for that kind - unless we need that property, I don't see a reason to tie it to the kind itself.  Mainly, it avoids the complexity of having to deal with storing an updated overlay config document on the overlay and dealing with version control of it and so on.  There is the problem of how does a node know that a given overlay config document is the most recent one.  In general, I'm not a fan of introducing more functions that may need central control and coordination than necessary for a p2p system. 

Especially in the case where any node is trusted to create new kinds, the kind-level complexity doesn't buy anything.  In general too, I wonder about how much the property of verifying the right authorization model being applied to a kind is really buying.  Every authorization rule we'd have should achieve the property of ensuring that only authorized nodes are able to write/modify a particular piece of data.  Arguably, the data is not of much use unless the right authorization model was applied to it, as specified by the usage.  The owner of the data gains nothing by applying the wrong authorization rule, as far as I can tell.  And, if the wrong rule was applied, it likely cannot be queried that easily (given that usages will assume a certain authorization model to compute the resource id for a query).  

So, I prefer that we signal the authorization rule in the protocol rather than have this complexity of having kind level knowledge in order to perform the authorization. 

All that said, I agree with the 5 rules you wrote below.  I'd recommend adding the following: 

- User must have a certificate with H(NodeID || "usage specific string") == Resource-ID and 
- User must have a certificate with H(user_id || "usage specific string") == Resource-ID

This allows the flexibility to usages to qualify the data they are storing as they see fit.  

- Vidya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Rescorla
> Sent: Friday, December 19, 2008 8:44 AM
> To: [email-masked]
> Subject: [P2PSIP] Dynamically introducing new types
> 
>