[e2e] Receiving RST on a MD5 TCP connection.

Joe Touch touch at ISI.EDU
Fri Jul 1 11:22:09 PDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Mitesh Dalal wrote:
> 
> On Fri, 1 Jul 2005, Joe Touch wrote:
> 
> 
>>
>>Mitesh Dalal wrote:
>>...
>>
>>>>Another point along these lines - if you had a secure connection with
>>>>another host, then the host reboots and 'forgets' the security
>>>>altogether (i.e., doesn't reestablish keys), it shouldn't be able to
>>>>reset the old connection anyway.
>>>
>>>and why would that be Joe ? By saying so you have no love for network
>>>reliability. Do you know networks can go down if MD5 enabled LDP
>>>connection cannot recover from this problem and rely on timeouts
>>>to recover ? Do you know the same thing can happen to BGP ?
>>>Security shouldnt come at the cost of reliablity!
>>
>>New keys should - as I noted later in my post - flush state associated
>>with old keys. Lacking new keys, old state does no harm, since new
>>connections shouldn't occur.
> 
> what we are discussing is how fast can we detect a stale connections
> to a rebooted host. New keys come into picture only if the host is up.
> For TCP MD5 scenarios we dont change keys ever.

Are you worried about establishing new connections or detecting and
cleaning up old ones? The former seems like it already works as per
RFC2385; the latter isn't an issue for TCP, as there's no focus on
cleaning up state to be space efficient until such state affects new
connections.

>>Recovering from a problem doesn't mean leaving your doors unlocked.
> 
> yes, so lets use a combination lock, the owner does not have to carry
> a key around (and potentially loose it) and instead simply remember
> the right combination (hint:tcpsecure) to gain access :)

I should need to have the key to gain access via a new connection -
whether it involves cleaning up the old state or not. There's no utility
to just cleaning up old state per se unless the keys change, and we
agree that's not the issue here.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxYnRE5f5cImnZrsRAjNWAKD6ORU5KoUfMcEUAr9sXulyjTB/aQCgoitE
j7YHDHbqvJ4LKRRkP2al/ME=
=BHHh
-----END PGP SIGNATURE-----


More information about the end2end-interest mailing list