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

Joe Touch <touch@ISI.EDU> Tue, 09 June 2009 20:07 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 DE2293A6847; Tue, 9 Jun 2009 13:07:22 -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 HK3bRp46oSKg; Tue, 9 Jun 2009 13:07:22 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 980123A6841; Tue, 9 Jun 2009 13:07:10 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n59K6bob014863; Tue, 9 Jun 2009 13:06:38 -0700 (PDT)
Message-ID: <4A2EC0CD.3020505@isi.edu>
Date: Tue, 09 Jun 2009 13:06:37 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
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> <C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com> <49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net> <EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com> <49E5F36D.7020808@earthlink.net> <A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com> <49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar> <4A2E66C3.6040701@isi.edu> <4A2EB9B7.80907@gont.com.ar>
In-Reply-To: <4A2EB9B7.80907@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: Joel Jaeggli <joelja@bogus.com>, opsec@ietf.org, tcpm@ietf.org
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, 09 Jun 2009 20:07:23 -0000

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



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 	The diligent blacksmith knows that hardening a tool also
>>>> 	makes it more brittle...
>>> This is a nice quote, but... I'd like examples. e.g., start discussing
>>> about which specific hardening proposal makes TCP more brittle.
>> 1) any security mechanism that increases complexity - of actions, state,
>> or message exchanges - any of which increases the potential for
>> implementation error
> 
> Agreed.
> 
> 
> 
>> 2) any security mechanism that has false positives, i.e., that discards
>> messages deemed a security threat when they were sent for legitimate reasons
> 
> Why would this make e.g., TCP more brittle?

It makes a TCP that used to work not work anymore.

> In any case, the actual response to such packets may vary (e.g., in the
> case of ICMP hard errors, discard vs. process as soft errors). I believe
> that no matter what the recommended response is, it is important to
> discuss these issues, and try to get consensus on what's the right thing
> to do in each case.

Agreed. In a document that aimes to describe just what has been
implemented, there's no goal of gaining community consensus, though.
There is still utility, however, in providing the alternate viewpoint on
the potential impacts of implementations.

>> #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure
>> and ICMP filtering
> 
> ICMP filtering actually decreases complexity.

It requires more code to check that an ICMP is in-window than to not
check. Nearly everything requires more code, at least.

>> I.e., AFAICT, *everything* that makes TCP more secure also makes it
>> brittle, by definition (ditto for metal hardening, FWIW). The key issue
>> is "when/where is the benefit worth the cost".
> 
> As I said before, I'd like to have concrete examples from the tcp
> security i-d that are deemed to make TCP more brittle.

I did above in both cases.

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

iD8DBQFKLsDME5f5cImnZrsRAlGWAKCzYpIm7avI7zCezK/qr6+YOmLzogCg+hQe
miDFj33au36GsANaWpxiM4w=
=6lOt
-----END PGP SIGNATURE-----