[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Noel -

Ah, you are using global trust anchors.  That will work, yes.

One question, though:  Who will be the entity in charge of operating a
root CDR (and hence of signing ID/locator mappings)?  This entity will
be in a very powerful position -- more powerful than any entity can be
in today's Internet.  There is no single entity today that has control
over IP connectivity in a large part of the Internet.

OTOH, we do have a similar dependency on root DNS(SEC) servers.  That's
for domain-name/address mappings, though, not for base IP connectivity.

Now back to your response:

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.

Yes, that's correct.

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.

By receiving side I meant a tunnel router receiving a gratuitous mapping
in-band in a packet.  My focus here was on *initial*, though, as opposed
to a mapping update that the tunnel router may receive *subsequently*.

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?

Yes, that's right.

Thanks for discussing this in detail!

- Christian




--
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