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

Joe Touch <touch@ISI.EDU> Fri, 19 September 2008 15:47 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB59A28C160; Fri, 19 Sep 2008 08:47:11 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CE628C114 for <tcpm@core3.amsl.com>; Fri, 19 Sep 2008 08:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zKMLoT5DjgN for <tcpm@core3.amsl.com>; Fri, 19 Sep 2008 08:47:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id CDC4728C160 for <tcpm@ietf.org>; Fri, 19 Sep 2008 08:47:04 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m8JFhDh3013916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Sep 2008 08:43:15 -0700 (PDT)
Message-ID: <48D3C90A.5050301@isi.edu>
Date: Fri, 19 Sep 2008 08:45:14 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: David Borman <david.borman@windriver.com>
References: <FE34F27F-8DDF-4C94-BC6E-E2ABF6000309@windriver.com> <B5A5E01F9387F4409E67604C0257C71E409513@NDJSEVS25A.ndc.nasa.gov> <24D2F5D3-93E7-4B64-BA96-2086F3E5754E@windriver.com> <20080906013831.GD2074@zod.isi.edu> <8B8A001A-CA85-407B-9F1A-0FB1D847C21C@windriver.com>
In-Reply-To: <8B8A001A-CA85-407B-9F1A-0FB1D847C21C@windriver.com>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, rrs@cisco.com, mdalal@cisco.com, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, Ted Faber <faber@ISI.EDU>
Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

-----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
> tcpm@ietf.org
> 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
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm