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 protected]
https://www.ietf.org/mailman/listinfo/p2psip
