Subject: RE: [tcpm] draft-ietf-tcpm-tcpsecure-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Mon, 26 Apr 2004 19:22:45 -0700

> > ...  But I think most host TCP implementors
> > will hesitate to implement that.
> 
> Frankly, I'd be surprised if host TCP implementors made any changes
> whatsoever.  That's why I like the proposed changes in Randall's
> draft.  (Well, that and the fact that I had a small hand in helping
> him!)  These changes impose no requirements at all on changes being
> made on the TCP peer unless the peer wants to be protected from the
> RST or SYN attack, or data injection.  And that's probably not very
> likely, since most host TCPs won't engage in long-lived sessions
> that are painful to restart.

You also have to consider that any change can backfire and break some
application somewhere. You are trading one risk, a DOS attack that will
sometimes succeed in breaking connections, against another, a change
that will sometimes break existing applications. You want to be very
careful for that kind of trade-off.

The DOS attack requires 4 conditions:

1) The attack requires identification of two ends of a connection;
2) The attack is easier to conduct if the port numbers of both ends of a
connection can be predicted;
3) Long duration sessions are more at risk that short connections;
4) The attack is amplified if the loss of a connection results in a
change in application behavior.

BGP is a bit unique because it meets all of these requirements. Very few
other applications meet more than 2 of the 4. Hence the desire to not
rush a solution that might backfire.

-- Christian Huitema

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Tim Shepard <[email-masked]>
Date: Mon, 26 Apr 2004 23:17:50 -0400

I think if we do have any change, it would not be a general change to
TCP, but rather a special mode you could put a TCP into with a call to
ioctl(,SO_TCP_RADIATION_HARDEN,) which would cause it to treat bare
RSTs skeptically (and somehow handle the other two problems).  At
least for a while.  Perhaps after some years of experience with this,
we could later recommend that it be turned on by default.  Those
particular services that need to be secured sooner (like BGP
connections) can turn it on explicitly if they lack some better way to
secure the connection.

(And now for some half-baked ideas....)

The timestamp option seems useful here.  The other end is constantly
proving to you that has received a recent timestamp value from you (by
sending it back to you).

I'm not sure though if RSTs typically include a timestamp option if
the packet that triggered the RST had a timestamp in it.  If they do,
then that's probably the right cookie we need.  (If your TCP had
gotten to ESTABLISHED with the timestamp options enabled, then the
other end clearly supported the timestamp option before, and
presumably they will still support the timestamp option if they should
inadvertently reboot and lose state of this connection.   So it seems
reasonable to expect the other end to include a timestamp option in
the RST.)

But..... are the timestamps used in the timestamp option offset by
some secret value (e.g. a good random number selected by a good secret
hash of the IP addresses and port numbers involved)?  Otherwise, the
timestamps might be guessable by an attacker.

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Apr 2004 09:25:05 -0700

> connections) can turn it on explicitly if they lack some better way to

That sounds very much like the EXPERIMENTAL track, ala some of the fast 
TCP mods, which appear equally benign, but are equally niche right now.

Joe

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 27 Apr 2004 18:30:48 -0700

> timestamps might be guessable by an attacker.

This depends on the implementation.  RFC 1323 does not specifies
how the timestamp is chosen as long as the value increases at
least at a certain rate.  So a TCP stack using this mechanism for
protection, it should choose the value carefully.

-- 

						K. Poon.
						[email-masked]