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

Fernando Gont <> Sat, 29 August 2009 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 857053A6878 for <>; Fri, 28 Aug 2009 19:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QsQF67kTEJKk for <>; Fri, 28 Aug 2009 19:39:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3BB433A6806 for <>; Fri, 28 Aug 2009 19:39:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EED4B6B681D; Fri, 28 Aug 2009 23:39:23 -0300 (ART)
Received: from [] ( []) (authenticated bits=0) by (8.14.1/8.14.1) with ESMTP id n7T2d470008071; Fri, 28 Aug 2009 23:39:05 -0300
Message-ID: <>
Date: Fri, 28 Aug 2009 23:38:59 -0300
From: Fernando Gont <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 ( []); Fri, 28 Aug 2009 23:39:22 -0300 (ART)
Cc: Alfred ? <>,
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Aug 2009 02:39:14 -0000

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.

Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1