Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Brian Dickson <briand@ca.afilias.info>

    > One obvious place to put the delegations, and to manage the PKI, is
    > with dnssec signed DNS zones, where the delegations themselves would
    > already be done.

Using the DNS to hold EID->RLOC mappings was discussed earlier (and in fact,
one version of LISP, I forget which now) proposes doing that. I got the
impression that people weren't wild about the concept, for a variety of
reasons, which I will let them give lest I not do a very good job of it.

    > If the EID->RLOC mappings are done in DNS ... the tree can be walked to
    > fully populate the entire set of EID->RLOC mappings.

That's not a very efficient way to give everyone a copy of the table of
bindings, in advance. If we want to operate in that mode (and there are
doubters, see the previous conversation betwen Tony and, Yakov, I think it
was), there are much better ways to do that.


<different message>

    > To use the DNSSEC model, you *don't* want the top level entity signing
    > the *data*. ... it doesn't scale well at all.

Well, again, in the design I described the root isn't signing anything,
because the signing authority of the namespace is partitioned into zones, and
separate machines would usually be responsible for each zone (both to limit
both the scope of what's affected by a security breach, and to reduce the
amount of stuff that has to be resigned when there is a breach).

Second, given that in most cases bindings should be being updated 'often', is
there really a problem here? I mean, as long as it's a constant slow trickle
of requests for resigning, it shouldn't be a problem. If the load does become
too high, since any reasonable design should allow replicated servers, just
add more servers to that pseudo-node in their resolution hierarchy.

The only time there might be an issue is if there's a security breach, and a
lot of stuff has to be re-signed in a hurry. Not sure how hard we need to
provide for that one.


    > What DNSSEC does, is sign *delegations*, until the leaf nodes, who sign
    > their own data.
    > ...
    > Since in no case is the data itself signed by anyone other than the
    > delegatee, the risk is limited to key data scoped appropriately, where
    > key rollover is handled by the parent.

The problem is that now we have lots of keys - lots and lots of keys. Enough
keys so that you probably don't have them all pre-loaded.

Only now we're back to the problem Christian alluded to, which is that you've
bought yourself a zero performance gain: instead of needing to go out and ask
for a binding, you try and speed things up by 'gratuitously' getting the
signed binding you will need - but before you can trust it, you have to go get
the key it was signed with - which is just as slow as getting the binding!

The system I described, with the namespace dividided into a modest number of
zones, each with a separate key, was designed to balance two competing
problems: having too many keys, and the hassle caused by the compromise of a
key. Turn the knob too far one way, you have too many keys; turn it too far
the other way, and a compromise results in too big a problem.

I don't know what the right setting is, I'm keen to have the users figure
that out for themselves. But it can't be a totally local choice, because if
*I* want minute zones to minimize the effects of compromises, *other* people
wind up paying a big part of the cost (by having to support those small
signing zones).


I dunno, my email to Christian earlier discussed the possibility of having
multiple different keys (and signers) for a zone (to avoid giving the signer
too much power); a possibility for this situation is to extend that to allow
multiple zone signing delegation hierarchies, so people who wanted different
settings on that virtual 'knob' (above) could chose different ones.

(So you could have, e.g. a coarse delegation hierarchy, and a fine one, and
people could pick which one they wanted; if they wanted to have to have the
greater security of more keys, they'd also be accepting the greater overhead
of more keys.)

The thing is that that is again more complexity, and I'm wondering if it's
really worth it. I'm very concerned about the complexity level as it is. In
fact, I think I'd be more likely to say: 'if anyone wants better security,
they'll have to build a separate system to sign bindings, rather than make
the default public one overly complex'. I think that's a viable design
approach; people who want triple-titanium security can roll their own.

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg