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

[David Borman <[e-mail]>]

(WG chair hat off)

The SHOULD/MAY in the applicability statement is about who benefits  
most from tcpsecure, and in the rest of the document the MUST/SHOULD/ 
MAY are about implementing tcpsecure.  We (the WG) wanted the  
distinction in the applicability statement about which situations will  
benefit the most from tcpsecure.

So for this issue, I think the document is fine as is.

			-David Borman

On Sep 19, 2008, at 10:45 AM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> One issue I'd like to re-confirm: we have, in this document, a
> hierarchical use of the RFC2119 terms of MUST/SHOULD/MAY, i.e.:
>
> whole doc: SHOULD
> 	certain portions are listed as MUST
>
> i.e., "if SHOULD, then MUST..."
>
> This is, based on recent discussions I've had with others while
> explaining this off-list, an uncommon use of 2119 language AFAICT.
>
> It would be useful to get IESG guidance on this; if such use is  
> common,
> then the doc can be left in its current form. If its use is uncommon  
> but
> desired, then we need to explain the issue in some detail (i.e., a  
> whole
> paragraph called out as a section, IMO). If its use is not desired by
> the IESG, then we need to adjust the recommendations accordingly  
> (i.e.,
> all MUSTs would drop to SHOULDs).
>
> Joe
>
> David Borman wrote:
>> Hi,
>>
>> I haven't seen any response from the authors on Ted's message.  We  
>> are
>> well past the WGLC, but I would like the authors to address the  
>> issues
>> that Ted brings up, and submit a new version of the draft before we
>> pass this up to the IESG.  I haven't seen any other comments on this
>> draft, so we are assuming that everyone else is happy with this
>> version, after Ted's comments are addressed.
>>
>> Once there is a new version available addressing Ted's comments,  
>> we'll
>> pass this on to the IESG for publication as an RFC.  So, if anyone  
>> has
>> further comments and neglected to speak up, now is the time to do so!
>>
>> 			-David Borman & Wes Eddy
>> 			TCPM WG co-chairs
>>
>> On Sep 5, 2008, at 8:38 PM, Ted Faber wrote:
>>
>>> 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
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFI08kKE5f5cImnZrsRAuMoAJ43+3GJLSi5p7zEOkvLZtuzYfeV0gCg5x7N
> yqGeykNAk2sBFupRaFqmo3s=
> =VG60
> -----END PGP SIGNATURE-----

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