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

Fernando Gont <fernando@gont.com.ar> Tue, 14 April 2009 05:43 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 761FD3A6D99; Mon, 13 Apr 2009 22:43:31 -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 sCSbgW+hjeUV; Mon, 13 Apr 2009 22:43:30 -0700 (PDT)
Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by core3.amsl.com (Postfix) with ESMTP id 994FF3A6D97; Mon, 13 Apr 2009 22:43:29 -0700 (PDT)
Received: by ag-out-0708.google.com with SMTP id 23so1116653agd.12 for <multiple recipients>; Mon, 13 Apr 2009 22:44:40 -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=4r6fJ2HYuYJwLMrCqOfC7vCje8jq+inqAyUc/bkP2sY=; b=DQFayMU3ciGL29pGCYmGerPRVI7Ggym28+WJ9vnLB7x9Kfs4g0ZrMC9B8v77N8jb85 MiDPuq6nfsUwCmUuXTO/0QUiXYOQYu32H3GWfqd5WdhSBsPXVm+MCEVkRSY0n9Pcrx4h 8to77Jfnc2DY+CC+MsV2zCdrj5BGO4Q6oIa6E=
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=cpvBW2J6mIRx+LL/cUc/rw+vmAkDJ+ZwWd08pBIQruqkGb2FA+EVEz6JIbQLwjLhWX eA1XRlaOsNdgevgRKW5dAMDUNFdc42XYhenDDUu79ZQXL9om8rsUjI/nTFgE23iT7Tuj 81dcmdy02OsXoZyyR6IY6BLyx5YpYbDH+JHyA=
Received: by 10.90.117.17 with SMTP id p17mr491548agc.30.1239687880210; Mon, 13 Apr 2009 22:44:40 -0700 (PDT)
Received: from ?192.168.1.3? ([190.50.221.185]) by mx.google.com with ESMTPS id 34sm1197628agc.39.2009.04.13.22.44.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 22:44:39 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <49E422C0.5050908@gont.com.ar>
Date: Tue, 14 Apr 2009 02:44:32 -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> <49E3B9BF.1060901@gont.com.ar> <49E3BED9.1030701@isi.edu>
In-Reply-To: <49E3BED9.1030701@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: Tue, 14 Apr 2009 05:43: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.
> 
> Implementation advice is outside the scope of the IETF. It's not even
> operational, IMO.

RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION"
RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4)

and,

RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you
are on of the co-authors :-) )

That said, to a large extent the document is provides advise about
enforcing stricter validation checks, timeouts where appropriate, and
about a number of policies that may improve TCP's resiliency/security
(e.g., how to select ISN's, etc.)



>>> 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?
> 
> That'd be harsh. I agree with some of the implementation advice as
> implementation advice. I agree that, in risk-prone environments (where
> packets can be tapped, e.g.), some of the recommendations are appropriate.
> 
> I'm disagreeing primarily with the general tone and balance of the document.

I believe at this point in time we're deciding whether it makes sense to
work on this document, and where it would make sense to do it.
draft-gont-tcp-security-00 is just a starting point. Of course, it
represents my pov, and to some extent the pov of the reviewers. But the
idea of bringing it to the IETF is that future versions of the document
represent wg consensus.

If you have specific suggestions on how to improve the document, I'll be
more than happy to hear about them.

However, I believe at this point we are not yet discussing on any
specific issue discussed in the draft, but are trying to agree on how to
move forward. (Feedback on the technical details in the document is
nevertheless welcome, though)



>> 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.
> 
> I disagree. Even if it weren't IPR encumbered, I would disagree with
> widescale deployment of a modification to TCP that answers a RST with
> one *or more* ACKs. As I said numerous times w.r.t. that document, the
> modifications it suggests are generally not needed, unnecessarily
> complicate packet processing, and since they don't protect from
> in-window injection attacks, I find them useless in the general case.

TCP is already very complicated. And the implementation of the
countermeasures in tcpsecure usually require not much more than
(literally) a couple of additional lines, or a slight modification in
some conditional statement.



>>>> 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"?
> 
> Limit cycles/resources available for new connections, e.g., for SYN
> attacks -- as is already done for things like IKE.

At the point in which you actually try to put this into code, a number
of questions arise that need to be answered. Why should vendors rehash
the same analysis over an over again (with the potential of doing it
wrong, which would lead to buggy implementations), when we could put out
a document with consensus on the preferable way to do those things.



>> 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.
> 
> I've been saying I feel that mods are necessary, and you keep
> complaining. 

That's not how I read your comments. If your point of view is "it would
be interesting to work on this. however, i believe the document should
be modified in this way, because of this reason" that's one thing.

If your pov is "we don't need this. go somewhere else", that's something
entirely different.


> If you're here for a rubber stamp, you came to the wrong WG ;-)

Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and
when it comes to advice on this issues, I believe it's even more
credible. Ask the question in bugtraq or full-disclosure, and that's
most likely the conclusion you'll get to.

I'm involved in the IETF, and honestly believe that the IETF should work
on this. I do know that the end result of that process would be such
that I probably won't be as happy with the resulting RFC than with the
UK CPNI document. But at least I would have helped to change the current
state of affairs a little bit.



> The sky has been falling in this WG for several years. Although this
> document is the first aggregation of such recommendations, as you know
> it's composed of many documents you yourself have been discussing for
> that period in this WG..

I'd probably argue that the case with tcpm is that at (many) times
protocol specifications have been taken as if they were casted in stone.
And unless one is part of some small circle of people that is supposed
to have been allowed by God to modify such specs, it will be very hard
there's no effort that takes less than quite a few years.

Very loud people take the time to maintain endless discussions, and most
mere mortals that need to get work done end up completely avoiding tcpm
altogether, because it requires a huge spend of time.

Virtually every developer that I know of won't care about what the end
result in tcpm is. At most, they will post a question to hear comments.
But that's it. To a large extent people cannot believe the amount of
energy we spend for such a null progress.

Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks).
The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD,
Linux, extreme networks, and Cisco (this last one "unofficially"). To
them, the draft looks okay. Many other people have also agreed with
that. But I cannot get those folks involved in our endless discussions.
The ROI for them is NULL.

Do they care about the outcome? Not really. They agree with the
proposal, it is in the code already, and has been running for years.
They just let us waste our time.

I agree that there are benefits to be gained from having a more
conservative philosophy, to put it some way. I believe that it is a good
thing to challenge proposals, to aim at improving their quality, etc.
This has helped improve many documents, including those I have authored.
But I believe at some point it starts looking as "everything that
neither me or my inner circle proposes will be banned".


>> 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.
> 
> I'm asking the question I apparently keep needing to ask:
> 
> 	Why do you think that just because something is implemented
> 	we should recommend it?

That's not how the tcp-security document was produced. For instance,
many of the recommendations had never been implemented. And the document
argues *against* some common implementation strategies.



> 	Why do you think that a message that isn't expected indicates
> 	an attack to be defended against, vs. the actions of a
> 	benign endpoint?

We simply raise the bar about what we react to. If there are packets for
which there's no legitimate use, we don't react to them (if this doesn't
cause harm).


> I have a high bar for the need for modifications to TCP, and the need to
> propagate local solutions to every endpoint in the Internet. 

And do you believe that such propagation depends on our outcome? --
Thanks God, it doesn't. Try to find any implementation that is
fully-compliant with the RFCs, and let me know if you find any.

The lack of advice on all these issues has put vendors in a position in
which they have to figure out that advice by themselves. Sometimes they
got to the right answers, sometimes not.

Have a look at the vulnerability advisories referenced in the I-D: the
same errors are committed over and over again.

draft-gont-tcp-security is an effort to help the vendor/developer
community in that area.

P.S.: My apologizes for the possible politically-incorrect comments. But
this is the best trade-off I have been able to get between being
politically-correct and being honest.

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