Re: [tcpm] poll for adopting draft-gont-tcp-security

Joe Touch <touch@ISI.EDU> Tue, 30 June 2009 18:39 UTC

Return-Path: <touch@ISI.EDU>
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 9BE9928C210 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 ENUch1So47xg for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:39:45 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B68EF3A6883 for <tcpm@ietf.org>; Tue, 30 Jun 2009 11:39:45 -0700 (PDT)
Received: from [75.217.54.49] (49.sub-75-217-54.myvzw.com [75.217.54.49]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5UIW3MN029458; Tue, 30 Jun 2009 11:32:05 -0700 (PDT)
Message-ID: <4A4A5A23.1010009@isi.edu>
Date: Tue, 30 Jun 2009 11:32:03 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar>
In-Reply-To: <4A4A56F5.30806@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting 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, 30 Jun 2009 18:39:46 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>> I don't understand why TCP must be able to be implemented in a secure
>> fashion. 
> 
> Because we don't want our systems to be trivially hacked.

We agree on that.

However, there are different issues here:

	1- protecting a particular TCP connection from attack
	2- protecting an endsystem from resource overload
	3- protecting the data a user transfers

TCP was never intended for any of these. IPsec, and TCP's MD5 and AO
options are intended to address some of these. If you're concerned with
hackers, you protect all three above - which means assuming IPsec and/or
MD5/AO, *then* talking about other issues.

Addressing vulnerabilities in unprotected TCP is like caulking the
windows of a car. It won't make it float.

>> It would be more useful, IMO, to at least admit that and change the
>> above to acknowledge that, e.g., (changing the wording and the level
>> down to SHOULD):
>>
>> - TCP SHOULD be able to be implemented in a way that mitigates, to the
>> extent possible, the impact of exploitable conditions leading to:
> 
> Do we really need to nit-pick at every document and waste cycles in
> end-less discussions that get nowhere, instead of getting stuff done?
> 
> Why don't we work on the document itself? Is there anything you think
> could be improved? Post feedback, and let's improve the document.

I've repeatedly said why I don't want to proceed on this path. It puts
the WG in the position of repeating ourselves on issues we've already
decided. Specific example - ICMP in-window checking. We acknowledge
systems do this, but do NOT recommend it as a security check. I've said
why in at least 3 different IETF meetings, as have others. Yet this doc
recommends it. That exceeds advice of the WG.

If you want this doc to be the basis of work in this WG, why don't
**YOU** start by revising it to at least apply the existing WG positions
on previously discussed advice?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKWiMACgkQE5f5cImnZrti0ACgzg5DD3SU3xMMhmYC8EbBlq/E
ob4An2c6WSG+znQ37e8yUxr2C3aYlnHP
=M0OE
-----END PGP SIGNATURE-----