Re: [tcpm] tcpsecure: how strong to recommend?

Tim Shepard <> Tue, 25 September 2007 19:00 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IaFdq-0001KG-RI; Tue, 25 Sep 2007 15:00:18 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IaFdp-0001K9-Kz for; Tue, 25 Sep 2007 15:00:17 -0400
Received: from ([] helo=alva.home) by with esmtp (Exim 4.43) id 1IaFdh-0006eJ-8L for; Tue, 25 Sep 2007 15:00:15 -0400
Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1IaFdE-0000Gs-00; Tue, 25 Sep 2007 14:59:40 -0400
From: Tim Shepard <>
To: "Mitesh Dalal \(mdalal\)" <>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
In-reply-to: Your message of Tue, 25 Sep 2007 11:34:50 -0700. <>
Date: Tue, 25 Sep 2007 14:59:40 -0400
Message-Id: <E1IaFdE-0000Gs-00@alva.home>
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc:, Joe Touch <touch@ISI.EDU>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> The whole discussion becomes relevant only if we are really updating
> rfc793, so as long as you see these changes as standalone, the question
> of SHOULD/MUST/MAY  become self explanatory in the right context. 
> So, in that sense I propose the changes as MUST. If an implementation
> claims
> compliance with these changes, than this (MUST) is the way it has to be
> implemented.

I think we've lost something important with MAY/SHOULD/MUST stuff.

Recall Lars Eggert's pointing out the need for an applicability
statement (in general and in particular).

It seems the mitigations described in this draft should be implemented
in any TCP which is going to be used for things which use TCP in such
a way that they will be vulnerable (where the IP addresses of both
ends and the port number of one end are knowable by an attacker) *or*
something else could be done to reduce vulnerability to such an

But its not completely clear to me that here we are trying to define a
protocol, the sort of thing which needs things like MAY/SHOULD/MUST to
ensure that interoperability goals will be met.

A somewhat serious security problem was discovered some time ago.
This draft documents one vendor's approach to solving this problem.
There are other ways of solving this problem.  It's not clear that a
standard is needed here to ensure interoperability of systems.

What is our goal here with this document?

Can the English word "should" be used in an RFC (without making it uppercase)?

I'd be happy publishing this document as informational and not
sweating the MAY/SHOULD/MUST stuff.  Just make them lowercase and make
the text make sense.

How's BTNS coming along?   Will we be seeing BGP over BTNS anytime soon?
(I've not been following BTNS too closely recently).

			-Tim Shepard

tcpm mailing list