Subject: [tsvwg] Opening-up for comments on the TCP-Stealth draft

From: [email-masked]
Date: Mon, 27 Jul 2015 08:34:36 +0100

I promised people I would send a list of "comments" following the previous
discussion of
the TCP Stealth draft, to see if people would be able to come to some
conclusions on
the TSVWG list.

So  here's a short summary of previous TCPM/TCPINC issues/comments from
-00 onwards.  The original text of the comments can be found on other IETF
lists... Feel free to expand - or explain which have already been
addressed... Using the TSVWG mailing list.

Gorry

----

Function:

Intended for use with SSH, not as a HTTP replacement. How widely usable is
this?

One comment was that this is about minimizing visible Internet footprint,
but not hiding from a listener.

The authors claim it's useful as a small change for connecting to services
in ways
that defeat "script kiddies" without setting up port knocking.

This doesn't discuss (or cite) RFC6528, but seems like it is a play on the
secret
key cited in Sec 3 of that RFC.

Someone said something like:
"seems like a syn-cookie variant, with no need to standardize"

Transport-related:

It was suggested that it would be easy to identify stealth sessions (ISN
and port
reuse vs. randomization) and to interfere with segments in-transit and
cause drops.

A static ISN for 4-tuple increases the collisions.

Middleboxes that update ISN will stop this working.

Changing TSval could affect TCP PAWS.

Security-related:

Is MD5 the correct algorithm?

Why not use TLS client certs instead?

Someone asked where's key propagation?

I saw a concern with sending RSTs upon a failed port knock (vs. being silent)

----

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jul 2015 16:12:32 -0700

Hi, all,

I have two observations:

a) if the authors would like feedback on an update of a draft, they
might find it useful to announce that draft on an IETF mailing list

	especially on the list where the discussion originally
	occurred (e.g., Aug 2014, TCPM, TCPINC); -01 was
	issued in Jan 2015 but not announced on either list

b) it would also be useful for the update to address the issues raised
in previous discussions

	there were many issues raised in Aug 2014 for the -00 version,
	and it does not appear any were addressed in the -01 update

So, IMO, despite the "urgent" need to schedule an IETF TCPM presentation
on this update, I see no need to comment on this version further.

Joe