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

Ted Faber <faber@ISI.EDU> Fri, 05 October 2007 17:00 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 1IdqXD-00007q-He; Fri, 05 Oct 2007 13:00:19 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IdqXC-000063-E3 for tcpm-confirm+ok@megatron.ietf.org; Fri, 05 Oct 2007 13:00:18 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdqXC-00005L-2J for tcpm@ietf.org; Fri, 05 Oct 2007 13:00:18 -0400
Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdqXB-0003fe-9g for tcpm@ietf.org; Fri, 05 Oct 2007 13:00:17 -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 l95Gvubf017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Oct 2007 09:57:56 -0700 (PDT)
Received: (from faber@localhost) by hut.isi.edu (8.14.1/8.14.1/Submit) id l95Gvulg003798; Fri, 5 Oct 2007 09:57:56 -0700 (PDT) (envelope-from faber)
Date: Fri, 05 Oct 2007 09:57:56 -0700
From: Ted Faber <faber@ISI.EDU>
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] tcpsecure: how strong to recommend?
Message-ID: <20071005165755.GA2845@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>
Mime-Version: 1.0
In-Reply-To: <4703E173.4060007@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: 36b1f8810cb91289d885dc8ab4fc8172
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="===============0145917286=="
Errors-To: tcpm-bounces@ietf.org

On Wed, Oct 03, 2007 at 11:37:39AM -0700, Joe Touch wrote:
> Ted Faber wrote:
> > 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?
> 
> Asking to 'synchronize with the other end' is authentication, especially
> when the only purpose behind it is to determine whether a spoofed packet
> is generated.

"Did you say that?" is a fundamentally different question that "Who said
that" in my mind.  Asking the first in this context is both more useful
and more practical to determine.

If you want to think of them both as authentication, I'm not going to
try any more to convince you not to.

> 
> It's insincere to rationalize events like erroneously generated or
> delayed RSTs into this discussion. Both kinds of RSTs are just as valid
> as correctly generated, timely ones, as far as the TCP spec is
> concerned, unless you're concerned they're beings spoofed.

I'm perfectly sincere about it.  I think pointing out that the technique
mitigates several possibilities emphasizes its value from an engineering
perspective.

I can't argue with your perfectly correct statement that a compliant TCP
will treat the spoofed, out of date, erroneously generated, or damaged
packets as correct and reset the connection.  The argument is whether
that behavior is useful or not.  

I think it's not, but YMMV.

> 
> >> 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.  
> 
> That presumes that either the RST is floating in the network more than 2
> MSLs or that your end decided to accept a connection it shouldn't have
> since it didn't correctly wait 2 MSLs from a previous connection.

Again, technically correct.  I think that addressing the eventuality that
(among other things) MSL is incorrectly estimated or configured with an
extra packet exchange is good engineering.

Yes, I know that an "engineering decision" is often difficult to tell
from an "egregious hack."  I think that this design is the former.

> 
> If we're going to patch TCP to fix >2MSL errors, there's a lot more work
> than this to be done. If your end is broken, then expecting this patch
> to correct the situation is not productive.

Again, engineering vs. protocol design.

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.  I do not characterize this as provably correcting a protocol
flaw.

> 
> > 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).
> 
> The identity of the other end is defined by the synchronization process
> - it's a TCP endpoint with which your ACKs synchronize state.
> 
> > I don't know anything new about the identity of anyone in the
> > communication; I just don't see authentication there.
> 
> You know it's the other end with which you can synchronize state. That's
> identity.

I think we're arguing over what to name the process.  This would be fun
to do in person, but I don't think it's advancing the discussion of the
system, or in particular of the discussion about the guidance to
implementers we're trying to decide on.

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