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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Alfred ? wrote:
...
> Regarding document structure:
> 
> The various past reviewers of the original document had
> 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.

...
> BTW: I could not even see where the fundamental basic discussion
> of protocol field properties might be located in the stucture
> Joe proposed.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqWJMsACgkQE5f5cImnZruAVACfXkBqsR2WbjB9wAIvuGP6t1Br
1hQAoJdjGqIAXwyKOm7s+tpR2L8Bm2F/
=MEdd
-----END PGP SIGNATURE-----