[e2e] Receiving RST on a MD5 TCP connection.

[Joe Touch]

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



Tapan Karwa wrote:
> 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.

TCP doesn't focus on cleaning up old state. This should happen just fine
in background.

This seems like a problem only if XX and YY try to reuse their
respective port pair, but in that case YY owuld have someone listening
on 65001 and would issue the RST with the right key.

> 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:
> 
> 
> 
> 
> 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.
> 

> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCxYkBE5f5cImnZrsRAknHAJ0aeMDFZpgFy4YVwrqVYHAnTiW9tgCg3S+H
0Hj4q4ZiXMZEMT9UU5tpc20=
=aTtv
-----END PGP SIGNATURE-----