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

Joe Touch <touch@ISI.EDU> Tue, 25 September 2007 21:50 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IaIIN-00058I-KO; Tue, 25 Sep 2007 17:50:19 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IaIIL-000582-RR for; Tue, 25 Sep 2007 17:50:18 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IaIIL-0006d7-5D for; Tue, 25 Sep 2007 17:50:17 -0400
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id l8PLnvR4021984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Sep 2007 14:49:57 -0700 (PDT)
Message-ID: <>
Date: Tue, 25 Sep 2007 14:47:51 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc:, David Borman <>, Fernando Gont <>,
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: <>, <>

Hash: SHA1

Anantha Ramaiah (ananth) wrote:
>> Hat off ... 
>> This is a lot of hang wringing mumbo-jumbo, I think.  It 
>> seems to me ...
>>   + If a standards track document says "a TCP SHOULD do X" then as a
>>     particular TCP evolves it really ought to do X unless the
>>     implementers have a very good reason not to do X.
> Since, all these discussions about started due to TCP secure, let me use
> the same as an example. There is nothing wrong in making all mitigations
> SHOULD since the "very good reason" can be one of :-

... I'll number these for references:

> - I don't care about security/robustness of TCP connections and hence my
> products don't need to implement these.
> - well I do care about security but I always use additional protection
> like MD5 or IPsec and hence implementing this is optional. I'll think
> about it.
> - I like the mitigations in the draft and I see them lightweight and
> I'll go ahead and implement them, but since these are tagged SHOULD I
> may have a knob to control this behaviour.
> - I definetely would want to implement these. Even though it is a
> SHOULD, to me it is like a MUST.
> So what I am tryng to say is: it is upto the implementers to interpret
> and implement it if they wish to do so. Saying SHOULD is not an issue
> since it gives enough leeway for all of the above scenarios.

I don't think SHOULD covers #1 very well above, and it arguably doesn't
voer case 2 either. SHOULD really intends to mean "MUST unless you know
you know a specific reason that would be undesirable".

That's why I think some of us (myself included) prefer MAY for all (with
the caveat that there can be MAY for the whole set, and the additional
relative requirements, i.e., If you do A, you MUST do B.)


> But I am open to the idea of adding a generic applicability statement
> like : "these mitigations are useful in blah blah... Conditions etc., "
> Already if I remember correctly we do have some text to that effect in
> the draft, but we can polish it further or formalize it.
> -Anantha
> _______________________________________________
> tcpm mailing list
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla -


tcpm mailing list