[e2e] Receiving RST on a MD5 TCP connection.

Joe Touch touch at ISI.EDU
Fri Jul 1 12:49:10 PDT 2005


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



Tapan Karwa wrote:
>>TCP doesn't focus on cleaning up old state. This
>>should happen just fine in background.
> 
> Consider the 2 cases: 
> 1) NOT using TCP-MD5 for BGP.
> 2) Using TCP-MD5 for BGP.
> 
> If I were "not" using MD5 and YY reboots, comes up and
> chooses a different port (65002), XX would not know
> that YY has rebooted and it would continue to send a
> segment on the old connection i.e. on port 65001 to
> YY. YY would respond with an RST and XX would happily
> accept it and close the old connection. This is
> because segments in either direction dont need to have
> the MD5 digest and so the RST from YY is valid for XX
> and it will accept it. So, this is the case when I am
> not using MD5 and things work fine even when YY
> reboots.
> 
> The problem case is when I "am" using MD5 and YY
> reboots and comes up again. XX doesnt know about it
> and XX sends segments "with" the MD5 digest and YY
> responds with RSTs "without" the MD5 digest. Thats
> when the old connection will stick around until XX has
> tried 12 retransmissions since its going to ignore the
> RSTs without the MD5 digest from YY. The RFC for
> TCP-MD5 says this is a problem but does not recommend
> any solution. 

Yes, but there are two subcases:

2a) YY wants to use the original port, i.e., there is a conflict with
the ports used by the old connection state that XX retains

2b) YY wants to use a new port

In 2a, YY will be listening on the original port, and will repond with
RSTs with the MD5 digest, and the state will be cleaned up and ready to
use quickly.

In 2b, the state will take a few RTTs to clean up - but in the meantime,
new connections will work just fine. I.e., overall, all we appear to be
worried about is the old connection state on XX.

While I appreciate that BGP takes cues on connectivity from TCP
connection state, that is an error of BGP IMO - TCP is well-defined not
to clean up old state until such state interferes with new connections.

Joe

> 
> Maybe its ok to let the old connection stick around
> until XX is done retransmitting and gives up.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxZ42E5f5cImnZrsRAvp/AJ9guSqow+Tvx0iiAv9G5HjEFD+IRQCg0Y09
PEv/Brdu2MthvlIJ9zlibDc=
=s+l6
-----END PGP SIGNATURE-----


More information about the end2end-interest mailing list