Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt

On Thu, Aug 21, 2008 at 12:40:43PM -0500, David Borman wrote:
> 
> Wes and I would like to start the WG Last Call for:
> 
>  Title           : Improving TCP's Robustness to Blind In-Window  
> Attacks'
>  Author(s)       : A. Ramaiah, R. Stewart & M. Dalal
>  Filename        : draft-ietf-tcpm-tcpsecure-10.txt
>  Pages           : 27
>  Date            : July 9, 2008
>  Intended Status : Proposed Standard
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-10.txt
> 
> It is our understanding that all the feedback has been incorporated  
> into this latest version and that there are no known outstanding  
> issues with this document.
> 
> Please send feedback to the list, even if it is just a "yes, go ahead  
> and publish".
> 
> The WGLC will end on Friday, September 5, 2009.

Overall I think this is a good draft and should advance.  I have
comments, which I'll present in page order:

Probably the most technical comment I have is the objection to the
"There was no sound technical reasoning for choosing the Data mitigation
as MAY", which is on P15.

P2:
The 4-tuple is called a socket pair in 793.  Even if you don't want to
adopt that terminology, it's probably worth mentioning.  I also don't
like "RST, SYN or DATA segment."  These are TCP segments with the RST or
SYN flag set and I'd describe them that way.  ONce you've had a chance
to define "RST segment" as a segment with the RST bit set, you can use
the short form.

I'd delete "either" from "This can cause the connection to either abort
or possibly cause data corruption."  I'd consider deleting "possibly" as
well.

P4:

"The TCP spoofing attacks, which are seen in the Internet today," - I'd
say "The off-path TCP spoofing attacks".  We're still describing the
problem, so let's be clear.  The next paragraph starts with a
description of the attacks this draft cares about, but until then be
precise.

"... making the odds of guessing correctly the 4-tuple..."  I think
"correctly guessing" is more common.  I'd actually suggest "... making
it much easier to guess the 4-tuple."

P5:

"One of the important things to note is that, for the attack to succeed
the RST..." -> delete the comma.

"A slight enhancement to the TCP's segment processing" -> delete the
"the".

P6:

"Every application has control of a number of factors that effect
drastically the probability of a successful spoofing attack."  You mean
"affect" not "effect".  I'd also use "drastically affect" rather than
"affect drastically".  The order of the adverb is a matter of style,
using "affect" changes the meaning of the sentence to the one you
intend.

On the figures in the "To successfully inject a spoofed packet..."
paragraph:

1. Use parens, not [].
2. Finish the math.  If you want to say 1/2 * 2^32 = 2^31 rather than
just dropping 2^31 that's fine, but we're going to be comparing these
requirements, so don't hide the results.  "[SITW] shows that the mean
number of tries needed to inject a RST command is (2^31/window) rather
than the 2^31 assumed before."

P7:

"...please refer to draft [RFC4953]" -> "please refer to [RFC4953]"
It's not a draft any more.

P8:

Why use 1) and 2) and A), B), C)?  Pick one.

"The previous text, quoted from [RFC0793], woould thus become:" -> That
sounds a lot like we're mandating the change rather than it being a
SHOULD.  Do we really need this restatement at all?

P13:

"...so the chances of successfully injecting data into a connection are
1 in (2^32/RCV.WND *2)."  In describing the RST attacks, we spoke in
terms of mean number of tries, and I'd be consistent here.  Similarly
I'd do the math all the way: " ... so the mean number of tries needed to
inject data successfully is  2*2^32/RWND = 2^33/RCV.WND."

This section used a) and b) instead of either A) and B) or 1) and 2)
(used earlier for the same purpose). Again, pick one.

P15:

"There was no strong technical reasoning for choosing the Data mitigation
as MAY."
First, everywhere else the you use "DATA", I'd use it here.

Second, if I failed to make the case before, let me make it now.  The
DATA injection is 4 times less likely than either the RST or the SYN
attacks (2^33 vs 2^31) and may be visible to the application as garbled
data.  If the attack is visible an application can gracefully
terminate the connection and re-establish the conversation - unlike the
RST/SYN cases.  As the attack is harder to carry out, and a successful
attack may be easier to recover from, I recommend a MAY.  I don't care
if you repeat that argument, but I do believe that there are sound
technical reasons for the MAY, and I'd like to see the sentence that
started this comment elided.

P16:

"Currently there is no known bad behavior that can be attributed to the
lack of ACK throttling, but as a general principle, if ever invoked,
something incorrect is occurring and such a mechanism will act as a
failsafe that protects both the sender and the network." -> "While we
have not encountered a case where the lack of ACK throttling can be
exploited, as a fail-safe mechanism we recommend its use.  An
implementation may take an excessive number of invocations of the
throttling mechanism as an indication that network conditions are
unusual or hostile."

P18:

"...the middle box design does not comply to [RFC0793]."   No middlebox
complies with RFC793; I suggest "...the middle box is generating packets
a conformant TCP endpoint would not generate."

P22:

"ACK throttling was introduced to this document bt combining the
suggestions from the tcpm working group."  That seems out of place in
"Contributors".  That section is to acknowledge the efforts of
individuals.

P24:

Why are RFC's 4302 and 4303 normative?  And if they are why isn't
RFC2385?  They're all referred to as possible mitigations.  My
preference is making 4302 and 4303 non-normative, but it's very likely
that I'm missing a rule here.

Quotation marks are misplaced on the Medina05 reference.

The NISCC reference lacks a date.

P25:

Quotation marks are misplaced on the SITW reference.

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