Re: [tcpm] status of TCP-MD5 after TCP-AO publication

I believe the rfc2385 should be modified.

http://www.ietf.org/rfc/rfc2385.txt
4.1
   A connectionless reset will be ignored by the receiver of the reset,
   since the originator of that reset does not know the key, and so
   cannot generate the proper signature for the segment.  This means,
   for example, that connection attempts by a TCP which is generating
   signatures to a port with no listener will time out instead of being
   refused.  Similarly, resets generated by a TCP in response to
   segments sent on a stale connection will also be ignored.
   Operationally this can be a problem since resets help BGP recover
   quickly from peer crashes.

An authenticationless reset MUST be ignored by the receiver of the reset.
The originator of that reset knows the key associated with their bgp neighbor and SHOULD use the key to generate 
an authenticated reset if that session has been terminated for some reason.
This means, for example, that connection attempts by a TCP which is generating
signatures to a port with no listener could be refused with a authenticated reset instead of being timed out.
Operationally this would be an improvement over the current standard since resets help BGP recover
quickly from peer crashes.

The current rfc compliant behavior doesn't make authenticated reset work, it makes ALL RESETS fail.
We could just as well have a flag that says ignore resets for bgp. It would have the same value as today's rfc compliant router implementations.

(coffee != sleep) & (!coffee == sleep)
Donald.Smith@qwest.com gcia   

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, August 04, 2009 9:56 AM
> To: Ron Bonica
> Cc: tcpm@ietf.org; iesg@ietf.org IESG
> Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication
> 
> On 4 aug 2009, at 1:26, Ron Bonica wrote:
> 
> > The HISTORIC nomenclature doesn't mean that there is no longer an
> > installed base. It just means that something more recent is 
> available.
> 
> I still think it's premature to change the status of RFC 2385 
> before a  
> replacement is widely available operationally.
> 
> And yes, that can take a decade, see 32-bit AS numbers.
> 
> Iljitsch
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 