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

Ted Faber <faber@ISI.EDU> Fri, 05 October 2007 18:40 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Ids6A-0008NJ-BJ; Fri, 05 Oct 2007 14:40:30 -0400
Received: from tcpm by with local (Exim 4.43) id 1Ids69-0008Mz-0M for; Fri, 05 Oct 2007 14:40:29 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1Ids68-0008L4-L6 for; Fri, 05 Oct 2007 14:40:28 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1Ids68-0007mH-4D for; Fri, 05 Oct 2007 14:40:28 -0400
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id l95IdW2j028725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 11:39:32 -0700 (PDT)
Received: (from faber@localhost) by (8.14.1/8.14.1/Submit) id l95IdVAr006113; Fri, 5 Oct 2007 11:39:31 -0700 (PDT) (envelope-from faber)
Date: Fri, 5 Oct 2007 11:39:31 -0700
From: Ted Faber <faber@ISI.EDU>
To: touch@ISI.EDU
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
Message-ID: <>
References: <> <> <> <> <> <> <> <>
Mime-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/
X-ISI-4-43-8-MailScanner: Found to be clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
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="===============0678691242=="

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.

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'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.  It's a sadder world that we're not in
one of those places.

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.

Ted Faber           PGP:
Unexpected attachment on this mail? See
tcpm mailing list