Re: [secdir] draft-ietf-tcpm-tcpsecure

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Sat, 15 August 2009 00:33 UTC

Return-Path: <ananth@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6373A6DCE; Fri, 14 Aug 2009 17:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 5PEslJUMLA6w; Fri, 14 Aug 2009 17:33:09 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 8E9A03A6B72; Fri, 14 Aug 2009 17:33:09 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAFefhUqrR7PE/2dsb2JhbAC5SogtkG4FhBk
X-IronPort-AV: E=Sophos;i="4.43,383,1246838400"; d="scan'208";a="90175637"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 15 Aug 2009 00:33:14 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n7F0XEe3007285; Fri, 14 Aug 2009 17:33:14 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n7F0XEo0022956; Sat, 15 Aug 2009 00:33:14 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 17:33:14 -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: Fri, 14 Aug 2009 17:33:13 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <20090814221222.GH1043@Sun.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [secdir] draft-ietf-tcpm-tcpsecure
Thread-Index: AcodLcrd34qLNifgR0CaN2LtEG9iWQAApZVA
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <20090814221222.GH1043@Sun.COM>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Nicolas Williams" <Nicolas.Williams@sun.com>, "Sandra Murphy" <sandy@sparta.com>
X-OriginalArrivalTime: 15 Aug 2009 00:33:14.0047 (UTC) FILETIME=[F98E2CF0:01CA1D3F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2658; t=1250296394; x=1251160394; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[secdir]=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=ORASoBLYeOUQxt2L2LqWxxBrv9+6yIsJUSkzxfdj6tc=; b=UC3UTTgtPZSFsBXlU6M+L2pw130mcYMbn+91pdNmrNBKTDm/T+jNx/PFvK oA0fSHIotK8dF1ISsQHV9NcvtHya2SZgubdX15rXB3q0PYDJd+cBzpUN+OE1 fpluMK/5G/;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Aug 2009 00:33:10 -0000

Hi Nico,

There was a big thread that went in TCPM some time back on this.
Initially the mitigations were tagged as "if you implement TCP secure
then all these are a MUST", such a statement gave a leeway for
implementers to chose whether or not they want to implement tcp-secure.
But some folks felt that since TCP secure has an IPR on it should
probably not have MUST in them at all, another argument was since TCP
secure is mostly useful only for long lived connections (like BGP), then
it may not be applicable to hosts and only applicable to routers. I
didn't (so as many others) didn't buy this argument, but since it was
not going anywhere Lars stepped up with the suggestion of applicability
statement to be added to this draft (I haven't seen any other TCP
related RFC which has an AS in it, FWIW) and the rest is history. I
seriously doubt whether the chairs/Lars/WG would like to fallback to
MUST/MUST/SHOULD.

In practice I have been given to understand that some vendors have
implemented these mitigations. Andre wanted to put these mitigations in
BSD as well, not sure about the current status. So, I am guessing if
folks are interested in adding robustness to their stacks in general and
TCP in particular, they would probably be interested in implementing
these mitigations.

Let me know if you need some text that needs to be added in the current
draft like for example add the reasoning why these mitigations are
chosen like this i.e, expand section 6 a little bit.

As far as the SYN corner case workaround we chose not to talk about the
fix for the same in the draft since the corner case exists in RFC 793
and nothing to do with the current SYN mitigation.

-Anantha

> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] 
> Sent: Friday, August 14, 2009 3:12 PM
> To: Sandra Murphy
> Cc: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal); 
> iesg@ietf.org; secdir@ietf.org
> Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
> 
> The mitigations in this I-D are made SHOULD, SHOULD, and MAY 
> (see section 6, page 15).  But that means that a TCP 
> implementation could claim conformance while not implementing 
> any of these mitigations.
> Therefore they should be, IMO, MUST, MUST and MAY (or SHOULD).
> 
> Also, ISTM that the corner case described in section 4.2 can 
> be avoided by noting the retransmitted SYN and then sending a 
> SYN+ACK to that, and if an acknowledgement comes back then 
> reset the old connection (and if there's no listener to 
> accept the new one, then reset it too).
> 
> Nico
> -- 
>