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

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Aug 2009 00:14:32 -0300

Folks,

As mentioned by David Borman, draft-gont-tcp-security has been adopted
as a wg item. It has been resubmitted as draft-ietf-tcpm-tcp-security, now.

I'd like to receive feedback on the outline of the document, i.e.,
whether you like the outline as-is or you think it should be modified.
(It should be noted that the document is aimed at TCP implementers, and
that's the reason for which most of the discussion is organized on a
per-protocol-field basis rather than on e.g., a per-attack-type basis).

We'll wait for your input on the outline of the document till August
26th, 2009 (one week from now).

BTW, as you may see, draft-ietf-tcpm-tcp-security contains only the
document outline, and the contents for the Introduction and the section
on the TCP "Source Port". The rationale for removing the rest of the
contents from the draft-ietf version of this document is that we want
the draft-ietf version to always represent wg consensus, to avoid having
implementers implement what's in the I-D assuming that it represents wg
consensus. Of course, the I-D will also contain the section that is
being currently discussed by the wg (hence the inclusion of the section
on "Source Port").

Once we are done with the outline, the plan is to move one section at a
time from draft-gont-tcp-security into draft-ietf-tcpm-tcp-security,
giving the wg enought time to provide feedback. (The first section to be
"discussed will be the one about the TCP "Source Port").

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Aug 2009 11:19:10 -0700

> whether you like the outline as-is or you think it should be modified.

I'll start with the observation that the WG approved an outline as the
WG starting point. The current doc has a few sections that are not an
outline; they should be omitted until we agree as a WG on their content.
This includes:
	1.1
	2.
	3.
	3.1
	3.1.1
	3.6.7

An exception would be only Sec 1.2, which is scoping the doc, and
providing a list of RFCs that might be relevant.

It seems useful to step back to the highest level of the outline.
Excepting required sections, they are:
	
	1 intro
	2 scope
	3 header fields
	4 common options
	5 connection establishment
	6 connection termination
	7 buffer management
	8 reassembly
	9 cong control
	10 API
	11 blind in-window attacks
	12 info leaking
	13 covert channels
	14 port scanning
	15 ICMP
	16 IP

It's not clear why 4 isn't part of 3, why 5 and 6 are separate, etc.
Overall, it'd be useful to have a more conventional structure:

	1 intro
		including scope
	2 background - to introduce terminology
		a) breakdown of TCP into:
			control
			data
			performance
			implementation
		b) threat model
		briefly explain attacks:
		- on-path vs. off-path
		- control vs. data vs. performance
		- injection vs. DOS

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.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 25 Aug 2009 11:17:03 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Joe Touch
>Sent: Thursday, August 20, 2009 2:19 PM
>

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
---------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2009 15:42:06 -0300

>> Then it'd be useful to break down TCP into its component parts, as
[....]
> no difficulty for implementers to use.

I think that for many attacks, the outline Joe is proposing becomes
ambiguous.

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.

> an appendix can index the recommendations differently.  

I feel comfortable with David proposal, btw.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Aug 2009 12:35:06 -0700

> attack". But one might argue that port scanning is, in some sense, an

That's a property of any way of organizing the topics - there are bound
to be overlapping cases. 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).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2009 17:30:59 -0300

Joe Touch wrote:

> to be overlapping cases. 

I don't think there's overlap in the current structure of the document.

> The issue to me is that the outline I proposed

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).

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Aug 2009 13:36:38 -0700

> 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.

> index (e.g., the one you proposed) in an appendix (as David suggested).

I don't see that as a useful way forward.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2009 18:41:06 -0300

> I don't see that as a useful way forward.

Well, no need to say that I have no problem to change the outline if the
wg feels that's the best way forward....

Also, regardless of our possible disagreement on this issue, your input
is always appreciated.

Thanks!

Kind regards,

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 12:40:29 +0100

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, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

> Sent: 25 August 2009 21:37
> To: Fernando Gont
> Cc: [email-masked]
> 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:
> >
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Aug 2009 01:41:41 -0300

Hello, Toby,

> 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. 

Before bringing this document to the IETF, most major vendors (including
Cisco, Juniper, Microsoft, and others) received a copy of it, and had
the chance to review it. Nobody complained about the document
outline/structure. Actually, they were very happy with it. So I'd argue
that *more* people from *outside* the IETF has read the document than
the people that

> 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.

A few comments/clarifications with respect to your note:

* My disagreement with the structure proposed by Joe should not be taken
as me "not accepting recommendations". As a wg participant, I guess I
can still have an opinion that differs from that of others'. That
doesn't mean that I won't accept recommendations when they reflect wg
consensus or are obvious improvements to the document.

* The current version of the document was thoroughly reviewed during two
years. Among the reviewers were many implementers, many of which are
listed in the "Acknowledgements" section. *Lots* of changes were made in
response to the feedback I got. Even during the last couple of months
before the official release of the UK CPNI version of it, I added around
15 pages in response to the feedback I received.

* I have always welcomed reviews of the document. For instance, I tried
to get reviews from the people that were likely to object the document
or suggest changes. e.g., I asked Joe myself to review the document
(both this TCP one and the IP counterpart)... even before the first IETF
Internet-Draft version of this document was published. I also asked
Alfred (whose reviews usually lead to lots and lots of changes) to
review the document, and I had to make lots of changes (in the
organization, prose, technical contents, etc.) and even had to add more
than ten pages at the last minute before publication to address
virtually all his comments.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Aug 2009 22:47:49 -0700

Fernando Gont wrote:
> the chance to review it.

It'd be useful to get input from a high-end server vendor. I would value
their input on TCP security/performance issues more.

As to input from outside the IETF, they're welcome to participate here.
The feedback from the meeting in Stockholm was to start with an outline,
and work the outline first, which is what I thought we were doing.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 27 Aug 2009 03:01:44 -0300

> their input on TCP security/performance issues more.

Anyone you're thinking of? Do let me know, and I will do my best to get
them involved.

> and work the outline first, which is what I thought we were doing.

One might argue that we had already adopted the document by that point
(e.g., see the chair's slides). So in some sense one might argue that
zero'ing the contents of the document and moving the structure around is
sort of going backwards. Nevertheless, I'm always open to do whatever it
takes to improve the document.

Thanks,