[e2e] Receiving RST on a MD5 TCP connection.

[RJ Atkinson]

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.
In practice, current deployments change keys roughly never.

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.

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.