[e2e] Receiving RST on a MD5 TCP connection.

[Joe Touch]

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