Re: [tcpm] tcp-security: Request for feedback on the outline of the document

Fernando Gont <fernando@gont.com.ar> Thu, 03 September 2009 19:57 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 C960C3A67C2 for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 12:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.257
X-Spam-Level:
X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 O19lbldsfNeb for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 12:57:34 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id EF2053A67A1 for <tcpm@ietf.org>; Thu, 3 Sep 2009 12:57:32 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 8A2C56B681E; Thu, 3 Sep 2009 14:40:37 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n83HeQ5B032086; Thu, 3 Sep 2009 14:40:27 -0300
Message-ID: <4A9FFF8C.7040001@gont.com.ar>
Date: Thu, 03 Sep 2009 14:40:28 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: toby.moncaster@bt.com
References: <200908262238.AAA06336@TR-Sys.de><4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar><4A9AB5C2.4090209@isi.edu> <4A9CB254.7050802@gont.com.ar> <AEDCAF87EEC94F49BA92EBDD49854CC70CDCE9FF@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <AEDCAF87EEC94F49BA92EBDD49854CC70CDCE9FF@E03MVZ1-UKDY.domain1.systemhost.net>
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]); Thu, 03 Sep 2009 14:40:36 -0300 (ART)
Cc: ah@tr-sys.de, tcpm@ietf.org, touch@ISI.EDU
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
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: Thu, 03 Sep 2009 19:57:36 -0000

Hello, Toby,

> opinions on this document that are clearly incompatible. One key thing,
> regardless of how we actually decide to split the work, Fernando's
> current ToC is too long... 3 pages of ToC is excessive. 

Well, it's a large document. Even If we reduce the number of top-level
sections, the ToC would most likely still be that large (or it wouldn't
be useful).


> I think the
> sections aren't grouped at a high enough level (e.g. connection
> establishment and tear-down could be in one section on connection
> management, buffer management and re-assembly could probably be grouped
> into memory management, etc). 

I agree. Please let me have another look, and try to come up with something.


> This is separate to any consideration as
> to whether you should be presenting things in a completely different
> order... I think Joe actually raised this before...

I don't think this is what Joe raised. For the most part, he argued to
organize the information on a per-attack-type basis. Anyway, you did
raise it... so,.. point taken.



>> Again: the goal of this document is helping TCP implementers harden
>> their TCPs. And for that target, having everything about a protocol
>> field in a single place is the only document outline that does not get
>> in the middle of the developer and the implementation. If you spread
>> the
>> advice among lots of places, this is what will happen: some
> mitigations
>> will be missed.
> 
> So if this is entirely aimed at implementers shouldn't that be
> explicitly stated in the title? I appreciate that in theory BCP is meant
> to imply implementation guidance but this might be more appropriately
> titled something like "Implementers guidelines for mitigating TCP
> security threats" or "Guidance on secure implementation of TCP"

Point taken. How about "Guidance on secure implementation of the
Transmission Control Protocol (TCP)"?

Thanks!

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