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

Nicolas Williams <Nicolas.Williams@sun.com> Sat, 15 August 2009 01:01 UTC

Return-Path: <Nicolas.Williams@sun.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 217C73A69E2; Fri, 14 Aug 2009 18:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.879
X-Spam-Level:
X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 tXatH5k+MAaL; Fri, 14 Aug 2009 18:00:59 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id CE2203A67C1; Fri, 14 Aug 2009 18:00:54 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7F10nSR003006; Sat, 15 Aug 2009 01:00:49 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7F10mIH008690; Fri, 14 Aug 2009 19:00:48 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7F0gZxc002047; Fri, 14 Aug 2009 19:42:35 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7F0gZKR002046; Fri, 14 Aug 2009 19:42:35 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 14 Aug 2009 19:42:35 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Message-ID: <20090815004234.GN1043@Sun.COM>
References: <Pine.WNT.4.64.0906080948290.6048@SANDYM-LT.columbia.ads.sparta.com> <20090814221222.GH1043@Sun.COM> <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0C53DCFB700D144284A584F54711EC5807D55441@xmb-sjc-21c.amer.cisco.com>
User-Agent: Mutt/1.5.7i
Cc: secdir@ietf.org, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>, iesg@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 01:01:00 -0000

On Fri, Aug 14, 2009 at 05:33:13PM -0700, Anantha Ramaiah (ananth) wrote:
> 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

If the issue is IPR then the WG/IETF could choose to make this RFC not a
Standards-Track RFC, but an FYI, and optionally drop the normative
RFC2119 language (or make those MUSTs; doesn't matter much to me, if the
RFC is to be Informational).

It'd be silly to make this a Standards-Track RFC with not a single
REQUIRED to implement feature in it -- all implementations of anything,
anywhere, could then claim to be compliant.  If there was at least one
REQUIRED to implement then you could choose to make other encumbered
features RECOMMENDED, or OPTIONAL.  But no RTI feature at all makes no
sense to me.

> 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

So what?  Implementors who don't care for this feature wouldn't be bound
to implement it just because this RFC says it's a MUST.  Implementors
who don't implement it would just not be compliant with this RFC, but
nothing says they have to be.

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

I'd like to hear from them.

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

OK.  Maybe this should be stated in the I-D.

Nico
--