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

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

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids6A-0008NJ-BJ; Fri, 05 Oct 2007 14:40:30 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ids69-0008Mz-0M for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 14:40:29 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ids68-0008L4-L6 for tcpm@ietf.org; Fri, 05 Oct 2007 14:40:28 -0400
Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ids68-0007mH-4D for tcpm@ietf.org; Fri, 05 Oct 2007 14:40:28 -0400
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (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 hut.isi.edu (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: <20071005183931.GB2845@hut.isi.edu>
References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu> <20071003181553.GF45911@hut.isi.edu> <4703E173.4060007@isi.edu> <20071005165755.GA2845@hut.isi.edu> <1191604898.470672a2ea7cb@webmail.isi.edu>
Mime-Version: 1.0
In-Reply-To: <1191604898.470672a2ea7cb@webmail.isi.edu>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0678691242=="
Errors-To: tcpm-bounces@ietf.org

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
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm