Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
Joe Touch <touch@ISI.EDU> Fri, 19 September 2008 17:13 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 4C2BF28B797; Fri, 19 Sep 2008 10:13:48 -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 E4A8C3A6B69 for <tcpm@core3.amsl.com>; Fri, 19 Sep 2008 10:13:47 -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=[AWL=0.000, 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 hhaxFGBLolcs for <tcpm@core3.amsl.com>; Fri, 19 Sep 2008 10:13:46 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6C3923A6B5F for <tcpm@ietf.org>; Fri, 19 Sep 2008 10:13:46 -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 m8JHCctC010981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Sep 2008 10:12:40 -0700 (PDT)
Message-ID: <48D3DE00.4060307@isi.edu>
Date: Fri, 19 Sep 2008 10:14:40 -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> <48D3C90A.5050301@isi.edu> <0D2F6D02-8018-4684-B156-9ACC49D5B4E4@windriver.com>
In-Reply-To: <0D2F6D02-8018-4684-B156-9ACC49D5B4E4@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 David Borman wrote: > (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. Yes, we agreed on that, but that distinction is, AFAICT, unusual in the IETF. I.e., most people I talked to expected the component recommendations to reflect the overall context; they were extremely surprised at our view that a hierarchy of recommendations was how standards were written. I'd like to suggest we get advice on this matter from outside the WG, since this isn't an internal issue. Joe > > 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: > > 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 iD8DBQFI094AE5f5cImnZrsRAtw3AKCs7g9FCoAKb0DS9QCNRrRIEIKSjgCglgnl wsD07E8spIc9N5fh0w/Po1w= =lDym -----END PGP SIGNATURE----- _______________________________________________ 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