[e2e] Receiving RST on a MD5 TCP connection.

[Joe Touch]

RJ Atkinson wrote:
> 
> On Jun 27, 2005, at 15:52, Tapan Karwa wrote:
> 
>> I am wondering if there is any consensus on how we
>> should deal with the problem mentioned in Section 4.1
>> of RFC 2385.
> 
> I don't think this is a significant issue in real world deployments.
> TCP MD5 is designed to prevent acceptance of unauthenticated TCP RST
> message to reduce risk of (D)DOS attacks on the TCP sessions of BGP.
> An adversary could send an unauthenticated RST anytime.  If that took
> out BGP, such would be a much larger operational problem.
> 
> In practice, if the first (i.e. unauthenticated) RST is ignored, the
> router will send another RST a bit later on (e.g. after it is rebooted
> sufficiently to know which MD5 key to use) and that one WILL be
> authenticated and will be accepted rather than ignored.
> 
> So it should sort itself out without any spec changes, just taking
> a time period closer to the reboot-time of the router that is
> rebooting rather than some small fraction of that time.  No real
> harm done with the current situation at all.
> 
> Ran
> rja at extremenetworks.com

Agreed.

Another point along these lines - if you had a secure connection with
another host, then the host reboots and 'forgets' the security
altogether (i.e., doesn't reestablish keys), it shouldn't be able to
reset the old connection anyway.

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.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050630/3a1cc181/signature.bin