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

Joe Touch <touch@ISI.EDU> Sat, 06 October 2007 01:15 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IdyGp-0007fL-LU; Fri, 05 Oct 2007 21:15:55 -0400
Received: from tcpm by with local (Exim 4.43) id 1IdyGn-0007f0-Oe for; Fri, 05 Oct 2007 21:15:53 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1IdyGn-0007aP-DZ for; Fri, 05 Oct 2007 21:15:53 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1IdyGf-00042a-4h for; Fri, 05 Oct 2007 21:15:51 -0400
Received: from [] ( [] (may be forged)) by (8.13.8/8.13.8) with ESMTP id l961EmGo000293; Fri, 5 Oct 2007 18:14:49 -0700 (PDT)
Message-ID: <>
Date: Fri, 05 Oct 2007 18:14:39 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Ted Faber <faber@ISI.EDU>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.3
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Cc:, "Anantha Ramaiah \(ananth\)" <>,
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: <>, <>
Content-Type: multipart/mixed; boundary="===============0558697607=="

Ted Faber wrote:
> On Fri, Oct 05, 2007 at 10:21:38AM -0700, touch@ISI.EDU wrote:
>>> IMHO, we're already addressing unlikely events - MSL violation or
>>> off-path spoofed RST with known addresses and ports.  I think that the
>>> cost of one packet exchange to validate that the connection is not about
>>> to be terminated by an unlikely event is a reasonable engineering
>>> choice. 
>> TCP was designed to be able to unilaterally terminate a connection with a RST.
>> If you wanted a handshake, why did you not use FIN?
> That's an instructive example.
> If your RST is lost - they're not sent reliably as a FIN is - the packet
> exchange is exactly the one TCPsecure proposes: ACK the last packet.
> (Strictly speaking the lost RST doesn't do it of course - that would be
> a nice trick.  Either new data goes out (ACKing the last packet as
> well), or a retransmission occurs, or a window probe goes off.)
> Receiving the ACK triggers a retransmission of the RST and state
> synchronizes.  If all the RSTs are lost, the state still synchronizes
> with a timeout.  I wouldn't call that an authentication (and I know you
> didn't), but the process is very similar to how TCPsecure plays out.

It's not the same, as you point out. If there's no further data to be
sent, then it doesn't necessarily behave like a FIN exchange.

If you want a coordinated endpoint exchange, I suggest using a FIN.

> If we were in a drinking establishment or academic symposium where the
> navel gazing were appropriate, we could discuss whether that RST packet
> "unilaterally terminates the connection" or is a hint that the
> connection has been unilaterally terminated by the destruction of the
> connection state at one endpoint. 

I doubt we would debate that long; I agree with you, I suspect, that the
latter is more precise. It's a hint.

Again, a reason why you either take the hint or not. You don't respond
to it, and you don't gain anything - except over-optimization - by
telling the other end anything to confirm that hint.

> I'm sure you can tell what I
> believe, and I'm suggesting that thinking of both these processes as
> confirming a hint might be less objectionable to you than thinking of
> them as authenticating a message. 

Confirming that it's a hint? Confirming what? That the hint came from
who you thought. Again we're back to authentication.

> But here on the list, I'm hoping that talking about what a "slightly
> unusual" packet is might steer us back toward the
> MAY/SHOULD/MUST/applicability statement discussion.

It walks, looks, and quacks like a duck. Whether you will agree to call
it a duck or not, I won't worry. But I've treated it like a duck in

If we truly want to get back to that discussion, I haven't heard others
address the proposed way forward I offered...


tcpm mailing list