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

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Sun, 28 September 2008 21:04 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 5F23E3A6957; Sun, 28 Sep 2008 14:04:38 -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 3F2F63A6957 for <tcpm@core3.amsl.com>; Sun, 28 Sep 2008 14:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 IadFVzRUJ5aw for <tcpm@core3.amsl.com>; Sun, 28 Sep 2008 14:04:35 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D27CD3A6950 for <tcpm@ietf.org>; Sun, 28 Sep 2008 14:04:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,327,1220227200"; d="scan'208";a="164578401"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2008 21:04:53 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8SL4qE9021880; Sun, 28 Sep 2008 14:04:52 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8SL4qqn025397; Sun, 28 Sep 2008 21:04:52 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Sep 2008 14:04:52 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 28 Sep 2008 14:03:55 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5805DF4359@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <20080906013831.GD2074@zod.isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
Thread-Index: AckPxNDHT/KHDJV6Rk6HqbPQTpAjDQAwyaoQ
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>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Ted Faber" <faber@ISI.EDU>, "David Borman" <david.borman@windriver.com>
X-OriginalArrivalTime: 28 Sep 2008 21:04:52.0858 (UTC) FILETIME=[DA141DA0:01C921AD]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9431; t=1222635892; x=1223499892; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20WGLC=3A=20draft-ietf-tcpm-tcps ecure-10.txt |Sender:=20; bh=9x2K6ZTk+6zU9r5Re6iaxleCnE3Sao4ILSqXh8SSCaE=; b=emu898c3vMHZcIaeoWuN+yUkUTgSx3eXHuSDxB/7IMunMilHrDXxKN2wx1 WygHzb9LBkpvmrjxsk/Hh5hLR1o71uK2vk0T7Ehklthn78AQ/Qh7mfQ+yulc G62Tywh/jq;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: rrs@cisco.com, tcpm@ietf.org, "Mitesh Dalal \(mdalal\)" <mdalal@cisco.com>
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

Ted,
  Appreciate the detailed comments. Pl see inline responses.


> -----Original Message-----
> From: Ted Faber [mailto:faber@ISI.EDU] 
> Sent: Friday, September 05, 2008 6:39 PM
> To: David Borman
> Cc: tcpm@ietf.org; rrs@cisco.com; Mitesh Dalal (mdalal); 
> Anantha Ramaiah (ananth)
> Subject: 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.

Good point. Will do.

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

Makes sense. Will do.

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

Ok. 

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

Both points taken.

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

Cool. Will do.

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

Ok.

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

Ok.

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

Hmm.. I thought it was more clearer that way. 

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

Sure, it is good to be consistent. But the math which you depict above
seems incorrect to me. What was said earlier in the document is
(referenced from Watson's paper ) is :

============
   "[SITW] demonstrated that
   this assumption was incorrect and that instead of [1/2 * 2^32]
   packets (assuming a random distribution) [1/2 * (2^32/window)]
   packets is required.

   Substituting numbers into this formula we see that for a window size
   of 32,768, an average of 65,536 packets would need to be transmitted
   in order to "spoof" a TCP segment that would be acceptable to a TCP
   receiver.  A window size of 65,535 reduces this even further to
   32,768 packets.  At today's access bandwidths an attack of that size
   is feasible.

===============

So for data injection, this should become 2^32/RCV.WND. (i.e, [1/2 *
2^32 *2]/window )


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

Ok.

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

Sure.

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

Hmm.. It should be actually twice less likely 2^32 versus 2^31, based on
above.


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

I think the general understanding was that any malicious event
responsible for the connection to go down is a problem. So I am not sure
whether I can buy this argument. OTOH, if you are classifying the
strength based on how easy/difficuly it is to contruct the attack vector
and cause harm to the connection, and if that is what is the consensus,
then so be it. I can mention this in the document.

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

Your change looks elegant. Will do.

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

Ok.

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

Makes sense.. Good eye!

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

I am not sure about the rules here?  David/Wes what needs to be done
here ?

> 
> Quotation marks are misplaced on the Medina05 reference.

Ok.

> 
> The NISCC reference lacks a date.
> 
> P25:
> 
> Quotation marks are misplaced on the SITW reference.

This was put in long back.... I need to check.

I'll incorporate these comments along with others received in the next
(final, hopefully ?) version.

Once again, thanks for the detailed review.

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