[tcpm] previous notes on tcp-secure-04

Here are my previous notes on v04, with comments to clarify. I do not
feel that some were addressed in v05. I appreciate Randall's addressing
them in the WG today, but it would have been useful to have addressed
them on-list when 05 was issued. That would have saved substantial
effort in re-reviewing 05 on points that were not addressed.

I further felt that 05 was a cosmetic update to 04, especially given the
detail provided below.

FWIW, these were sent privately to Randall and the chairs in March; this
is the first time they appear on this list.

I have added "NOTE:" comments to clarify below.

Joe
-----------------------------------------------------------------------

A. the doc describes 3 different mods
	1. RST
	2. SYN
	3. data injection

It'd be useful to explain what the common thread is, and why all three
are needed. RST and SYN fall into the same "short run for a long slide"
category.

	NOTE: there are a set of solutions that are all
	presented in this document as related, and all implied as
	"quick fixes with large benefit" (short run/long slide).
	It'd be useful to explain them as having a common reason,
	rather than just as a shopping list of things to fix.

The data injection stuff seems out of place, though. The solution is
comparatively cumbersome and I don't believe as well agreed. It's also a
bit misnamed (it's really a blind window sliding attack), and blind data
injection is still fairly simple (in-window).

B. the general document writing and presentation needs work
including spelling, sentence structure, etc.

	NOTE: this refers to readability and comprehension
	of the issues and protocol changes required, to the
	extent that the current language gets in the way
	of that.

C. I would suggest a more focused discussion as follows:

	a. section 1 should summarize tcp-antispoof in a paragraph or
	two, but otherwise ref off to that

	instead, it should focus on a few things:
		1. how a TCP solution is different
		2. why the group of mods to TCP are all related
		3. why modifying TCP here is a good thing

	I would agree that cleaning up unintended holes in TCP
	processing is reasonable, esp. given the small mods that can
	accomplish them (e.g., for RST and SYN).

	I would prefer if that were the focus of the doc (safety from
	incorrect messages, regardless of intent) , with the
	side effect of increasing resistance to some recent attacks,
	BUT that if real protection is required, that real security
	is recommended (e.g., IPsec).

	Where increased resistance is described ("much harder"), it
	should be quantified.

	b. the protocol sections should discuss things 793-style
	Some of the discussion of the changes seems more like a
	recipe than a protocol spec change.

	Specific portions of 793 should be quoted where needed,
	and changes clearly indicated. These should be entitled
	"Changes to 793" or somesuch, rather than 'Mitigation'.

	c. section 5- the blind data stuff, is "too long a walk
	for a short slide"

	It requires new TCB state (MAX.SND.WND) which is very informally
	introduced, and not discussed:
		- do you save the window scale for that max?
		- does this present an opportunity for attack itself?

	While this protects from some ACK attacks, it's still
	sufficiently easy, after this mod, to inject ACKs that
	accomplish the same purpose, or to inject data similarly.

	I would recommend removing it.

D. ACK throttling needs a more clear discussion

The requirements need to be separated and condensed as a list, rather
than dispersed througout (the same recommendation applies to other
sections, BTW).

The potential for implementation deadlock deserves much more than a
passing reference; this is a substantial concern. If there's a way
around it, it should be discussed. It seems incumbent to me that this
solution MUST  ;-)  specify the protocol behavior in such a way that
such deadlocks are not possible. (793 does this all over the place, by
placing rules on the order of handling queued segments, order of
handling signals, data, etc., etc.)

E. the backward compatibility section needs to highlight a few more things:

- - when incrementally or mutually deployed (separate discussions):
	- which sides benefit and how
	- which sides are impacted and how
	- is there any impact or benefit to third parties

middlebox considerations are a subsection of backward compatibility, IMO

I would suggest that mboxes that modify TCP packets are briefly
described as "deserving what they get" rather than going into details.
What some mboxes do is irrelevant; more to the point is what we can
expect a mbox to do, and that's not really static anyway (unless you
refer off to the RFC defining the versions, like half-cone, full-cone,
etc.) Finally, I would suggest that protection from mbox interference is
better provided by IPsec (which would interfere with mbox mod of the
packets).  ;-)

Interoperability reports seem like at best an appendix, but more like
something that would accompany the submission of this doc as
standards-track. It doesn't seem like it ought to be inside the doc.

F. security considerations should address the benefits vs limits in
specific - how much more security is provided, and what are the limits.
it should also note that on-path attacks are still possible, and that
data injection attacks are still possible. it should finally note that
full protection warrants the use of IPsec (that's what security consids
are for!)

if there are still deadlocks possible that can be triggered by malicious
parties, then that needs to be noted here too

G. section 12 ought to note the input of the TCPM WG, and a few names
there if you feel appropriate. This work was, IMO, polished by the WG a
bit since I first saw it (e.g., the need for ACK throttling), and that
too should (IMO) be noted.

	NOTE: i.e., the ack throttling (ACK war avoidance solution)
	should be noted as a WG contribution.

---

[tcpm] previous notes on tcp-secure-04

Attachment: signature.asc