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

From: Alfred Hönes <[email-masked]>
Date: Thu, 27 Aug 2009 00:38:10 +0200 (MESZ)

Folks,
I strongly disagree with Joe's proposal.
For detailed rationale see below.

Furthermore, the envisioned procedure for the treatment of the
document is perceiced as discriminating; it gives much more
influence to WG participants with an always open time budget, who
can continually follow the discussion and participate quickly,
and it makes contributing by folks like me (who have a 'bursty'
primary business and can only spend cycles for IETF purposes
irregularly) rather difficult and/or inefficient.
Starting this important work, with very short timelines, during
the major summer vacation period is even more unfortunate.
The apparent outcome I observe is that very few but very active
voices already have started majorizing the discussion, and that
I have not heard voices of implementers recently.

Regarding document structure:

The various past reviewers of the original document had
appreciated the focus on implementer's point of view, which
is closely related to the document structure, and among those
reviewers were quite a couple of implementers.

For instance, when implementing checks on a protocol field,
a comprehensive discussion of the properties of that field
is needed, with a summary of known attacks using that field,
and a presentation of restrictions and extensibility properties
of such field, in order to allow the reader to easily make an
educated decision on what checks to implement and what possible
other related hardening measures/knobs for his/her implementation
are needed.
Scattering that information throughout the document will make
the utility of the document highly questionable.
BTW: I could not even see where the fundamental basic discussion
of protocol field properties might be located in the stucture
Joe proposed.

IMO, far-reaching structural changes should only be applied with
strong support from the TCP implementers' community.

As a mathematician, I have a strong preference for a bottom-up
document structure, starting with the definitions and proceeding
to the properties and gradually more complex conclusions;
in the context of protocol design and implementation, that means
a good document (after a short overview) should start with the
basic data structures and protocol fields.
The worst documents I ever had to read and understand were those
that gave the basics last (e.g., many OSPF documents, defining
the PDU fields and formats in Appendices -- ugly!)

Fernando's outline roughly follows that natural bottom-up paradigm,
starting with the PDUs and the field properties, specific attacks
related to each single field, and general considerations regarding
particular groups of fields -- that's what will go into header
files (in 'C' implementations) and low-level code;
then the original outline proceeds to major procedures to be
implemented (connection setup and teardown, data buffer and data
segment management, congestion control, 'abstract' / socket API
-- modules that typically will have identifiable components in an
implementation and which hence are worth a high-level block of
discussion in a document useful for implementers;
the final chapters discuss more general topics spanning multiple
of the previous topics, and the final chapters regarding ICMP
and the interface to IP help to align with related protocol
components -- you know, strict layer separation isn't a
property of TCP/IP!

There are indeed details to be discussed, e.g., whether the
section on TCP Options better be a subsection of the preceding
section.
IMO, that's not a good idea; the basic TCP Header is mandatory
and (almost) static, it won't change -- even in the long term
future evolution of TCP --, whereas TCP Options are a truly
optional ensemble subject to yes/no implementation decisions;
option design is an ongoing effort making it worth to separate
TCP Options off the basic TCP Header for the exposition, allowing
to discuss general topics specific to these circumstances there.

However, I suggest to re-organize the subsections on the src/dst
port fields:
A general discussion of port numbers, including server ports vs.
(ephemeral) client ports, and the case (and pros/cons) of
(symmetric) peer-to-peer applications operation with fixed port
numbers on both sides should precede the discussion of the
src and dst prot number fields, because the logical properties
of the port numbers (as mentioned above) are not bound to their
per-packet role as src/dst.

In any case, the document structure should be such that
important details can be located in the Table of Contents.
The RFC Editor usually limits the ToC to a certain nesting level
(based on style and available tools); therefore, nesting sections
too deeply should be avoided in favor of more primary sections.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Joe Touch <[email-masked]>
Date: Wed, 26 Aug 2009 23:16:43 -0700

Alfred ? wrote:
...
> appreciated the focus on implementer's point of view,...

This is a good point. This isn't just an implementer's guide, however.
Some of the issues are being discussed in detail for the first time in
this doc.

I.e., there are two separate issues:

1) what are the vulnerabilities

2) how to address the vulnerabilities

Some of the ways to address vulnerabilities are choices that the specs
left open to implementers. Some are weaknesses in the protocol itself
that a clever implementation can overcome (e.g. SYN cookies to overcome
the state introduced at SYN receipt). Others are created by inefficient
implementations (e.g., badly implemented TIME-WAIT state lists).

The first two are useful to discuss in a general outline form. The last
can be covered separately, since it's just bad coding to be avoided, and
often there are common causes (buffer overrun, bounds checking,
efficiency of lists).

The original outline I proposed was:

	1 intro
	2 background
	3 control attacks
	4 data attacks
	5 performance
	6 implementation issues
	7 security considerations

Based on the above, I'd update to be more like:

	1 intro
	2 background
	3 attacks
	  a in-band control plane (TCP header/options)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  b out-of-band control plane (ICMP)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c data plane
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c API
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	4 mitigations
	  a in-band control plane (TCP header/options)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  b out-of-band control plane (ICMP)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c data plane
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c API
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	5 implementations to avoid
	  a that create direct vulnerabilities
	  b that create performance vulnerabilities
	6 security issues

The last section (6) includes topics of security interest that are not
specific to a field, e.g., covert channel issues.

...
> of protocol field properties might be located in the stucture

Protocol fields are part of the header, so they are "control attacks",
and listed among the items that would be covered in section 3.

In the submitted I-D, protocol field properties are covered in sections
3,5,8,9,11,13,14,15. That is the issue the outline I proposed is
intended to address. Note that the outline I proposed didn't leave
things out; it was intended to organize things so that they tended to
fall into expected categories.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 28 Aug 2009 23:38:59 -0300

> Some of the issues are being discussed in detail for the first time in

The latter is true, but the document is still meant to target
implementers. If you spread the advice on a per-attack basis, or on a
protocol-weaknesses vs. implementer's-choice-weaknesses, you're
basically spreading the advice about a single protocol field or option
among multiple sections.

As an implementer, you don't want that. You want the whole advice in a
single place. You want to know everything that can go wrong with a
specific protocol-field or option (or mechanism, for instance), so that
you can easily convert that advice into code.

Spreading the advice on specific fields or options (or mechanisms) among
several sections would be a nightmare for anybody wanting to use this
document for hardening a TCP implementation (which is the target of this
document in the first place).

> implementations (e.g., badly implemented TIME-WAIT state lists).

What's the difference in here? Are we concerned about "who gets the blame"?

Again, if you are an implementer, and you're e.g. hacking the ACK
processing code, you want to know all you need to do with the field
(sanity checks, whatever), exactly. Whether the advice is considered an
implementer's BCP or a fix to the protocol, doesn't matter. Your TCP is
resilient, or it is not. That's what matters.

> 3,5,8,9,11,13,14,15. 

I disagree. Protocol field properties are covered in Sections 3 and 4.
e.g., Sections 5 through 9 cover specific mechanisms or policies, but
not the fields themselves.

Thanks,
-- 
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: Sun, 30 Aug 2009 10:24:18 -0700

> basically spreading the advice about a single protocol field or option

Maybe - some fields are susceptible to only a small set of attacks that
may be related. However, we'd also be allowing (if not encouraging) use
of protections as appropriate, rather than encouraging everyone to
implement every protection - some of which are not agreed as recommended
by the WG.

...
> What's the difference in here? Are we concerned about "who gets the blame"?

This doc isn't only useful to implementers. People developing specs care
about #1 - maybe these are holes to be filled. #2 can result in
interactions between the solution and the protocol that were unintended.
#3 is just good design.

An implementer needs to know when they're playing inside a box the spec
created (#1), playing around in ways that could affect the protocol now
or in the future (#2), or just need to apply known algorithms rather
than modify the protocol.

...
> not the fields themselves.

Well, I found 8 places. You found 2 places at least, if not another 2
for a total of 4 (I don't care whether it's a mechanism or policy, if it
affects the field).

The point is that in the outline proposed in ID-0, there are multiple
top-level sections where these issues are discussed. The idea that "an
implementer wants to find things in one place" is fine, but IMO the
outline I proposed may to a mode useful job of aggregating this
information than ID-0.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 01 Sep 2009 02:34:12 -0300

Hello, Joe,

> may be related. 

That's the exception, not the rule.

> However, we'd also be allowing (if not encouraging) use
> implement every protection - 

Joe, this is about hardening a TCP implementation, not about mitigating
some vulnerabilities while leaving the door open to the rest of them.

> than modify the protocol.

Exactly. That's why the document does not simply provide the "what to
do", but also provides a discussion of the mitigations, etc.

But the document is still aimed at implementers. A bunch of implementers
have already reviewed the document, and found the current outline useful.

> outline I proposed may to a mode useful job of aggregating this

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.

I'm not saying the outline you propose is "wrong". I'm saying it's not
the best approach for the public this document targets. That doesn't
mean that an alternative outline can be included in an appendix. -- that
may be useful.

Thanks!

Kind regards,