[e2e] Receiving RST on a MD5 TCP connection.

[Tapan Karwa]

I would like to point out this simple scenario:

Consider XX and YY as BGP peers. They have a TCP
connection between them, lets say, with port numbers
179 on XX and 65001 on YY (lets say YY initiated the
connection).

Lets say YY goes down. XX doesnt know about it and
keeps sending keepalives to YY on port 65001. 

While all this is happening, YY comes up and it will
try to make a new connection with XX (port 179) again.
Lets say YY chooses 65002 as its port this time. 

Even if MD5 was being used for both connections, the
new connection might work fine, depending on how you
implement it. But, for each retransmission that XX
sends to port 65001, YY will keep sending RSTs back to
XX. And these RSTs wont have MD5 since YY does not
have anyone listening on port 65001.

Standard TCP on XX will retry 12 times before it
finally gives up.

Even if we assume that the whole world is using MD5
(thereby not worrying about the security issue as
much), XX will not honor the RSTs from YY since they
dont have the MD5 digest. 

And this behaviour will be independent of keys i.e.
will happen whether you use new keys or old keys. The
old connection will stay for atleast 8 minutes until
XX is done retransmitting and finally gives up on the
old connection.

--- Joe Touch <touch at ISI.EDU> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> RJ Atkinson wrote:
> > 
> > On Jun 30, 2005, at 15:03, Joe Touch wrote:
> > 
> >> It does suggest, however, that if new keys are
> used on both sides,  then
> >> both sides ought to flush their connections
> entirely (i.e., drop all
> >> TCBs using old keys). This affects TCP/MD5
> keying, but that's not
> >> automatically managed, though.
> > 
> > I would normally expect that if a reboot triggered
> rekeying,
> > then some form of automated key management would
> be in place.
> 
> Agreed.
> 
> > In practice, current deployments change keys
> roughly never.
> 
> As you note below, in practice deployments don't
> even use keys ;-)
> 
> > Along that line, it should be quite practical for
> someone to
> > write a "TCP MD5 Domain of Interpretation"
> specification to
> > permit the existing ISAKMP/IKE protocol to be used
> for this
> > purpose.
> 
> Agreed, however it's even easier to configure IKE to
> setup a transport
> association between BGP peers (which, as below, I
> presume you are
> referring to).
> 
> Joe
> 
> > In practice, most current implementations of "TCP
> MD5 for BGP" only
> > support one key per remote-peer at a time, which
> is a challange
> > if one wants to have smooth key rollover (whether
> manual or
> > via some automated key management).  This is just
> an
> > implementation issue; nothing prevents supporting
> more than one
> > key at a time.
> > 
> > Actually, the bit I find most surprising is that
> the majority of
> > deployed BGP sessions (including the majority of
> e-BGP sessions)
> > run without even enabling TCP MD5.
> > 
> > Given that folks generally don't deploy TCP MD5 to
> protect against
> > basic attacks (e.g. TCP RST attacks or TCP session
> stealing),
> > I don't see why one would think that some form of
> authentication
> > enhancement within the BGP protocol itself would
> have rapid or
> > widespread deployment.[1]
> > 
> > Ran
> > rja at extremenetworks.com
> > 
> > [1] My non-scientific sample of network operators
> can't find anyone
> > who thinks Kent's S-BGP is deployable.  Most think
> that SO-BGP is
> > deployable, but would be challenging to deploy,
> and are hoping for
> > something more deployable than either one of those
> two.
> > 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFCxXo1E5f5cImnZrsRAsX8AKDiSEjhX0AyXgyDALhcA+XXCb0IoACcC8jn
> 8HzwfrPHRKkpk/wJQwn8Gz8=
> =TyIA
> -----END PGP SIGNATURE-----
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com