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

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

> -----Original Message-----
> From: Chaks Chigurupati (chaks) [mailto:chaks@cisco.com] 
> Sent: Tuesday, August 04, 2009 10:49 AM
> To: Smith, Donald; Iljitsch van Beijnum; Ron Bonica
> Cc: tcpm@ietf.org; iesg@ietf.org
> Subject: 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.

In ever implementation I have seen there is a shared secret in the BGP configuration.
It might mean "searching" the bgp configuration to find the neighbor's route ID and grab the shared secret associated with that router ID but that plus the incoming packet information (src_port, dst_port, sequence_numbers...) is enough to provide an authenticated reset. 

One issue here is that the reset would probably not be generated by the asic on the line card as it is in many cases today. So this would probably lead to a hit on to the cpu or npu (slow path). Some routers ignore authenticated resets which per the current version of the rfc can be viewed as rfc compliant:(

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