[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