[e2e] Receiving RST on a MD5 TCP connection.

[Mitesh Dalal]

On Thu, 30 Jun 2005, Joe Touch wrote:

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

and why would that be Joe ? By saying so you have no love for network
reliability. Do you know networks can go down if MD5 enabled LDP
connection cannot recover from this problem and rely on timeouts
to recover ? Do you know the same thing can happen to BGP ?
Security shouldnt come at the cost of reliablity!

Mitesh