[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 17, 2008, at 6:08 AM, Noel Chiappa wrote:
Well, I'm not so sure. I'm not a crypto math expert, but...

Neither am I, but...

AFAIK, this isn't an issue with public-private encryption, so I don't see a need to do periodic key rollover. (If I'm wrong about any of the crypto
aspects of all this, someone please enlighten me! :-)

My understanding is that you need to periodically replace keys in order to thwart brute force attacks (among other reasons). RFC 4641 discusses this in the context of DNSSEC in section 3.3.

And how much 'touching' of the trust hierarchy you want to impose on
the lookup agents.
Sorry, didn't follow that - can you expand a bit?

Typically, the lookup agents will need to have the trust anchors configured by some means (usually, manually). If you have multiple trust anchors, you'll need to reconfigure those trust anchors in the lookup agents every time there is a change. In RFC 4641, the recommended period for key rollover is 12 months. If you're partitioning the namespace into 256 pieces, this implies making (at least) 256 changes to the configuration of each lookup agent you are responsible for per year where one implication of doing it wrong is to completely disable routing of systems dependent on that lookup agent for some or all of the partitions of the namespace.

while only having 2 things to break when you configure your lookup
agent...

I don't expect people to be typing the master keys in! Yes, they would be distributed out-of-band ("printed in the newspaper", one wag suggested), but I was assuming they would more be included in software distributions as a
file.

This puts much trust in the software distribution mechanism (chicken- or-egg problems may lie here). In the case of DNSSEC, this turns out to be a non-trivial problem. This may be because of the idiosyncrasies of the DNS (e.g., distributed authority) and may not be applicable to what we're discussing here, however one of the lessons DNSSEC has taught me (over the 10+ years I've been involved in it, either directly or on the periphery): ignoring operational key management requirements can render whatever you come up with completely useless. FWIW.

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