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

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

    > From: Christian Vogt <christian.vogt@nomadiclab.com>

    > Would public-key authentication of an ID/locator mapping really reduce
    > the overhead at the receiving side compared to a look-up of the mapping
    > in a global, trusted directory ..
    > I don't think so because, for the receiving side to verify that the
    > keys used to sign the ID/locator mapping really belong to the ID owner,
    > the receiving side has to check the ID/public-key binding, and this
    > requires a look-up in a trusted directory (PKI in this case) as well.
    > So the receiving side has to do a directory look-up in any case -- be
    > it to get the ID/locator mapping, or to verify an ID/public-key mapping.

{Visualize JNC with a *very* large Cheshire-Cat grin!}

Yes, this was the exact difficulty I struggled with for some weeks! I finally
had a brainwave, and realized that if the mountain will not come to Mohammed,
then Mohammed must go to the mountain...

In a simplified form (to make understand the basic concept easier), the
signing is not done by each individual aCAR (i.e. authoritative source for
bindings - which would necessitate, as you observe, each aCAR having a
separate key, which you'd have to acquire securely, putting you right back
where you were, in terms of communication overhead); rather, the aCAR passes
its bindings up the hierarchy to the root, which signs them, and passes the
signed bindings back down to the aCAR. It is those signed bindings which the
appropriate entity hands out (either in response to a request, or piggybacked
on a request for another binding).

Since we trust the delegation hierarchy already (if you are doing a classical
lookup), if we use the same hierarchy to pass bindings up to be signed, and
then returned, we have exactly the same level of dependability.

In practise, for purely practical reasons (i.e. limiting damage in case of a
security breach) there wouldn't be a single root key (these improvements were
mostly suggested by Dave Oran, IIRC). Rather, we'd divide the namespace up
into a series of zones, each of which would have a separate key, and no
machine should hold more than one. In addition, there'd be a two-phase
system, with 'master' zone keys kept offline in a secure facility, and used
to sign 'secondary' sequence-numbered zone keys, which are what is actually
used online to sign bindings.


Yes, I know it sounds complicated, and it is - and I worry about that a lot,
because complexity always worries me a lot. ("Perfection has been attained,
not when there is nothing left to add, but when there is nothing left to take
away.") This seems to be a typical thing with security, though, that it gets
complicated - seemingly much more complex than the typical security that we
use e.g. on our houses.

The way I look at it, though, is that in a world where a master lock-picker
could try hundreds of doors in a second, we'd all be using much better locks
on our houses - and the wonderful Internet brings us not just data from a
myriad of sources around the world in the blink of an eye, it brings us
croooks from a myriad of sources around the world in the blink of an eye.
Sigh, progress always has costs as well as benefits...


    > Computational overhead of public-key authentication comes in addition
    > to the overhead of looking up the ID/public-key mapping.

Right, but I am informed that checking authentication is a lot less
computationally intensive than signing something - which is good for us, and
(helpfully) just the right direction for such an asymmetry!


    >> (And why would a receive be looking up mappings anyway? Surely it's
    >> the sender that has to look up mappings, no?)

    > But since we have to combat mapping spoofing, either we use
    > self-certifying mappings (as in Six/One, e.g.), or the receiver must do
    > a look-up in some trusted directory, too.

Sorry, not sure that I followed that. Did you mean that if you received a
'gratuitous' binding, piggybacked on a request for a binding that you held,
you'd have to do a query on that gratuitously-provided binding, to verify that
it was valid, and not a spoof?

If so, I think the built-in authentication of bindings (above) solves that one.


    > In all of the above, we are talking about the initial mapping
    > provisioning for the receiving side.

"Receiving" is a little confusing to me, since both sides are receiving
stuff. I prefer the terms 'client' and 'server', on the assumption that
although not all pairwise connections are client/server, many are, and for
all client/server interactions, the client does the lookup of the 'server
binding' first.

So, in that terminology, what I think you said there was: "In all of the
above, we are talking about providing the binding of the client, at the server
side", right?

    > While the benefits of public-key authentication are IMO limited in this
    > case

On the contrary, it's the only way I can see to authenticate the client's
binding 'on the spot' (i.e. without additional network traffic) if you
gratuitously provide it to the server, piggybacked on the client's request
for the server's binding.

    > public-key authentication may very well be suited for mapping
    > /updates/, which a sending side may want to communicate to a receiving
    > side for TE reasons.

I'm assuming this is because you're working with a model where, along with
the binding, one would have gotten a key which could/would be used to sign
updates to the binding?

	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