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

"Chaks Chigurupati (chaks)" <chaks@cisco.com> Tue, 04 August 2009 17:28 UTC

Return-Path: <chaks@cisco.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073703A6FB7; Tue, 4 Aug 2009 10:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.605
X-Spam-Level:
X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xldHDJW759yi; Tue, 4 Aug 2009 10:28:01 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CBEA93A6C7C; Tue, 4 Aug 2009 10:28:01 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAH8MeEqrR7PE/2dsb2JhbAC8eYgpj3gFhBiBTw
X-IronPort-AV: E=Sophos;i="4.43,322,1246838400"; d="scan'208";a="360240453"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 17:28:04 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n74HS4Os016079; Tue, 4 Aug 2009 10:28:04 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n74HS4WK013945; Tue, 4 Aug 2009 17:28:04 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 10:28:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 04 Aug 2009 10:28:03 -0700
Message-ID: <3C50EF6BFB256E448286057DABC00CBE0834DB8A@xmb-sjc-214.amer.cisco.com>
In-Reply-To: <B01905DA0C7CDC478F42870679DF0F100599C37D28@qtdenexmbm24.AD.QINTRA.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication
Thread-Index: AcoVHCcZ8JwlPIP3Qw6VTNwcE8WB5AAAMtNQAAFy8wAAAM/DkAAAkyog
References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><FB33B8FD-308B-4867-902E-131382969C35@muada.com><4A777220.3070507@juniper.net><75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> <B01905DA0C7CDC478F42870679DF0F100599C37D03@qtdenexmbm24.AD.QINTRA.COM> <3C50EF6BFB256E448286057DABC00CBE0834DB40@xmb-sjc-214.amer.cisco.com> <B01905DA0C7CDC478F42870679DF0F100599C37D28@qtdenexmbm24.AD.QINTRA.COM>
From: "Chaks Chigurupati (chaks)" <chaks@cisco.com>
To: "Smith, Donald" <Donald.Smith@qwest.com>, Iljitsch van Beijnum <iljitsch@muada.com>, Ron Bonica <rbonica@juniper.net>
X-OriginalArrivalTime: 04 Aug 2009 17:28:04.0184 (UTC) FILETIME=[EC5C7D80:01CA1528]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5954; t=1249406884; x=1250270884; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=chaks@cisco.com; z=From:=20=22Chaks=20Chigurupati=20(chaks)=22=20<chaks@cisco .com> |Subject:=20RE=3A=20[tcpm]=20status=20of=20TCP-MD5=20after= 20TCP-AO=20publication |Sender:=20; bh=qs7FKgR7WmjEQbar+hUTGXj0SMuGpJH9dEpySnup4oI=; b=fOc8pY33A/IQ2O5q3gL3nIO0eDK5PFlkNQNJ/ahe5CGOV8xF+BwpDHMrbG PojoL1nV3tfcTFNUxaee1ZLByG9miCK53oqF3DV+k6J6MEv1qhABSMkk4eWy B1haMsQGjV;
Authentication-Results: sj-dkim-4; header.From=chaks@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: tcpm@ietf.org, iesg@ietf.org
Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2009 17:28:03 -0000

 

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

[Chaks2] My comment was based on the implementations that I know of.
Ideally, you don't want TCP code to be aware of BGP or LDP configuration
whatsoever. You would expect the BGP and LDP processes to make these
neighbor specific passwords available to TCP via a setsockopt() on the
listen socket. If the listen socket goes away, so do these passwords as
far as TCP is concerned.

Chaks

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