Re: [tcpm] [OPSEC] draft-gont-tcp-security

Lars Eggert <lars.eggert@nokia.com> Tue, 14 April 2009 07:54 UTC

Return-Path: <lars.eggert@nokia.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 062103A6D6B; Tue, 14 Apr 2009 00:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 tG5KGQn5-JwY; Tue, 14 Apr 2009 00:54:56 -0700 (PDT)
Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4DFC13A68AC; Tue, 14 Apr 2009 00:54:55 -0700 (PDT)
Received: from [10.180.41.39] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n3E7tlVr021648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Apr 2009 10:55:47 +0300 (EEST) (envelope-from lars.eggert@nokia.com)
Message-Id: <C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <49E3BED9.1030701@isi.edu>
Content-Type: multipart/signed; boundary="Apple-Mail-28--604463031"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 14 Apr 2009 10:55:41 +0300
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g ov><49E36AB9.40507@isi.edu> <49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu> <49E39119.1060902@gont.com.ar> <B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM> <49E3A88F.9060301@gont.com.ar> <49E3ABC0.1050601@isi.edu> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu>
X-Mailer: Apple Mail (2.930.3)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Tue, 14 Apr 2009 10:55:49 +0300 (EEST)
Cc: "'tcpm@ietf.org'" <tcpm@ietf.org>, "'ietf@ietf.org'" <ietf@ietf.org>, "Smith, Donald" <Donald.Smith@qwest.com>, 'Joe Abley' <jabley@ca.afilias.info>, "'opsec@ietf.org'" <opsec@ietf.org>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] [OPSEC] draft-gont-tcp-security
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, 14 Apr 2009 07:54:57 -0000

Hi,

<all hats off>

On 2009-4-14, at 1:38, Joe Touch wrote:
>>> Advice in making a hardened version of TCP would be useful to the
>>> implementation community.
>>
>> To a large extent this is what draft-gont-tcp-security is about.
>
> Implementation advice is outside the scope of the IETF. It's not even
> operational, IMO.

I do believe there is value in having a document that would inform a  
stack vendor of various potential attack vectors against a TCP stack  
and what techniques exist to harden their stacks.

I agree with Joe that some of the hardening techniques that vendors  
are implementing come with consequences (make TCP more brittle). To  
me, this is a *reason* this document should be published via the IETF  
(i.e., TCPM) - we are probably in the best position to correctly  
evaluate and classify the impact of various hardening techniques.  
Stack vendors have been putting these mechanisms in to their stacks  
without clear specifications and discussions of the potential upsides  
and downsides that would let them make an educated decision. It seems  
clear to me that the vendor community is looking for guidance here,  
and I do believe the IETF should give it.

Yes, there is a fine line here, where some of the hardening techniques  
introduce some new assumptions on what the segment flow of a valid  
connection looks like, etc. It will be important to accurately  
describe the downsides of some of these techniques, especially where  
they could result in valid connections being dropped.

Lars