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
- [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Fernando Gont
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Eddy, Wesley M. (GRC-RCN0)[VZ]
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt David Borman
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Anantha Ramaiah (ananth)
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Joe Touch
- Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt Ted Faber