Re: [tcpm] TCP-AO: Text for New_Key Process

At Thu, 29 Jan 2009 09:16:36 -0800,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, Eric (et al.),
> 
> To others - it might be useful to weigh in on this discussion...
> 
> Eric Rescorla wrote:
> > At Thu, 29 Jan 2009 07:15:15 -0800,
> ...
> >> We can bury the mechanism I suggest inside TCP-AO if desired, but I
> >> think that just ends up making it even more heavyweight. Automated key
> >> management is a mechanism that does not need to be inside TCP-AO - we
> >> were given that direction by the ADs from the start.
> > 
> > I don't consider this to be automated key management, and I don't
> > think it's very productive to argue about the direction from the ADs
> > gave us. My understanding from the discussion in MSP was that there
> > was general WG consensus that the protocol ought to include some
> > mechanism for automatic switchover of manually configured keys
> > without real-time coordination. The minutes aren't as explicit
> > as one might like but sort of reflect this when they say: 
> > 
> > "***ACTION*** GL will write the text up explaining all of this"
> 
> Greg was a proponent of it, and we were all interested in hearing what
> he was thinking; I don't recall anything beyond interest in seeing the
> details. Upon examining it in detail, it involves coupling directly with
> TCP exchanges in a way I think is out of scope based on what I recall
> the ADs saying - they can certainly remind us of what they're thinking
> now...

Well, as I said earlier, there are ways to do this that don't
couple to TCP. I.e., TCP-AO just chooses the occasional existing
packet to probe with. 

> > Well, you've now sort of reinvented the mechanism I originally
> > suggested and which is in Greg's message,
> 
> Not really; the difference is that in my example side A can tell side B
> it's ready to switch keys without ANY impact to side B; side B can
> switchover when its ready.

Yes, but you rely on correct receipt to confirm the switch.

> > but this is worse IMO because
> > substantial numbers of packets may be lost at one time before you can
> > switch over. 
> 
> Yes, packets are lost when you switchover and the key is wrong in my
> mechanism. However, NO packets are lost when the key is right, vs.
> Greg's mechanism which loses all probe packets until the other side is
> ready. The impact of the lost probes depends on the variant used; if no
> new TCP segments are generated, then the lost probes impact TCP's
> congestion control. 

Yeah, I'm having a really hard time getting worked up about the
impact of losing one packet every hour or so.

> > Granted, this only happens with misconfiguration but it
> > makes misconfiguration quite bad. And the logic around failure also
> > becomes quite complicated. How long do I wait before I decide the
> > other side has screwed up? 
> 
> IMO, that's the benefit - it's up to the user, not the TCP-AO
> implementation to decide that.

I don't consider that a benefit in terms of either interop or user confusion.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm