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

"Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov> Tue, 25 August 2009 16:17 UTC

Return-Path: <wesley.m.eddy@nasa.gov>
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 4004E3A67A8 for <tcpm@core3.amsl.com>; Tue, 25 Aug 2009 09:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.451
X-Spam-Level:
X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 QFGIGS-0o4BB for <tcpm@core3.amsl.com>; Tue, 25 Aug 2009 09:16:59 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 5F10A3A6ABA for <tcpm@ietf.org>; Tue, 25 Aug 2009 09:16:59 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 4801BAC76; Tue, 25 Aug 2009 11:17:03 -0500 (CDT)
Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7PGH3Xg030331; Tue, 25 Aug 2009 11:17:04 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 25 Aug 2009 11:17:02 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Joe Touch <touch@ISI.EDU>, Fernando Gont <fernando@gont.com.ar>
Date: Tue, 25 Aug 2009 11:17:03 -0500
Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document
Thread-Index: AcohwuOGrbF1dSPtQ7SU9PXJaVk8LQD2tPOQ
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB479B7E7359@NDJSSCC01.ndc.nasa.gov>
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>
In-Reply-To: <4A8D939E.9050008@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-25_05:2009-08-11, 2009-08-25, 2009-08-25 signatures=0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
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: Tue, 25 Aug 2009 16:17:00 -0000

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>Joe Touch
>Sent: Thursday, August 20, 2009 2:19 PM
>
>Then it'd be useful to break down TCP into its component parts, as
>introduced in 2a:
>
>	3 control attacks
>		header fields
>		option fields
>		connection establishment
>		connection termination
>		port scanning
>
>	4 data attacks
>		injection
>		info leaking
>
>	5 performance
>		cong control / ACK attacks
>		reassy attacks
>
>	6 implementation issues
>		performance, e.g., SYN cookies, buffer mgt.
>		API, IP interface issues
>
>	7 security considerations
>		this can be used as a catchall for items that don't
>		fit as directly above and aren't specific to TCP,
>		e.g., covert channel issues, info leaking etc.
>
>IMO, this presents the info in a way that is still organized for
>implementers, but structures it in a way that the info can be more
>easily located when needed.


I like the hierarchy that Joe suggests; it groups similar issues and
recommendations together, and I agree with  him that it would pose
no difficulty for implementers to use.

David had suggested that however the document content is organized,
an appendix can index the recommendations differently.  That makes
sense to me too, though from the standpoint of actually reading the
document itself, I think something like Joe's outline is much better.

However, my opinion isn't very strong on this, and I'm comfortable
with however this thread converges.


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------