Re: [tcpm] question about TCP-AO and rekeying

[Eric Rescorla <[e-mail]>]

At Thu, 18 Jun 2009 07:08:29 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> >> It's a bit overgeneralized above, but clamp it down a bit more and it
> >> might still make sense, e.g.:
> >>
> >> 	alpha		from ME:ANY to JOE:BGP KEYID=6
> >> 	beta		from ME:ANY to JOE:ANY KEYID=7
> >>
> >> I.e., I may want to lock BGP with a different key than other connections
> >> between the two, but OK to use a single key for the rest.
> > 
> > Why would you want to do this?
> > 
> > The configuration you propose would still leave you vulnerable to
> > packet injection by someone who knew key alpha.
> > 
> > Going up a level, I'm skeptical of this entire line of argument.
> > The existing rationale for this technology (BGP DoS prevention)
> > doesn't really justify engineering for extensively complicated
> > key use policies.
> 
> The policy above would be used to utilize a stronger key/algorithm for
> BGP, and a weaker one for other exchanges - such as would be used to
> protect the transport of other protocols used in tandem with BGP, e.g.,
> SNMP or DNS (each over TCP).

Well, remember that this technology really only makes sense as 
an anti-DoS measure. Otherwise you might as well use TLS.
So, I'm not overly concerned with the idea that people want
to use it as a generic communication protection measure for
arbitrary TCP-based protocols *and* that they want to
use this clumsy a key management scheme.


> I agree that non-overlap is necessary to avoid injection. The trouble is
> that there are different ways to avoid non-overlap which we are
> currently leaving as "implementation dependent". If we leave them open,
> I am concerned that KMPs will not be able to ensure that two endpoints
> will pick corresponding MKTs for a given segment.

Really? I would imagine this is precisely the invariant that some
putative KMP would enforce.

-Ekr