[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
Noel,
On Jan 16, 2008, at 11:06 AM, Noel Chiappa wrote:
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
Well, to start with, there is no single entity which signs bindings
for the
entire namespace - as I mentioned, we would probably want to split the
namespace up into zones (e.g. maybe /8's), and have a separate key
(and
signing entity) for each zone, in part so that no single break-in can
compromise (and require re-signing of) bindings across the entire
nameapace.
Isn't the implication of this a need to rollover multiple keys for the
multiple namespace authorities, that is, instead of having 1 trust
anchor that you periodically rollover, you have 256? (I'm assuming
you would need to rollover keys as a normal part of security hygiene).
We can change that, but it's really a question of how much
configuration
overhead one wishes to incur, versus the amount of flexibility in
terms of
distributing that 'power'.
And how much 'touching' of the trust hierarchy you want to impose on
the lookup agents.
more powerful than any entity can be in today's Internet. There is
no u
single entity today that has control over IP connectivity in a large
part of the Internet.
Well, what about the DNS root? Yes, there are multiple roots, but
they contain
the same data. Ooops, I see, you make that exact point:
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.
True.
Being somewhat in the crosshairs of the root signing situation with
DNSSEC, I should probably point out that the political ramifications
of a single root are decidedly non-trivial (and that's just for
something that has limited impact on whether packets get from A to
B). But then again, having multiple roots means the lookup agents
have multiple chances of getting things wrong.
So, let me know what you think about the 'multiple independent signing
authorities' concept as a way to deal with the sole (per zone)
global trust
anchor issue you raised; if that doesn't work, I'll see if I can
come up with
something better.
What are your thoughts on multiple independent signing authorities,
with each authority signing the bindings for the entire namespace? If
you have (say) 2 independent trust anchors for the entire namespace
then you could cross validate (if necessary... sort of like getting a
second opinion if validation fails) while only having 2 things to
break when you configure your lookup agent...
Regards,
-drc
--
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