Re: Security Assessment of the Transmission Control Protocol (TCP)
Fernando Gont <fernando@gont.com.ar> Sun, 22 February 2009 01:00 UTC
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2433A693C for <ietf@core3.amsl.com>; Sat, 21 Feb 2009 17:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 Q82jJDr8+5ij for <ietf@core3.amsl.com>; Sat, 21 Feb 2009 17:00:23 -0800 (PST)
Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 03AE63A6A8E for <ietf@ietf.org>; Sat, 21 Feb 2009 17:00:22 -0800 (PST)
Received: by gxk7 with SMTP id 7so1729686gxk.13 for <ietf@ietf.org>; Sat, 21 Feb 2009 17:00:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=ZErxKR8JqKkdtS4jwZu2M98Ax6VtX8O80eje7vzDxzU=; b=Gf1v+WSdizPzjvfgpB0JWkrv610+bIGL30vx9yFVnXMA4ug6irkshwBAv5KIp20BDI h9hz59SGy5oywW2WglCPk+bvA9woVetDUk5v8o+xflwaC44lXu6zYcTL13Zvn1TrmrDs th8Im0soReEzRjcTm+N6vkvSlBt37/usvFtEU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=FfP/yHIwyrRvwq/Riu9qEaXtLr1Gq5O4f+X1qC2gm1DseV1MFDxNXhXVi7GIuxqAAr QdgUj2X9pOZWlW4MoRV9zOZpo38cKsGZOzDx0W5kaLF0S57TCXR/yVFUqC03kC6OhMtQ YBDyNL43okdcQ1tywNJpplxQH15vICVPZ05yk=
MIME-Version: 1.0
Sender: fernando.gont.netbook.win@gmail.com
Received: by 10.220.75.19 with SMTP id w19mr400597vcj.110.1235264438109; Sat, 21 Feb 2009 17:00:38 -0800 (PST)
In-Reply-To: <972666D1-3024-4495-A3BC-475B7488DA81@nokia.com>
References: <4994A4EB.5030607@gmail.com> <0B030ADA-F621-4FDF-9CAF-23A27C16E26B@multicasttech.com> <972666D1-3024-4495-A3BC-475B7488DA81@nokia.com>
Date: Sat, 21 Feb 2009 22:00:38 -0300
X-Google-Sender-Auth: ed74595115ee21aa
Message-ID: <be6497400902211700x44c1830diacc6ce131b87c5b8@mail.gmail.com>
Subject: Re: Security Assessment of the Transmission Control Protocol (TCP)
From: Fernando Gont <fernando@gont.com.ar>
To: Lars Eggert <lars.eggert@nokia.com>
Content-Type: multipart/alternative; boundary="0016e647ecfc0986060463776a90"
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Feb 2009 01:01:05 -0000
2009/2/14 Lars Eggert lars.eggert@nokia.com > during the discussions around the TCP implementation deficiencies > publicized by the Outpost24 last fall, we discussed with CERT-FI and others > in that community that the IETF would offer to be the venue for publishing > such a document. > It has always been in our mind to bring the results of our project ("Security Assessment of the Transmission Control Protocol (TCP)" to the IETF. We have already done this for another document ("Security Assessment of the Internet Protocol") that was part of the same project. In July 2008, the UK CPNI released that document, and the next week after the release we publish an IETF I-D version of the same document. We have done the same thing with this new TCP document. I have already submitted an IETF I-D version of the document, in the hope that the IETF will work on this stuff. The document is entitled "Security Assessment of the Transmission Control Protocol (TCP)", and the filename is draft-gont-tcp-security-00.txt. > The goal would be to document techniques that stack vendors are employing > to harden their stacks. > This is sort of what we have done. However, not only have we documented techniques that stack vendors have implemented to harden their stack, but have also performed an assessment of the IETF specs themselves, and have also proposed mitigation techniques for known issues (on which there had never been advise on how to deal with them). We had a preliminar version of our paper sometime in 2006, but then it went through a throrough review process. That's why it ended up being published this month. > They asked us to wait until vendors had a chance to deploy patches to the > latest round of vulnerabilities, and we haven't heard back from them since > late last year. (Which reminds me to shoot them an email.) > I have been in the loop (for some time, at least), and have also been in very close contact with a number of vendors. For instance, an excerpt of our large TCP document (that discussed the specific issues that had been publicized by Outpost24) was made available to vendors in the hope of providing vendors with advice on how to deal with those issues. I don't really know how the "patching" work is going on... but at least a few months ago, I would say that many (most?) vendors were not really working in patches. And to some extent it might make sense, as some of the issues have more to do with having the applications controlling the amount of resources that they are using, than with TCP trying to limit the amount of resources per app at the TCP level. > I believe such a document would be fully in scope for TCPM, > I believe both tcpm and opsec could be possible candidates for this document. > but obviously the involvement of the stack vendors is critical to ensure > this is a document that has practical relevance. > To the extent that was possible, vendors *have* been involved in the review process of our TCP security document. However, at times it gets hard to get vendors involved in the IETF process. For the most part, they feel they are not heard, and that participating in the IETF has a low ROI (Return Of Investment). We have had some experience in this arena with the document "ICMP attacks against TCP" that we are still pursuing within tcpm. I was able to get involved from the following "vendors": * NetBSD * OpenBSD * FreeBSD * Linux * Cisco * Sun * HP * ExtremeNetworks (IIRC) * ... and others but we nitpicked on the document for ages. Virtually everybody in the vendor community couldn't believe that we were having such discussions about that stuff. So at some point most people argued that "they had already voiced their opinion, but they felt that it didn't made a difference". After all, they had already implemented the stuff discussed in the document (and so had others), so they really didn't have much of a reason to get involved in the process. I'd be glad to discuss a plan to pursue this work within the IETF. Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
- Fwd: Security Assessment of the Transmission Cont… Marshall Eubanks
- Re: Fwd: Security Assessment of the Transmission … Keith Moore
- Re: Fwd: Security Assessment of the Transmission … Joel Jaeggli
- Re: Fwd: Security Assessment of the Transmission … Keith Moore
- Re: Security Assessment of the Transmission Contr… Lars Eggert
- Re: Fwd: Security Assessment of the Transmission … Jari Arkko
- Re: Fwd: Security Assessment of the Transmission … TSG
- Re: Security Assessment of the Transmission Contr… Fernando Gont
- Security Assessment of the Transmission Control P… Fernando Gont