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

[Fernando Gont <[e-mail]>]

Joe Touch wrote:

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

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



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

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.



> In the submitted I-D, protocol field properties are covered in sections
> 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: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1