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

Fernando Gont <fernando@gont.com.ar> Mon, 13 April 2009 22:15 UTC

Return-Path: <fernando.gont.netbook.win@gmail.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 B94743A67B1; Mon, 13 Apr 2009 15:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level:
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 O-FOR4sVQWYl; Mon, 13 Apr 2009 15:15:30 -0700 (PDT)
Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 4CF063A6C22; Mon, 13 Apr 2009 15:15:30 -0700 (PDT)
Received: by gxk7 with SMTP id 7so448239gxk.13 for <multiple recipients>; Mon, 13 Apr 2009 15:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=6HLm2gJLCSrNWV43539qUV1LrzTRHqLp1J+4IafeMII=; b=gBjuQtq+EvGyEF1UGOsYGd9a9sE1t79yGECoWld7ACruG7XYjqUxNjZNsXCgx/La6V 7CcRq/9dYAYT6viv5oWmWqpKdTqla15Gn2/1Lek4QwX8wCptrryRLHBMCZN4EQ7pXGhJ qIK67qV1WaihVEUMP+yuYGdkweORg6J8QGA2w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=UYFkvxkRhrFAu24OuhTopLMiCJSxnih+3tAOoOt9CEvVcg9yq4GDIJ3sMQukWtLYgA Oz8wrUlAuZx9DeDa7LIoudXSaq/pJTHvuT4ogKYfcdy712PvJfXiDga3AXDS9TeaIjji D7R0Ewho9yVgjMiuhHfh/sp2HmzZyR4K7biWg=
Received: by 10.100.152.12 with SMTP id z12mr5125294and.141.1239660998200; Mon, 13 Apr 2009 15:16:38 -0700 (PDT)
Received: from ?192.168.0.151? (235-131-17-190.fibertel.com.ar [190.17.131.235]) by mx.google.com with ESMTPS id d24sm249633and.37.2009.04.13.15.16.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 15:16:37 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <49E3B9BF.1060901@gont.com.ar>
Date: Mon, 13 Apr 2009 19:16:31 -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: <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>
In-Reply-To: <49E3ABC0.1050601@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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>
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: Mon, 13 Apr 2009 22:15:31 -0000

Joe Touch wrote:

>> The consensus seems to be that the current state of affairs is something
>> like: "a mess". Even if you do care to produce a resilient
>> implementation, that task is going to be much harder than necessary. You
>> don't know the amount of cycles we spent in producing
>> draft-gont-tcp-security.... let alone the time it would take to move the
>> advice in an actual implementation.
> 
> 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.



> However, if you're saying that TCP specs in general are a mess, yes they
> are. That's why we created a roadmap document, and why it needs to be
> maintained. If you're suggesting we need a clean single documentation of
> what TCP is, I might even agree. However:
> 
> 	1) TCPM is not the place that would generate it
> 	(IMO, that'd be TSVWG)
> 
> 	2) this document is not a step in that direction

The tcp roadmap is a roadmap to the documents that the IETF has
published. There's lots of stuff that has not been published by the IETF
and that therefore is not discussed in the tcp roadmap.

This is another area in which this document tries to help.



> You've produced a summary of issues you feel would harden TCP. I feel
> that some of them make TCP more brittle, and some make TCP unnecessarily
> complex, and in both cases the mods are not needed in the general
> Internet.

Is there nothing in the document with which you agree?



> TCPsecure is a good example; it has caveats in its ID that
> indicate where it is useful and where it is not -- it is NOT a general
> solution for the entire Internet (the WG basically agreed to that with
> the wording for its use cases).

c'mon Joe.. IMO, tcpsecure needed to include those statements about
usefulness in large part because it was IPR-encumbered, and in part as a
political workaround that would avoid further waste of time in endless
discussions.



>> In many cases the lack of a straight answer may have to do with us being
>> unable to get to consensus and get something published in a timely
>> fashion. e.g., the last round on ICMP attacks against TCP was circa
>> 2004. At that point an I-D was published on the subject (now
>> draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when
>> everybody did something about it five years ago.
> 
> Uh, well, we're deciding whether we agree with what's been deployed.
> Deploying some of these changes hasn't always been a good idea; if it
> were, we'd be agreeing to it.

Some people prefer to get work done instead of committing/wasting lots
of cycles in endless discussions.



>> It becomes harder to get s staright answer when it's impossible for a
>> vendor to point to a counter-measure that is supposed to be the result
>> of a thorough review process, in a *timely* fashion.
> 
> Can you be as specific here as you want us to be? What exactly does a
> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing
> known countermeasures?

What's "the existing known counter-measures"?



>> I'm aware there's an effort in the vendor community to improve the
>> resiliency of TCP basedon the document published by UK CPNI. Yet we're
>> still debating whether to ignore it or not.... maybe so that we can
>> publish an RFC in the future tagging those implementations as
>> non-compliant... or maybe to allow tcp vulnerabilities to be
>> "rediscovered" every few years.
> 
> If the vendors are following this doc already, then we REALLY need to
> ensure it's updated with advice appropriate to the context in which it
> is deployed. 

FWIW, vendors are following the UK CPNI document. The idea of bringing
those results to the IETF is so that these results/advice can be further
discussed, more eyes look into them, and the doc is modified if it is
felt necessary.


> Running around saying the sky is falling for everyone isn't
> going to help.

Who did that? We worked on this document very silently for a couple of
years. If we had wanted that "sky is falling" approach, we would have
gone to the press before showing anything (like quite a few folks have
been doing in the recent past). Or we could have announced part of this
stuff as "vulnerabilities" to the press..

That wasn't the case.

I tried to get many people to review the document, and have the document
be as objective as possible. At least for the ip-security counterpart, I
recall asking you to have a look at it before publication, even when I
knew that you'd most likely disagree with large parts of the document.

This project is already done.... but nevertheless I'm still spending
some cycles to bring this to the IETF, because I truly believe the IETF
should work on it. Neither me nor UK CPNI have IPRs or anything on the
material covered in our document... so there's no hidden motivation in
all this.

Honestly, I'm not sure why you always have to knock down others' efforts
on a "by default" basis, and prejudge the motivation behind those efforts.

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