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

Fernando Gont <fernando@gont.com.ar> Tue, 30 June 2009 20:02 UTC

Return-Path: <fernando@gont.com.ar>
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 737C53A6EF5 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Level:
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5zXyfK3rD3pM for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:02:18 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 97BCF3A6ED3 for <tcpm@ietf.org>; Tue, 30 Jun 2009 13:02:15 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 90C9D6B660B; Tue, 30 Jun 2009 16:49:48 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UJnWFJ031325; Tue, 30 Jun 2009 16:49:33 -0300
Message-ID: <4A4A6C53.9040008@gont.com.ar>
Date: Tue, 30 Jun 2009 16:49:39 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
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> <4A4A5A23.1010009@isi.edu>
In-Reply-To: <4A4A5A23.1010009@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 16:49:47 -0300 (ART)
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 20:02:19 -0000

Joe Touch wrote:

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

TCP was not designed with congestion control in mind... so what? Will
you knock down RFC2581, too?

Whether it was designed with those issues in mind or not, doesn't
matter. TCP operates in hostile environments and therefore, to the
extent that it's possible, it's is desirable that it is as resilient as
possible.



> IPsec, and TCP's MD5 and AO options are intended to address some of these. 

>From your perspective, why would you work on TCP-AO if TCP is not meant
to provide security??



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

You use a helmet when you ride a motorcycle, right? Does that mean that
a motorcycle becomes secure? No it doesn't. But it does mean that you
probably will not get very injured if you fall from your motorcycle at
20 km/h.

C'mon Joe...




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

I had meant to remove most of that ICMP stuff. This is a pending change,
and I thought I had already removed most of that stuff (and replace it
with a small discussion, and a pointer to the ICMP attacks I-D).



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

As I said, this is no problem, and I thought I had already applied this
change.

That said, I don't believe this is a show stopper.... (issues solved, as
far as I can tell).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1