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

Ted Faber <faber@ISI.EDU> Wed, 03 October 2007 18:17 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 1Id8mr-00088u-0T; Wed, 03 Oct 2007 14:17:33 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Id8mp-00082S-Lv for tcpm-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:17:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8mp-00082J-CQ for tcpm@ietf.org; Wed, 03 Oct 2007 14:17:31 -0400
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id8mj-0006SK-3Z for tcpm@ietf.org; Wed, 03 Oct 2007 14:17:31 -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 l93IFr5U023596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Oct 2007 11:15:53 -0700 (PDT)
Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l93IFrhB029604; Wed, 3 Oct 2007 11:15:53 -0700 (PDT) (envelope-from faber)
Date: Wed, 3 Oct 2007 11:15:53 -0700
From: Ted Faber <faber@ISI.EDU>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
Message-ID: <20071003181553.GF45911@hut.isi.edu>
References: <0C53DCFB700D144284A584F54711EC580409FD4F@xmb-sjc-21c.amer.cisco.com> <46FF3FFA.4080207@isi.edu> <20071003172326.GE45911@hut.isi.edu> <4703D165.30606@isi.edu>
Mime-Version: 1.0
In-Reply-To: <4703D165.30606@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: 00e94c813bef7832af255170dca19e36
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="===============0773579442=="
Errors-To: tcpm-bounces@ietf.org

On Wed, Oct 03, 2007 at 10:29:09AM -0700, Joe Touch wrote:
> 
> 
> Ted Faber wrote:
> > Acting without a chair hat, I disagree.  The packet is being categorized
> > as suspicious, for example, it could have been spoofed, corrupted,
> > significantly delayed, whatever.  I see the ACK is an attempt to
> > synchronize the endpoints' states, not an attempt to autenticate the
> > peer.  The question being asked is closer to "what's going on on your
> > end?" than "who sent this packet?"
[snip]
> > 
> OK, so that makes it even more strange. You're requiring a unilateral
> reset (RST) to be issued only when the endpoint states are precisely
> aligned (no outstanding unack'd segments).
> 
> Why?

To make it unlikely that spoofed, delayed, erroneously generated, or
otherwise invalid packets will terminate an existing connection.

A correct implementation intentionally resetting will quickly become
synchronized even if the first RST was not from a perfectly synched
state.  The reset is potentially slower, but a poorly performing abort
facility doesn't upset me much.

Do you disagree with the characterization of the system or its
operation?

> 
> What does that tell you about the other end that you didn't know? What
> purpose relevant to resetting a connection does synchronizing state
> serve if not to authenticate the other end?

If the RST that triggered the ACK was from another connection, the
TCPsecure exchange tells you that the other end of this connection has
not reset.  No new information about the identity of that endpoint has
been asserted, simply that the end that got your ACK has state closely
enough synchronized with yours to make a sensical reply.  The identity
of the sender of the RST remains unknown (though if the other end *has*
reset, the sender is likely the other end).

I don't know anything new about the identity of anyone in the
communication; I just don't see authentication there.

> If not, then this is an even more bizarre requirement on an otherwise
> very simple mechanism.

Yeah, this has the feel of us talking past each other.

-- 
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