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

From: Ted Faber <[email-masked]>
Date: Wed, 3 Oct 2007 10:23:26 -0700

On Sat, Sep 29, 2007 at 11:19:38PM -0700, Joe Touch wrote:
> Anantha Ramaiah (ananth) wrote:
> > I will have to dis-agree to this since my viewpoint is different. TCP
> > secure adds robustness to the processing of certain TCP segments, which
> > in turn helps to counter *some* spoofing attacks. Calling it as an
> > authentication scheme seems too far-fetched.
> 
> You are making an assertion about whether you believe the packet is
> spoofed or not based on its content matching what you expect from the
> true endpoint.
> 
> That is called authentication. Weak, but still authentication.

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

While some of the discussion has definitely leaned toward security and
authentication terminology, I don't think that's the essence of the
proposed system.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Oct 2007 10:29:09 -0700

> authentication terminology, I don't think that's the essence of the

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?

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 not, then this is an even more bizarre requirement on an otherwise
very simple mechanism.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 3 Oct 2007 11:15:53 -0700

> > end?" than "who sent this packet?"
[snip]
> aligned (no outstanding unack'd segments).

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?

> 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

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Oct 2007 11:37:39 -0700

> Do you disagree with the characterization of the system or its

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.

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.

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

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.

> No new information about the identity of that endpoint has

The identity of the other end is defined by the synchronization process
- it's a TCP endpoint with which your ACKs synchronize state.

> communication; I just don't see authentication there.

You know it's the other end with which you can synchronize state. That's
identity.

Joe

---

From: Ted Faber <[email-masked]>
Date: Fri, 5 Oct 2007 09:57:56 -0700

> when the only purpose behind it is to determine whether a spoofed packet

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

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

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

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

> You know it's the other end with which you can synchronize state. That's

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.

---

From: [email-masked]
Date: Fri, 5 Oct 2007 10:21:38 -0700

> try any more to convince you not to.

The only difference between "did you say that" and "who said that" is who is
providing the authentication. The latter can be authenticated by a third party,
where the first is done exclusively by the other end of the connection. I hope
that at least helps explain why I see these as equivalent, even if not everyone
agrees with it.

> I think it's not, but YMMV.

I think I've shown above that the utility of the behavior is exclusively
motivated by authentication, and that other justifications don't have valid
support.

You can still think it's useful. I don't think it's not useful, so much as not
necessary if you're really concerned about security, and potentially dangerous
(unncesssarily complicated and IPR-burdened) if you aren't.

> from an "egregious hack."  I think that this design is the former.

Good engineering to update TCP to handle incorrect MSL estimation would be a
substantial piece of work. It would require reevaluating everything from SYN
exchanges to window offset validation. At the end of the day, if you don't
trust the MSL estimation, you need anti-replay. Yet another good reason to use
something like IPsec if this is what you're true concerns are, rather than a
patchwork of solutions that approximate anti-replay in specific cases.

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

..
> implementers we're trying to decide on.

I agree with that, but we've tripped over some other name issues that are
fundamental here:

---

From: [email-masked]
Date: Fri, 5 Oct 2007 10:28:49 -0700

Quoting [email-masked]:

..
> I agree with that, but we've tripped over some other name issues that are

, notably whether this is an update to RFC793 (I think most of us agree that it
is).

It's important for implementers to know why we're doing what we're doing, and
this is purely motivated by security concerns, and provides no real protection
from incorrect MSL estimation to TCP as a whole. That's why calling it
authentication is important. Calling it a patch to update TCP's robustness is
incorrect and misleads implementers into adopting this mechanism unncessarily.

Joe

---

From: Ted Faber <[email-masked]>
Date: Fri, 5 Oct 2007 11:39:31 -0700

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

---

From: Ted Faber <[email-masked]>
Date: Fri, 5 Oct 2007 11:44:36 -0700

On Fri, Oct 05, 2007 at 10:28:49AM -0700, [email-masked] wrote:
> , notably whether this is an update to RFC793 (I think most of us
> agree that it is).

Yep.  It's not much of an exercise to point at the paragraphs that
change.

> incorrect and misleads implementers into adopting this mechanism unncessarily.

I do think it makes TCP slightly more robust, but the occurrances that
would trigger that robustness are pretty unusual.  The most common cause of
that uncommon set is malice.  Do you think that concentrating on the
likelihood of bad RSTs (and SYNs and data) showing up would steer us
back toward the recommendation level?

---

From: Ted Faber <[email-masked]>
Date: Fri, 5 Oct 2007 11:46:20 -0700

> MAY/SHOULD/MUST/applicability statement discussion.

Who the heck do I think I'm quoting there?

Sorry.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Oct 2007 18:15:47 -0700

Ted Faber wrote:
...
> back toward the recommendation level?

I don't think considering these RSTs/SYNs/data issues more than
malicious is appropriate, and I do think that has a lot to do with the
recommendation level.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Oct 2007 18:14:39 -0700

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

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

> 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
deciding MUST/MAY/SHOULD.

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

Joe