[tcpm] [Fwd: Re: tcpsecure]

[Randall Stewart <[e-mail]>]

These are Joes original comments to
V04 of tcp-secure...

 From which minor changes were made to make V05..


Joe, you might want to add more/or what have you...
possibly send text please :=0

R
-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

--- Begin Message ---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Randall Stewart wrote:
> Mark Allman wrote:
>>  
>> Randall-
>> Not sure if Touch caught you in Dallas, but when I sat and chatted with
>> him he had a bunch of pretty minor things flagged in tcpsecure.  He said
>> they weren't hugely technical, but should be fixed.  If you didn't chat
>> with him can you ping him?

FYI, here they are. It's minor in the sense that I see where the doc
could go now; the doc does need some substantial work, but the solution
doesn't (except w.r.t. one part; see 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.

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.

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.

- --






	
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEKtydE5f5cImnZrsRAmtsAKCs68nm0tYjtYM/6OuJFKrEpbN78ACg8cmr
WBNSI1GxpVS4xkdh7FM+qOQ=
=LA/R
-----END PGP SIGNATURE-----

--- End Message ---

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