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

<toby.moncaster@bt.com> Wed, 26 August 2009 11:43 UTC

Return-Path: <toby.moncaster@bt.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 318DF3A6AD5 for <tcpm@core3.amsl.com>; Wed, 26 Aug 2009 04:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level:
X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 Z7guLrz5iM-m for <tcpm@core3.amsl.com>; Wed, 26 Aug 2009 04:43:30 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 2DEF33A6A24 for <tcpm@ietf.org>; Wed, 26 Aug 2009 04:42:44 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 12:41:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Aug 2009 12:40:29 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC70CC81561@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <4A944B56.5080200@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document
Thread-Index: AcolxBs0HSBOzCEGQqWY1s2AssRguAAfTO3Q
References: <4A8CBF98.1070809@gont.com.ar><4A8D939E.9050008@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB479B7E7359@NDJSSCC01.ndc.nasa.gov> <4A94307E.2080209@gont.com.ar><4A943CEA.4000905@isi.edu> <4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu>
From: <toby.moncaster@bt.com>
To: <touch@ISI.EDU>, <fernando@gont.com.ar>
X-OriginalArrivalTime: 26 Aug 2009 11:41:12.0777 (UTC) FILETIME=[1CE24B90:01CA2642]
Cc: 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: Wed, 26 Aug 2009 11:43:32 -0000

I definitely agree that Joe's structure looks more organised. As he points out, it is impossible to create a comprehensive structure that removes all overlap or contradictions. If you want this document to succeed (rather than join an ever-growing pile of RFCs that no-one outside the IETF have even read) then making it easily readable has to be the first requirement. A significant part of readability is the structure used to present the data in the document. It is always hard as an author to accept recommendations that seem to alter one's work so fundamentally but remember that other people are able to take a step back from the detail in a way you, as an author, may not find so easy.

Toby

____________________________________________________________________ 
Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 



> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
> Joe Touch
> Sent: 25 August 2009 21:37
> To: Fernando Gont
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] tcp-security: Request for feedback on the outline
> of the document
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Fernando Gont wrote:
> > Joe Touch wrote:
> >
> >>> e.g., think about the "Rose attack" described in the MSS section.
> The
> >>> attack employs the TCP MSS option (and thus would be included in
> >>> "control attacks" according to Joe's outline). However, the attack
> >>> attempts to degrade performance. So.. where would the attack be
> finally
> >>> included?
> >>> Joe argues that "info leaking" and that port scanning is a "control
> >>> attack". But one might argue that port scanning is, in some sense,
> an
> >>> info leaking attack.
> >> That's a property of any way of organizing the topics - there are
> bound
> >> to be overlapping cases.
> >
> > I don't think there's overlap in the current structure of the
> document.
> 
> The current document doesn't have the kind of structure I'm suggesting
> is important.
> 
> >> The issue to me is that the outline I proposed
> >> has easily recognized structure to it, and I at least know where
> various
> >> attacks should go (even if they go in one place and are cross-
> referenced
> >> and also discussed in others).
> >
> > IMO, the issue here is not whether one knows where to put them, but
> > rather whether implementers would know where to find them.
> >
> > IMHO, I'd live the main structure "as is", and would add an alternate
> > index (e.g., the one you proposed) in an appendix (as David
> suggested).
> 
> I don't see that as a useful way forward.
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkqUS1YACgkQE5f5cImnZrtyngCeIu1SCaxiA04zoWuvq3ap12lP
> En0AoLemlz2eQCngpm/zpRZgN62iaZ/0
> =sR5K
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm