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 > -- >
- [secdir] draft-ietf-tcpm-tcpsecure Sandra Murphy
- Re: [secdir] draft-ietf-tcpm-tcpsecure Lars Eggert
- Re: [secdir] draft-ietf-tcpm-tcpsecure Lars Eggert
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Nicolas Williams
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Nicolas Williams
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Lars Eggert
- Re: [secdir] draft-ietf-tcpm-tcpsecure Nicolas Williams
- Re: [secdir] draft-ietf-tcpm-tcpsecure Paul Hoffman
- Re: [secdir] draft-ietf-tcpm-tcpsecure Lars Eggert
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Sandra Murphy
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)
- Re: [secdir] draft-ietf-tcpm-tcpsecure Anantha Ramaiah (ananth)