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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 4C2BF28B797; Fri, 19 Sep 2008 10:13:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4A8C3A6B69 for <>; Fri, 19 Sep 2008 10:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hhaxFGBLolcs for <>; Fri, 19 Sep 2008 10:13:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C3923A6B5F for <>; Fri, 19 Sep 2008 10:13:46 -0700 (PDT)
Received: from [] ( []) by (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: <>
Date: Fri, 19 Sep 2008 10:14:40 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: David Borman <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,,, "Anantha Ramaiah (ananth)" <>, Ted Faber <faber@ISI.EDU>
Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-tcpsecure-10.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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.


> 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
>>>>>> 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:
>>>>> " 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
>>>>>           PGP:
>>>>> Unexpected attachment on this mail? See
>>>> _______________________________________________
>>>> tcpm mailing list
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list