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

One minor comment - Please see inline for [Chaks]

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Smith, Donald
> Sent: Tuesday, August 04, 2009 9:27 AM
> To: 'Iljitsch van Beijnum'; 'Ron Bonica'
> Cc: 'tcpm@ietf.org'; 'iesg@ietf.org IESG'
> Subject: 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.

[Chaks] If the listener is not around, it is very likely that the
listener has withdrawn from TCP the knowledge about the 
various keys associcated with the neighbors. OR, TCP itself might have
purged that info as such info is usually "attached" to the listen
socket. So, it may not be possible for TCP to generate an authenticated
reset in the absence of a listener.

Chaks

> 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
> > 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 