From hkchu@google.com Sat Aug 1 18:42:24 2009 Return-Path: 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 CE5583A68E9 for ; Sat, 1 Aug 2009 18:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.527 X-Spam-Level: X-Spam-Status: No, score=-101.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 lh4+nM1bpq12 for ; Sat, 1 Aug 2009 18:42:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id CB4BD3A68CC for ; Sat, 1 Aug 2009 18:42:23 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id n721gPAc010685 for ; Sat, 1 Aug 2009 18:42:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1249177345; bh=nzg0mJm6xrcHX6l5p3626QUpqM0=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=SOWB2GRRCcu1d8Rbv7 x70GqvKMfzfZwgw2tnTvv2qih7W3raR/bA/uyKYx6tZIwbgaaToAdOMIXz2yCnO+/qq w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=l4z8J51rl3dKJEY9GBTcaOTGq/a9QmagP8GaBm4PsyMgGJk4dL16h5IDb6NFHAy+E mFv277weuqFWhhzThqedg== Received: from yxe11 (yxe11.prod.google.com [10.190.2.11]) by wpaz33.hot.corp.google.com with ESMTP id n721gHac021103 for ; Sat, 1 Aug 2009 18:42:23 -0700 Received: by yxe11 with SMTP id 11so5242858yxe.3 for ; Sat, 01 Aug 2009 18:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.194.7 with SMTP id r7mr5989562anf.37.1249177337569; Sat, 01 Aug 2009 18:42:17 -0700 (PDT) In-Reply-To: <20090730192227.94B8C38CAEC@lawyers.icir.org> References: <20090730192227.94B8C38CAEC@lawyers.icir.org> Date: Sat, 1 Aug 2009 18:42:17 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Sun, 02 Aug 2009 01:42:24 -0000 [Sorry for the delay in response. I have been traveling...] Mark, On Thu, Jul 30, 2009 at 12:22 PM, Mark Allman wrote: > > Jerry- > > Let's put some (rough; based on your slides) numbers to things here ... > > =A0+ With an initRTO of 3sec your data suggests that 98% of the > =A0 =A0connections complete the 3WHS without retransmitting. =A0So, in 2%= of > =A0 =A0the connections we in fact lose a SYN. > > =A0+ Also, you note that something like 2% of the connections have an RTT > =A0 =A0longer than 1sec. =A0(And, I am making the assumption that is real= ly > > =A0 =A01sec and < 3sec.) > > =A0+ So, with an initRTO of 1sec we'd expect to see 2% of the connections > =A0 =A0experience loss, 2% of the connections have a long RTT and > =A0 =A0spuriously retransmit which leaves 96% of the connections Just > =A0 =A0Working. =A0(All in rough terms.) > > =A0+ Forget the 96%... they are good to go. =A0They got an RTT sample in > =A0 =A0the 3WHS and so presumably are working fine and no longer have to > =A0 =A0worry about the initRTO. > > =A0+ The 2% of the connections that experienced loss will have each saved > =A0 =A02sec in the 3WHS by using an initRTO of 1sec vs. 3sec. =A0So, if w= e > =A0 =A0care about X connections that's an aggregate savings of X*0.02*2se= c > =A0 =A0when using an initRTO of 1sec versus using an initRTO of 3sec (whi= ch > =A0 =A0yields 0sec of savings). > > =A0+ The connections that experienced loss will send data in the first > =A0 =A0RTT (say) and experience another 2% loss rate. =A0If we have a try= -2 > =A0 =A0approach and again use an initRTO of 1sec then this would save eac= h > =A0 =A0of these connections 2sec over my notion of reverting the initRTO = to > =A0 =A03sec. =A0In the aggregate the savings here is X*0.0*0.02*2sec. > > =A0+ So, now we have saved X*0.02*2sec + X*0.02*0.02*2sec with a try-2 > =A0 =A0approach vs. X*0.02*2sec with a try-1 approach. =A0For X=3D10K > =A0 =A0connections that is a difference of 8sec in the aggregate (400sec > =A0 =A0with try-1 vs. 408sec with try-2)---or, less than 1msec per > =A0 =A0connection on average if you'd like to do it that way. One thing I forgot to mention as part of why I felt try-1 may not be strong enough is that although our average global retransmission rate is estimated to be 1-2%, the rate distribution is far from even. It varies greatly betwe= en regions, time of the day..., etc. In some regions and during busy hours use= rs can experience retransmission rate > 5% (perhaps as high as 10% but again this is only my rough memory of how bad retransmissions can get). For those connections experiencing high loss rate try-1 just feels a bit weak. One ma= y argue for connections experiencing high loss rate, performance sucks anyway= . But I think it doesn't have to be so for web surfing employing short connections. Also in high loss condition pkt drop events may be more correlated where tr= y-2 can make a difference (I can try to collect some data to verify this conjecture). > > =A0+ Then there are the spurious RTOs caused by lowering the initRTO to > =A0 =A01sec. =A0We'll have 2% of those in the 3WHS. =A0The problem is tha= t > =A0 =A0keeping the initRTO at 1sec **ensures** a spurious retransmit in t= he > =A0 =A0first RTT of data transfer, too. =A0So, the cwnd will be reduced t= o an > =A0 =A0MSS, no RTT sample will be taken again, linear increase will be > =A0 =A0forced upon the connection, etc. As I mentioned in my previous email the try-N can diverge into different flavors. The simplest one (also one I had in mind) is to just limit its application = on SYN/SYN-ACK pkts. For that flavor there is no worry about it triggering false congestion avoidance. There is indeed another plus for the try-1 scheme over a try-N scheme where N > 2 though - the latter in some scenario can cause enough dupack (i.e., 3= ) to trigger unnecessary congestion avoidance (I think). > > =A0+ (Note, I am ignoring connections that use timestamps. =A0Connections > =A0 =A0that successfully use timestamps will have an RTT sample from the > =A0 =A03WHS and therefore we don't have to worry about the initRTO > =A0 =A0further.) So perhaps try-1 is indeed good enough - most of the server stacks have TS enabled by default anyway (with the exception of Windows servers that I'= m not sure) so we may have been arguing over the corner of another corner case :)= . > > To me the tradeoff is clearly in favor of try-1. =A0For the advantage of = a > *tiny* time savings to the 0.02*0.02 of connections that experience loss > in both the 3WHS and the initial window of data (i.e., what try-2 would > help) you pay by dooming 0.02 of the connections (that now work fine, > BTW) to no exponential ramp up. =A0That might be a tradeoff you are > personally willing to make---i.e., to sacrifice one type of connection > in favor of another. =A0But, I don't see that as a good tradeoff for the > standards to make. See above. I was more of trying to let only SYN/SYN-ACK have more shots. Also the loss distribution is far from even so the 0.02*0.02 calcuation may not be applicable. > > Also, note, your scheme of counting SYNs is not overly complicated and > does not have overly onerous state requirements. =A0I didn't mean to > indicate either of those. =A0However, it isn't terribly robust either and > I am not ultimately sure how it'd play out. =A0So, say a connection has a > 2sec RTT (works with others, too): > > =A00.0 xmit SYN > =A01.0 RTO (=3D=3D1sec), rexmit SYN > =A02.0 rec SYN+ACK (from original transmit) / send ACK / send DATA > =A03.0 resend DATA > =A03.0 rec SYN+ACK (from retransmit) > > Those last two events represent a race condition. =A0I.e., in this case, > we hope we get the SYN+ACK before we resend the data because then we can > use your scheme to revert to an initRTO of 3sec. =A0But, we might get it > in the order given above. =A0And, we might not get that packet at all. > So, it might work and it might not work. =A0But, the cost of not using it > (possibly saving X*0.02*0.02*2sec) is so small that it seems like > needless complication to me. Again see above. I was more thinking about the consecutive-pkt case where o= ne simply count how many times a SYN/SYN-ACK has been retransmitted. (All stack implementations must be counting this anyway in order to decide when = to give up.) > > Now, there is something you can do here... If you wanted to take the > reception of the SYN+ACK and compare that to the *earliest* SYN > transmission and use that as an RTT sample and then use that to seed the > RTO estimator then fine. =A0I.e., in this case that'd (correctly) see an > RTT of 2sec. =A0And, if the original SYN was lost then the returning > SYN+ACK would yield an RTT sample of 3sec. =A0I.e., using this scheme > might overestimate the RTT, but you won't underestimate it. =A0If that is > less than 3sec you'd be better off for the first window of data and > you'd be protected against spurious retransmits (to the best of the > standard RTO estimator's abilities) by using a conservative RTT sample. Sounds like another good idea. Will give it more thoughts when I go back to office in a week. Jerry > > allman > > > > From mallman@icir.org Mon Aug 3 05:07:33 2009 Return-Path: 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 879123A6BEE for ; Mon, 3 Aug 2009 05:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 fNyJVVOGruDU for ; Mon, 3 Aug 2009 05:07:32 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id C8E913A6A42 for ; Mon, 3 Aug 2009 05:07:32 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n73C7W6t000546; Mon, 3 Aug 2009 05:07:32 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id F38483BF796A; Mon, 3 Aug 2009 08:07:23 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2F0DD39CCA1; Mon, 3 Aug 2009 08:07:26 -0400 (EDT) To: Jerry Chu From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Streets of Philadelphia MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma54011-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 03 Aug 2009 08:07:26 -0400 Sender: mallman@icir.org Message-Id: <20090803120726.2F0DD39CCA1@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 12:07:33 -0000 ----------ma54011-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > the rate distribution is far from even. Right. That's clear from both your slides and a ton of previous empirical observation. I was merely using an average of sorts from your slides as an illustration. A couple more things: - Even if the loss rate is 10% that's .1*.1 or 1% instead of .02*.02. So, we're not helping a stunningly large number of connections. - Moreover, if we're talking about correlated loss rates across RTOs then I think you're arguing for aggressiveness in the face of persistent congestion to help a quite small fraction of connections. That doesn't quite seem useful. > As I mentioned in my previous email the try-N can diverge into > different flavors. It seems that we don't quite have the same notion of what we're talking about. Could you sketch something concrete in an email to the list? Thanks! allman ----------ma54011-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkp20v0ACgkQWyrrWs4yIs72AwCfbxWI/JE70ID/FdIfwu0Wy+Mo EAcAoIfQcwc/BlwkS2N+D2IQPiU58tKC =13vs -----END PGP SIGNATURE----- ----------ma54011-1-- From andrew.knutsen@bluecoat.com Mon Aug 3 14:54:35 2009 Return-Path: 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 EC2DD3A6862 for ; Mon, 3 Aug 2009 14:54:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): Subject: ... Option for Transparent Middlebox Discovery\n \n 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 eD5n7u3fkREn for ; Mon, 3 Aug 2009 14:54:34 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 1D83B3A69F0 for ; Mon, 3 Aug 2009 14:53:39 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n73Lrfnt017752 for ; Mon, 3 Aug 2009 14:53:41 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 14:53:36 -0700 Message-ID: <4A775C60.7030204@bluecoat.com> Date: Mon, 03 Aug 2009 14:53:36 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Aug 2009 21:53:36.0466 (UTC) FILETIME=[DA540B20:01CA1484] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , Wei Jen Yeh Subject: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Mon, 03 Aug 2009 21:54:35 -0000 We've just posted . The intended category is Informational. Current technology uses several experimental and unassigned option kinds for this function, by different vendors. This draft represents an effort to allow use of a single, standard, flexible option. We appreciate your attention, so we can begin moving toward an assigned option kind. Abstract This document describes a TCP option intended to facilitate transparent detection of middleboxes (or services playing that role) along the path of a TCP connection as the connection is made. The option has no effect if an appropriate middlebox is not on the path. From rbonica@juniper.net Mon Aug 3 16:30:00 2009 Return-Path: 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 F1B233A6AE7; Mon, 3 Aug 2009 16:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WlmgU-S1bSSj; Mon, 3 Aug 2009 16:29:59 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with ESMTP id 01C833A6B1B; Mon, 3 Aug 2009 16:29:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSndyuzbrAd+kszkfemHGf+nimcFHNg84@postini.com; Mon, 03 Aug 2009 16:29:07 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 3 Aug 2009 16:26:26 -0700 Received: from [172.28.134.30] (172.28.134.30) by p-emfe02-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 3 Aug 2009 19:26:26 -0400 Message-ID: <4A777220.3070507@juniper.net> Date: Mon, 3 Aug 2009 19:26:24 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Mon, 03 Aug 2009 23:30:00 -0000 Folks, RFC 2026 defines a HISTORIC RFC as follows: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. I think that TCP-MD5 fits that definition. The HISTORIC nomenclature doesn't mean that there is no longer an installed base. It just means that something more recent is available. Ron Iljitsch van Beijnum wrote: > On 29 jul 2009, at 12:48, Lars Eggert wrote: > >> at the meeting, the question came up which status TCP-MD5 should >> have after TCP-AO is published. Specifically, whether it should be >> obsoleted by TCP-AO and/or if it should be reclassified as Historic. > > First of all, I'd like to see some operational experience with TCP-AO. > Don't throw away your old shoes until you know whether the new ones fit. > > Second, it's not like TCP-MD5 isn't being used. As such, "historic" > wouldn't apply. "Deprecated", maybe. > > Third, why is it exactly that we can't simply move from MD5 to IPsec > to protect BGP sessions?? > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From iljitsch@muada.com Tue Aug 4 08:56:16 2009 Return-Path: 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 798233A6828; Tue, 4 Aug 2009 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, 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 4hwnfGuDYceg; Tue, 4 Aug 2009 08:56:15 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6113A67E7; Tue, 4 Aug 2009 08:56:15 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n74FtsZD043640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2009 17:55:54 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> From: Iljitsch van Beijnum To: Ron Bonica In-Reply-To: <4A777220.3070507@juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 17:56:11 +0200 References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> <4A777220.3070507@juniper.net> X-Mailer: Apple Mail (2.935.3) Cc: "tcpm@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 15:56:16 -0000 On 4 aug 2009, at 1:26, Ron Bonica wrote: > The HISTORIC nomenclature doesn't mean that there is no longer an > installed base. It just means that something more recent is available. I still think it's premature to change the status of RFC 2385 before a replacement is widely available operationally. And yes, that can take a decade, see 32-bit AS numbers. Iljitsch From Donald.Smith@qwest.com Tue Aug 4 09:26:52 2009 Return-Path: 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 B1D4F3A6CDC; Tue, 4 Aug 2009 09:26:52 -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 gqUzZEuZEbQZ; Tue, 4 Aug 2009 09:26:51 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id B34F13A6A9F; Tue, 4 Aug 2009 09:26:51 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.0/8.14.0) with ESMTP id n74GQrhS009868; Tue, 4 Aug 2009 10:26:53 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.0/8.14.0) with ESMTP id n74GQkJH026698; Tue, 4 Aug 2009 11:26:48 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 4 Aug 2009 10:26:46 -0600 From: "Smith, Donald" To: "'Iljitsch van Beijnum'" , "'Ron Bonica'" Date: Tue, 4 Aug 2009 10:26:45 -0600 Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication Thread-Index: AcoVHCcZ8JwlPIP3Qw6VTNwcE8WB5AAAMtNQ Message-ID: References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net> <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> In-Reply-To: <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm@ietf.org'" , "'iesg@ietf.org IESG'" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 16:26:52 -0000 I believe the rfc2385 should be modified. http://www.ietf.org/rfc/rfc2385.txt 4.1 A connectionless reset will be ignored by the receiver of the reset, since the originator of that reset does not know the key, and so cannot generate the proper signature for the segment. This means, for example, that connection attempts by a TCP which is generating signatures to a port with no listener will time out instead of being refused. Similarly, resets generated by a TCP in response to segments sent on a stale connection will also be ignored. Operationally this can be a problem since resets help BGP recover quickly from peer crashes. An authenticationless reset MUST be ignored by the receiver of the reset. The originator of that reset knows the key associated with their bgp neighb= or and SHOULD use the key to generate=20 an authenticated reset if that session has been terminated for some reason. This means, for example, that connection attempts by a TCP which is generat= ing signatures to a port with no listener could be refused with a authenticated= reset instead of being timed out. Operationally this would be an improvement over the current standard since = resets help BGP recover quickly from peer crashes. The current rfc compliant behavior doesn't make authenticated reset work, i= t makes ALL RESETS fail. We could just as well have a flag that says ignore resets for bgp. It would= have the same value as today's rfc compliant router implementations. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Iljitsch van Beijnum > Sent: Tuesday, August 04, 2009 9:56 AM > To: Ron Bonica > Cc: tcpm@ietf.org; iesg@ietf.org IESG > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication >=20 > On 4 aug 2009, at 1:26, Ron Bonica wrote: >=20 > > The HISTORIC nomenclature doesn't mean that there is no longer an > > installed base. It just means that something more recent is=20 > available. >=20 > I still think it's premature to change the status of RFC 2385=20 > before a =20 > replacement is widely available operationally. >=20 > And yes, that can take a decade, see 32-bit AS numbers. >=20 > Iljitsch > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > = From touch@ISI.EDU Tue Aug 4 09:37:15 2009 Return-Path: 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 B0A433A6452; Tue, 4 Aug 2009 09:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 RRLEs6pUX9k9; Tue, 4 Aug 2009 09:37:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C9CBF3A6F36; Tue, 4 Aug 2009 09:37:14 -0700 (PDT) Received: from [75.213.61.46] (46.sub-75-213-61.myvzw.com [75.213.61.46]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n74Ga42e004955; Tue, 4 Aug 2009 09:36:07 -0700 (PDT) Message-ID: <4A786374.5010705@isi.edu> Date: Tue, 04 Aug 2009 09:36:04 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lars Eggert References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> In-Reply-To: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 16:37:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Eggert wrote: > Hi, > > at the meeting, the question came up which status TCP-MD5 should have > after TCP-AO is published. Specifically, whether it should be obsoleted > by TCP-AO and/or if it should be reclassified as Historic. A related > issue I came across while trying to form an opinion of the former issue > is if the publication of TCP-AO means that we can lift the Standards > Variance for TCP-MD5 introduced by RFC4728. (I'm CC'ing the IESG because > of this latter point, because that Standards Variance came from the SEC > and RTG areas.) I think you mean RFC4278. Because TCP-AO is intended to replace TCP MD5, and because TCP MD5 is considered less than desirable, it seems reasonable to both put forward AO as draft-standard and declare TCP MD5 historic at the same time. If TCP MD5 were safer, we might consider leaving it as-is, but at this point I think we're really trying to push the deployed both away from TCP MD5 and towards AO, so both steps seem useful together right now. And although, in some sense, all new protocols might be sent out first as experimental, that is not the default process for standards developed in the IETF per se, nor is it useful in this particular case, IMO. There is no experiment desired or intended. There are no backward compatibility issues, nor are there interaction issues with other protocols. The only current component for which there is any question is NAT support, which might be an experimental extension if published separately. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4Y3QACgkQE5f5cImnZrux1gCeI8C76UkJZTNFCE5na6ynM/GV oi8AmgII1uU7l+NNehoFCHX5ZsyoyMx0 =Rs/T -----END PGP SIGNATURE----- From chaks@cisco.com Tue Aug 4 09:49:40 2009 Return-Path: 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 506273A68BE; Tue, 4 Aug 2009 09:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WHfTQOxupQiv; Tue, 4 Aug 2009 09:49:39 -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 4D86728C375; Tue, 4 Aug 2009 09:49:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB8DeEqrR7O6/2dsb2JhbAC9D4gpj3gFhBg X-IronPort-AV: E=Sophos;i="4.43,322,1246838400"; d="scan'208";a="360210973" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 16:48:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n74GmiZZ010561; Tue, 4 Aug 2009 09:48:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n74GmhBk028333; Tue, 4 Aug 2009 16:48:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 09:48:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 09:48:42 -0700 Message-ID: <3C50EF6BFB256E448286057DABC00CBE0834DB40@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication Thread-Index: AcoVHCcZ8JwlPIP3Qw6VTNwcE8WB5AAAMtNQAAFy8wA= References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net><75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> From: "Chaks Chigurupati (chaks)" To: "Smith, Donald" , "Iljitsch van Beijnum" , "Ron Bonica" X-OriginalArrivalTime: 04 Aug 2009 16:48:43.0642 (UTC) FILETIME=[6D5E5DA0:01CA1523] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3588; t=1249404524; x=1250268524; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=chaks@cisco.com; z=From:=20=22Chaks=20Chigurupati=20(chaks)=22=20 |Subject:=20RE=3A=20[tcpm]=20status=20of=20TCP-MD5=20after= 20TCP-AO=20publication |Sender:=20; bh=ZYPonULPIQKDv2KYHSHqMqGxZHANcvN2Jcc1qUuk6QI=; b=OWfNMd46lsqbwE/0RO7FInh0morVH/snPGfWupztRfpvjjsQHmt93zOTy/ 0WkPh+wW38nnvfc7TLOaYR8TS+SGsIBWt8vgyN6k0xFaQdHyXQhauWAbylAU 7rnzErFaA+; Authentication-Results: sj-dkim-2; header.From=chaks@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 16:49:40 -0000 One minor comment - Please see inline for [Chaks] > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Smith, Donald > Sent: Tuesday, August 04, 2009 9:27 AM > To: 'Iljitsch van Beijnum'; 'Ron Bonica' > Cc: 'tcpm@ietf.org'; 'iesg@ietf.org IESG' > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication >=20 > I believe the rfc2385 should be modified. >=20 > http://www.ietf.org/rfc/rfc2385.txt > 4.1 > A connectionless reset will be ignored by the receiver of=20 > the reset, > since the originator of that reset does not know the key, and so > cannot generate the proper signature for the segment. This means, > for example, that connection attempts by a TCP which is generating > signatures to a port with no listener will time out=20 > instead of being > refused. Similarly, resets generated by a TCP in response to > segments sent on a stale connection will also be ignored. > Operationally this can be a problem since resets help BGP recover > quickly from peer crashes. >=20 >=20 >=20 > An authenticationless reset MUST be ignored by the receiver=20 > of the reset. > The originator of that reset knows the key associated with=20 > their bgp neighbor and SHOULD use the key to generate an=20 > authenticated reset if that session has been terminated for=20 > some reason. > This means, for example, that connection attempts by a TCP=20 > which is generating signatures to a port with no listener=20 > could be refused with a authenticated reset instead of being=20 > timed out. [Chaks] If the listener is not around, it is very likely that the listener has withdrawn from TCP the knowledge about the=20 various keys associcated with the neighbors. OR, TCP itself might have purged that info as such info is usually "attached" to the listen socket. So, it may not be possible for TCP to generate an authenticated reset in the absence of a listener. Chaks > Operationally this would be an improvement over the current=20 > standard since resets help BGP recover quickly from peer crashes. >=20 >=20 >=20 > The current rfc compliant behavior doesn't make authenticated=20 > reset work, it makes ALL RESETS fail. > We could just as well have a flag that says ignore resets for=20 > bgp. It would have the same value as today's rfc compliant=20 > router implementations. >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com gcia =20 >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > Behalf Of Iljitsch van Beijnum > > Sent: Tuesday, August 04, 2009 9:56 AM > > To: Ron Bonica > > Cc: tcpm@ietf.org; iesg@ietf.org IESG > > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication > >=20 > > On 4 aug 2009, at 1:26, Ron Bonica wrote: > >=20 > > > The HISTORIC nomenclature doesn't mean that there is no longer an > > > installed base. It just means that something more recent is=20 > > available. > >=20 > > I still think it's premature to change the status of RFC 2385=20 > > before a =20 > > replacement is widely available operationally. > >=20 > > And yes, that can take a decade, see 32-bit AS numbers. > >=20 > > Iljitsch > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From Donald.Smith@qwest.com Tue Aug 4 10:20:41 2009 Return-Path: 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 57A993A682A; Tue, 4 Aug 2009 10:20:41 -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 90rOz4OcRE2J; Tue, 4 Aug 2009 10:20:40 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 52FF93A67F8; Tue, 4 Aug 2009 10:20:40 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by suomp64i.qwest.com (8.14.0/8.14.0) with ESMTP id n74HKfbS015684; Tue, 4 Aug 2009 12:20:41 -0500 (CDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.0/8.14.0) with ESMTP id n74HKZq7027483; Tue, 4 Aug 2009 11:20:35 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 4 Aug 2009 11:20:35 -0600 From: "Smith, Donald" To: "'Chaks Chigurupati (chaks)'" , "'Iljitsch van Beijnum'" , "'Ron Bonica'" Date: Tue, 4 Aug 2009 11:20:34 -0600 Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication Thread-Index: AcoVHCcZ8JwlPIP3Qw6VTNwcE8WB5AAAMtNQAAFy8wAAAM/DkA== Message-ID: References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net><75E968CA-1D9 A-40BD-9C3E-534518B13BCF@muada.com> <3C50EF6BFB256E448286057DABC00CBE0834DB40@xmb-sjc-214.amer.cisco.com> In-Reply-To: <3C50EF6BFB256E448286057DABC00CBE0834DB40@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'tcpm@ietf.org'" , "'iesg@ietf.org'" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 17:20:41 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia =20 > -----Original Message----- > From: Chaks Chigurupati (chaks) [mailto:chaks@cisco.com]=20 > Sent: Tuesday, August 04, 2009 10:49 AM > To: Smith, Donald; Iljitsch van Beijnum; Ron Bonica > Cc: tcpm@ietf.org; iesg@ietf.org > Subject: RE: [tcpm] status of TCP-MD5 after TCP-AO publication >=20 > One minor comment - Please see inline for [Chaks] >=20 > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > Behalf Of Smith, Donald > > Sent: Tuesday, August 04, 2009 9:27 AM > > To: 'Iljitsch van Beijnum'; 'Ron Bonica' > > Cc: 'tcpm@ietf.org'; 'iesg@ietf.org IESG' > > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication > >=20 > > I believe the rfc2385 should be modified. > >=20 > > http://www.ietf.org/rfc/rfc2385.txt > > 4.1 > > A connectionless reset will be ignored by the receiver of=20 > > the reset, > > since the originator of that reset does not know the key, and so > > cannot generate the proper signature for the segment. =20 > This means, > > for example, that connection attempts by a TCP which is=20 > generating > > signatures to a port with no listener will time out=20 > > instead of being > > refused. Similarly, resets generated by a TCP in response to > > segments sent on a stale connection will also be ignored. > > Operationally this can be a problem since resets help BGP recover > > quickly from peer crashes. > >=20 > >=20 > >=20 > > An authenticationless reset MUST be ignored by the receiver=20 > > of the reset. > > The originator of that reset knows the key associated with=20 > > their bgp neighbor and SHOULD use the key to generate an=20 > > authenticated reset if that session has been terminated for=20 > > some reason. > > This means, for example, that connection attempts by a TCP=20 > > which is generating signatures to a port with no listener=20 > > could be refused with a authenticated reset instead of being=20 > > timed out. >=20 > [Chaks] If the listener is not around, it is very likely that the > listener has withdrawn from TCP the knowledge about the=20 > various keys associcated with the neighbors. OR, TCP itself might have > purged that info as such info is usually "attached" to the listen > socket. So, it may not be possible for TCP to generate an=20 > authenticated > reset in the absence of a listener. In ever implementation I have seen there is a shared secret in the BGP conf= iguration. It might mean "searching" the bgp configuration to find the neighbor's rout= e ID and grab the shared secret associated with that router ID but that plu= s the incoming packet information (src_port, dst_port, sequence_numbers...)= is enough to provide an authenticated reset.=20 One issue here is that the reset would probably not be generated by the asi= c on the line card as it is in many cases today. So this would probably lea= d to a hit on to the cpu or npu (slow path). Some routers ignore authentica= ted resets which per the current version of the rfc can be viewed as rfc co= mpliant:( >=20 > Chaks >=20 > > Operationally this would be an improvement over the current=20 > > standard since resets help BGP recover quickly from peer crashes. > >=20 > >=20 > >=20 > > The current rfc compliant behavior doesn't make authenticated=20 > > reset work, it makes ALL RESETS fail. > > We could just as well have a flag that says ignore resets for=20 > > bgp. It would have the same value as today's rfc compliant=20 > > router implementations. > >=20 > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > Donald.Smith@qwest.com gcia =20 > >=20 > > > -----Original Message----- > > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > > Behalf Of Iljitsch van Beijnum > > > Sent: Tuesday, August 04, 2009 9:56 AM > > > To: Ron Bonica > > > Cc: tcpm@ietf.org; iesg@ietf.org IESG > > > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication > > >=20 > > > On 4 aug 2009, at 1:26, Ron Bonica wrote: > > >=20 > > > > The HISTORIC nomenclature doesn't mean that there is no=20 > longer an > > > > installed base. It just means that something more recent is=20 > > > available. > > >=20 > > > I still think it's premature to change the status of RFC 2385=20 > > > before a =20 > > > replacement is widely available operationally. > > >=20 > > > And yes, that can take a decade, see 32-bit AS numbers. > > >=20 > > > Iljitsch > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > >=20 > = From chaks@cisco.com Tue Aug 4 10:28:03 2009 Return-Path: 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 073703A6FB7; Tue, 4 Aug 2009 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.605 X-Spam-Level: X-Spam-Status: No, score=-4.605 tagged_above=-999 required=5 tests=[AWL=-1.994, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 xldHDJW759yi; Tue, 4 Aug 2009 10:28:01 -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 CBEA93A6C7C; Tue, 4 Aug 2009 10:28:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH8MeEqrR7PE/2dsb2JhbAC8eYgpj3gFhBiBTw X-IronPort-AV: E=Sophos;i="4.43,322,1246838400"; d="scan'208";a="360240453" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Aug 2009 17:28:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n74HS4Os016079; Tue, 4 Aug 2009 10:28:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n74HS4WK013945; Tue, 4 Aug 2009 17:28:04 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Aug 2009 10:28:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 10:28:03 -0700 Message-ID: <3C50EF6BFB256E448286057DABC00CBE0834DB8A@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication Thread-Index: AcoVHCcZ8JwlPIP3Qw6VTNwcE8WB5AAAMtNQAAFy8wAAAM/DkAAAkyog References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net><75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> <3C50EF6BFB256E448286057DABC00CBE0834DB40@xmb-sjc-214.amer.cisco.com> From: "Chaks Chigurupati (chaks)" To: "Smith, Donald" , "Iljitsch van Beijnum" , "Ron Bonica" X-OriginalArrivalTime: 04 Aug 2009 17:28:04.0184 (UTC) FILETIME=[EC5C7D80:01CA1528] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5954; t=1249406884; x=1250270884; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=chaks@cisco.com; z=From:=20=22Chaks=20Chigurupati=20(chaks)=22=20 |Subject:=20RE=3A=20[tcpm]=20status=20of=20TCP-MD5=20after= 20TCP-AO=20publication |Sender:=20; bh=qs7FKgR7WmjEQbar+hUTGXj0SMuGpJH9dEpySnup4oI=; b=fOc8pY33A/IQ2O5q3gL3nIO0eDK5PFlkNQNJ/ahe5CGOV8xF+BwpDHMrbG PojoL1nV3tfcTFNUxaee1ZLByG9miCK53oqF3DV+k6J6MEv1qhABSMkk4eWy B1haMsQGjV; Authentication-Results: sj-dkim-4; header.From=chaks@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Tue, 04 Aug 2009 17:28:03 -0000 =20 > -----Original Message----- > From: Smith, Donald [mailto:Donald.Smith@qwest.com]=20 > Sent: Tuesday, August 04, 2009 10:21 AM > To: Chaks Chigurupati (chaks); 'Iljitsch van Beijnum'; 'Ron Bonica' > Cc: 'tcpm@ietf.org'; 'iesg@ietf.org' > Subject: RE: [tcpm] status of TCP-MD5 after TCP-AO publication >=20 >=20 >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com gcia =20 >=20 > > -----Original Message----- > > From: Chaks Chigurupati (chaks) [mailto:chaks@cisco.com] > > Sent: Tuesday, August 04, 2009 10:49 AM > > To: Smith, Donald; Iljitsch van Beijnum; Ron Bonica > > Cc: tcpm@ietf.org; iesg@ietf.org > > Subject: RE: [tcpm] status of TCP-MD5 after TCP-AO publication > >=20 > > One minor comment - Please see inline for [Chaks] > >=20 > > > -----Original Message----- > > > From: tcpm-bounces@ietf.org=20 > [mailto:tcpm-bounces@ietf.org] On Behalf=20 > > > Of Smith, Donald > > > Sent: Tuesday, August 04, 2009 9:27 AM > > > To: 'Iljitsch van Beijnum'; 'Ron Bonica' > > > Cc: 'tcpm@ietf.org'; 'iesg@ietf.org IESG' > > > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication > > >=20 > > > I believe the rfc2385 should be modified. > > >=20 > > > http://www.ietf.org/rfc/rfc2385.txt > > > 4.1 > > > A connectionless reset will be ignored by the receiver of the=20 > > > reset, > > > since the originator of that reset does not know the=20 > key, and so > > > cannot generate the proper signature for the segment. =20 > > This means, > > > for example, that connection attempts by a TCP which is > > generating > > > signatures to a port with no listener will time out instead of=20 > > > being > > > refused. Similarly, resets generated by a TCP in response to > > > segments sent on a stale connection will also be ignored. > > > Operationally this can be a problem since resets help=20 > BGP recover > > > quickly from peer crashes. > > >=20 > > >=20 > > >=20 > > > An authenticationless reset MUST be ignored by the=20 > receiver of the=20 > > > reset. > > > The originator of that reset knows the key associated=20 > with their bgp=20 > > > neighbor and SHOULD use the key to generate an=20 > authenticated reset=20 > > > if that session has been terminated for some reason. > > > This means, for example, that connection attempts by a=20 > TCP which is=20 > > > generating signatures to a port with no listener could be refused=20 > > > with a authenticated reset instead of being timed out. > >=20 > > [Chaks] If the listener is not around, it is very likely that the=20 > > listener has withdrawn from TCP the knowledge about the=20 > various keys=20 > > associcated with the neighbors. OR, TCP itself might have=20 > purged that=20 > > info as such info is usually "attached" to the listen=20 > socket. So, it=20 > > may not be possible for TCP to generate an authenticated=20 > reset in the=20 > > absence of a listener. >=20 > In ever implementation I have seen there is a shared secret=20 > in the BGP configuration. > It might mean "searching" the bgp configuration to find the=20 > neighbor's route ID and grab the shared secret associated=20 > with that router ID but that plus the incoming packet=20 > information (src_port, dst_port, sequence_numbers...) is=20 > enough to provide an authenticated reset.=20 [Chaks2] My comment was based on the implementations that I know of. Ideally, you don't want TCP code to be aware of BGP or LDP configuration whatsoever. You would expect the BGP and LDP processes to make these neighbor specific passwords available to TCP via a setsockopt() on the listen socket. If the listen socket goes away, so do these passwords as far as TCP is concerned. Chaks >=20 > One issue here is that the reset would probably not be=20 > generated by the asic on the line card as it is in many cases=20 > today. So this would probably lead to a hit on to the cpu or=20 > npu (slow path). Some routers ignore authenticated resets=20 > which per the current version of the rfc can be viewed as rfc=20 > compliant:( >=20 >=20 > >=20 > > Chaks > >=20 > > > Operationally this would be an improvement over the=20 > current standard=20 > > > since resets help BGP recover quickly from peer crashes. > > >=20 > > >=20 > > >=20 > > > The current rfc compliant behavior doesn't make=20 > authenticated reset=20 > > > work, it makes ALL RESETS fail. > > > We could just as well have a flag that says ignore resets=20 > for bgp.=20 > > > It would have the same value as today's rfc compliant router=20 > > > implementations. > > >=20 > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > > Donald.Smith@qwest.com gcia =20 > > >=20 > > > > -----Original Message----- > > > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > > > > Behalf Of Iljitsch van Beijnum > > > > Sent: Tuesday, August 04, 2009 9:56 AM > > > > To: Ron Bonica > > > > Cc: tcpm@ietf.org; iesg@ietf.org IESG > > > > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication > > > >=20 > > > > On 4 aug 2009, at 1:26, Ron Bonica wrote: > > > >=20 > > > > > The HISTORIC nomenclature doesn't mean that there is no > > longer an > > > > > installed base. It just means that something more recent is > > > > available. > > > >=20 > > > > I still think it's premature to change the status of RFC 2385=20 > > > > before a replacement is widely available operationally. > > > >=20 > > > > And yes, that can take a decade, see 32-bit AS numbers. > > > >=20 > > > > Iljitsch > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > >=20 > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > >=20 >=20 From toby.moncaster@bt.com Wed Aug 5 02:24:54 2009 Return-Path: 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 EBD5328C530; Wed, 5 Aug 2009 02:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 H1yyuYWPbe6o; Wed, 5 Aug 2009 02:24:54 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D81A628C39D; Wed, 5 Aug 2009 02:23:41 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 10:22:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 10:22:11 +0100 Message-ID: In-Reply-To: <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] status of TCP-MD5 after TCP-AO publication Thread-Index: AcoVHCRpUYkawuiWR0OqBusOh0XiQAAkXq5w References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net> <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> From: To: , X-OriginalArrivalTime: 05 Aug 2009 09:22:12.0830 (UTC) FILETIME=[37369FE0:01CA15AE] Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 05 Aug 2009 09:24:55 -0000 New solutions may only become widely deployed if there is some = indication that the existing deployment is in some way = obsolete/historic. If you are now saying we can't call the existing = solution obsolete/historic until there is wide deployment of the new = solution then we are in a Catch 22... Toby ____________________________________________________________________=20 Toby Moncaster, Networks Research Centre, BT=20 B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf = Of > Iljitsch van Beijnum > Sent: 04 August 2009 16:56 > To: Ron Bonica > Cc: tcpm@ietf.org; iesg@ietf.org IESG > Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication >=20 > On 4 aug 2009, at 1:26, Ron Bonica wrote: >=20 > > The HISTORIC nomenclature doesn't mean that there is no longer an > > installed base. It just means that something more recent is > available. >=20 > I still think it's premature to change the status of RFC 2385 before a > replacement is widely available operationally. >=20 > And yes, that can take a decade, see 32-bit AS numbers. >=20 > Iljitsch > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From iljitsch@muada.com Wed Aug 5 02:40:24 2009 Return-Path: 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 901EB28C545; Wed, 5 Aug 2009 02:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, 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 9zPkP3WVCUC6; Wed, 5 Aug 2009 02:40:23 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [83.149.65.1]) by core3.amsl.com (Postfix) with ESMTP id 034D928C55B; Wed, 5 Aug 2009 02:39:44 -0700 (PDT) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.55]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n759cYTY049934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Aug 2009 11:38:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Message-Id: <791B8996-F1CB-4DA6-B181-3D0A6E691532@muada.com> From: Iljitsch van Beijnum To: "" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 5 Aug 2009 11:38:51 +0200 References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com><4A777220.3070507@juniper.net> <75E968CA-1D9A-40BD-9C3E-534518B13BCF@muada.com> X-Mailer: Apple Mail (2.935.3) Cc: tcpm@ietf.org, iesg@ietf.org Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 05 Aug 2009 09:40:24 -0000 On 5 aug 2009, at 11:22, wrote: > New solutions may only become widely deployed if there is some > indication that the existing deployment is in some way obsolete/ > historic. If you are now saying we can't call the existing solution > obsolete/historic until there is wide deployment of the new solution > then we are in a Catch 22... Despite people telling me it has been around for years, I have never encountered AO in the wild. And with IPsec as a mechanism to protect BGP being a huge failure because the vendors couldn't make it configurable (remember, configuring BGP is a full time job in many cases!) and 32-bit AS numbers taking a decade to appear on the scene, I am worried that making RFC 2385 historic quickly may leave some operators with no way to protect BGP sessions. Don't forget that people can easily run 2 year old code and deployment in Quagga is complex due to the fact that the actual authentication happens in the kernel, so if a late model Cisco or Juniper has AO but no MD5 and an older model or a Quagga box only MD5 but no AO we're in worse shape than we are today. Also remember that what the crypto people think is good operational practice has nothing to do with what really happens in practice, setting up MD5 once and never changing the password is what happens in 49% of all cases (with no protection at all in 50%), and considering the amount of attacks happening this seems quite sufficient. Actually the thing that worries me most about MD5 is that it allows for CPU exhaustion attacks, especially as implementations seem to authenticate first and do TCP sanity checking later and RFC 3682 never caught on because it doesn't autonegotiate. Not sure of AO helps against those attacks, but IPsec could through the anti-replay counter. From pekkas@netcore.fi Wed Aug 5 02:57:36 2009 Return-Path: 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 7C0EA3A6B19; Wed, 5 Aug 2009 02:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 M5ZNBa-42MLh; Wed, 5 Aug 2009 02:57:35 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 6125A3A6AAA; Wed, 5 Aug 2009 02:57:35 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id n759vVdU001010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2009 12:57:31 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id n759vUr7001006; Wed, 5 Aug 2009 12:57:31 +0300 Date: Wed, 5 Aug 2009 12:57:30 +0300 (EEST) From: Pekka Savola To: Joe Touch In-Reply-To: <4A786374.5010705@isi.edu> Message-ID: References: <6BB76CFA-4134-4D3E-BE20-3A90A5111CBD@nokia.com> <4A786374.5010705@isi.edu> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at otso.netcore.fi X-Virus-Status: Clean Cc: tcpm@ietf.org, "iesg@ietf.org IESG" Subject: Re: [tcpm] status of TCP-MD5 after TCP-AO publication X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 05 Aug 2009 09:57:36 -0000 I'll probably regret putting in my 5c, but.. On Tue, 4 Aug 2009, Joe Touch wrote: > Because TCP-AO is intended to replace TCP MD5, and because TCP MD5 is > considered less than desirable, it seems reasonable to both put forward > AO as draft-standard and declare TCP MD5 historic at the same time. (I think you mean proposed standard, not draft standard.) I support making TCP MD5 historic if when TCP-AO is being approved there exist at least a couple of implementations of TCP-AO. Just making there is real commitment behind TCP-AO. If it's important to vendors, they will have implemented it long before RFC status. Otherwise, we can keep TCP MD5 status as is. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ilpo.jarvinen@helsinki.fi Wed Aug 5 04:12:36 2009 Return-Path: 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 32C5F3A7184 for ; Wed, 5 Aug 2009 04:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.872 X-Spam-Level: X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, 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 YoIVRI9b+ilL for ; Wed, 5 Aug 2009 04:12:35 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 353AF3A6BA4 for ; Wed, 5 Aug 2009 04:12:34 -0700 (PDT) Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Wed, 05 Aug 2009 14:12:35 +0300 id 0008C24E.4A796923.0000494F Received: by wel-95.cs.helsinki.fi (Postfix, from userid 50795) id D8AE5202141; Wed, 5 Aug 2009 14:12:35 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by wel-95.cs.helsinki.fi (Postfix) with ESMTP id D55F4202140; Wed, 5 Aug 2009 14:12:35 +0300 (EEST) Date: Wed, 5 Aug 2009 14:12:35 +0300 (EEST) From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi To: tcpm@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="8323329-901203034-1249470664=:10654" Content-ID: Cc: Markku Kojo Subject: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01 X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 05 Aug 2009 11:12:36 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-901203034-1249470664=:10654 Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi all, We've just uploaded 01 version which is effectively the same version as the unofficial 01a that was used as the basis of the presentation in the Stockholm meeting. Only the following placeholders for TBD items were added to -01 version: - A note on Window Updates, yet another case where the improved algorithm has a benefit (thanks to corridor talk with Anna Brunström) - Clarified the dupack counting rule for the case where the duplicate ACKs don't come "in a row" Any feedback is more than welcome. In the meeting it was also decided take to the mailing list the further discussion on whether there's interest in adopting this as a WG item? -- i. From: IETF I-D Submission Tool To: ilpo.jarvinen@helsinki.fi Cc: kojo@cs.helsinki.fi Subject: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01 Date: Wed, 5 Aug 2009 02:06:14 -0700 (PDT) A new version of I-D, draft-jarvinen-tcpm-sack-recovery-entry-01.txt has been successfuly submitted by Ilpo Jarvinen and posted to the IETF repository. Filename: draft-jarvinen-tcpm-sack-recovery-entry Revision: 01 Title: Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation Creation_date: 2009-08-05 WG ID: Independent Submission Number_of_pages: 15 Abstract: This document describes a TCP sender algorithm to trigger loss recovery based on the information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements in the traditional way. The given algorithm is more robust to ACK losses, ACK reordering, missed duplicate acknowledgements due to delayed acknowledgements, and extra duplicate acknowledgements due to duplicated segments and out-of- window segments. The algorithm allows not only a timely initiation of TCP loss recovery but also reduces false fast retransmits. It has a low implementation cost on top of the SACK scoreboard defined in RFC 3517. The IETF Secretariat. --8323329-901203034-1249470664=:10654-- From wesley.m.eddy@nasa.gov Wed Aug 5 07:48:22 2009 Return-Path: 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 C72E528C4B3 for ; Wed, 5 Aug 2009 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=-1.190, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, 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 tslt1V0nT5Zm for ; Wed, 5 Aug 2009 07:48:22 -0700 (PDT) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id E79C928C3F7 for ; Wed, 5 Aug 2009 07:48:21 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 9ACF62D83B3; Wed, 5 Aug 2009 09:48:24 -0500 (CDT) Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n75EmOUk020682; Wed, 5 Aug 2009 09:48:24 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Wed, 5 Aug 2009 09:48:24 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: =?iso-8859-1?Q?Ilpo_J=E4rvinen?= , "tcpm@ietf.org" Date: Wed, 5 Aug 2009 09:48:23 -0500 Thread-Topic: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01 Thread-Index: AcoVvak6kCJUSL3ZSoubpSw6Js+V0wAHVJWw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-05_09:2009-07-24, 2009-08-05, 2009-08-05 signatures=0 Cc: Markku Kojo Subject: Re: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01 X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 05 Aug 2009 14:48:22 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Ilpo J=E4rvinen >Sent: Wednesday, August 05, 2009 7:13 AM > >Hi all, > >We've just uploaded 01 version which is effectively the same version as >the unofficial 01a that was used as the basis of the presentation in >the Stockholm meeting. Only the following placeholders for TBD items >were added to -01 version: >- A note on Window Updates, yet another case where the improved > algorithm has a benefit (thanks to corridor talk with Anna Brunstr=F6m) >- Clarified the dupack counting rule for the case where the > duplicate ACKs don't come "in a row" > >Any feedback is more than welcome. > >In the meeting it was also decided take to the mailing list the >further discussion on whether there's interest in adopting this >as a WG item? I've read this version of the document. It looks like a pretty reasonable thing to do to me, and the document is well-scoped and has good discussion of the proposal itself and interactions with other mechanisms in a TCP implementation. I would support it as a WG item. For better understanding of the change being made and of the benefits, it would really help to have some time-sequence diagrams showing the difference that this makes under the different kinds of circumstances where it's useful (e.g. lossy ack path). --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From hkchu@google.com Sat Aug 8 17:35:37 2009 Return-Path: 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 0BE253A67E6 for ; Sat, 8 Aug 2009 17:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.797 X-Spam-Level: X-Spam-Status: No, score=-103.797 tagged_above=-999 required=5 tests=[AWL=2.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 imPiKQnvZKZw for ; Sat, 8 Aug 2009 17:35:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 3D0DB3A6782 for ; Sat, 8 Aug 2009 17:35:36 -0700 (PDT) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n790ZdIC030663 for ; Sat, 8 Aug 2009 17:35:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1249778139; bh=7VzrcXPr85G2P02BIZPqLKLqc3g=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=duWwSikHKXbugCV0CL 8WcM2nOut3WweFnW9dscX6Ikeo/ehEYp+Xd78it/ARvKDzs2jm+EAT8uIn1cPjIBafM g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=V/M5kQpaBw0747KhslTksH8pVPiYBpeEH4BetvqrIhJZbHyg/DU3lAvqVR6sRaeUb maJOyFZmWKSIRyR7JSXhw== Received: from ewy19 (ewy19.prod.google.com [10.241.103.19]) by zps37.corp.google.com with ESMTP id n790Z335030814 for ; Sat, 8 Aug 2009 17:35:37 -0700 Received: by ewy19 with SMTP id 19so1324322ewy.44 for ; Sat, 08 Aug 2009 17:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.24.206 with SMTP id x56mr572382wex.39.1249778136492; Sat, 08 Aug 2009 17:35:36 -0700 (PDT) In-Reply-To: <20090803120726.2F0DD39CCA1@lawyers.icir.org> References: <20090803120726.2F0DD39CCA1@lawyers.icir.org> Date: Sat, 8 Aug 2009 17:35:36 -0700 Message-ID: From: Jerry Chu To: mallman@icir.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tcpm@ietf.org" Subject: Re: [tcpm] initial RTO (was Re: Tuning TCP parameters for the 21st century) X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Sun, 09 Aug 2009 00:35:37 -0000 [Sorry for the delay again due to vacation.] On Mon, Aug 3, 2009 at 5:07 AM, Mark Allman wrote: > >> the rate distribution is far from even. > > Right. =A0That's clear from both your slides and a ton of previous > empirical observation. =A0I was merely using an average of sorts from you= r > slides as an illustration. > > A couple more things: > > =A0- Even if the loss rate is 10% that's .1*.1 or 1% instead of .02*.02. > =A0 =A0So, we're not helping a stunningly large number of connections. > > =A0- Moreover, if we're talking about correlated loss rates across RTOs > =A0 =A0then I think you're arguing for aggressiveness in the face of > =A0 =A0persistent congestion to help a quite small fraction of > =A0 =A0connections. =A0That doesn't quite seem useful. Not sure how much more congestion one additional 1-sec RTO may add to a congested link. Unfortunately I don't have data to argue either way so this seems to remain a subjective call for now. > >> As I mentioned in my previous email the try-N can diverge into >> different flavors. > > It seems that we don't quite have the same notion of what we're talking > about. =A0Could you sketch something concrete in an email to the list? Sorry for leaving out some gory details. There could be another exit condition to the N-shot 1-sec-initRTO scheme in addition to the following two: 1) N shots have been used up 2) a valid RTO estimate has been obtained The 3rd exit condition I've had in mind is 3) when a connection exits from 3WHS, usually into fully established The one-shot initRTO scheme will not need 3) because by then it would've met either 1) or 2). For a N-shot schem where N > 1, it could have two different flavors depending on whether 3) is included as an exit condition. The N-shot scheme I've been leaning toward includes all three exit conditions for simplicity. That is, when a connection becomes fully established AND there is still shot left (and we haven't been able to acqui= re a valid RTO estimate), the remaining shots are forefeited and the 3-sec RTO is restored. There may be some marginal benefit of allowing the remaining 1-sec shots to be carried into the data transmission phase. But from the top of my head its complexity seems to outweigh the potential benefit. Jerry > > Thanks! > > allman > > > > From nishida@sfc.wide.ad.jp Mon Aug 10 01:23:32 2009 Return-Path: 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 CA4413A6D79 for ; Mon, 10 Aug 2009 01:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.54 X-Spam-Level: *** X-Spam-Status: No, score=3.54 tagged_above=-999 required=5 tests=[AWL=2.636, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] 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 yDo9clUasFNW for ; Mon, 10 Aug 2009 01:23:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id F0EF33A6D39 for ; Mon, 10 Aug 2009 01:23:31 -0700 (PDT) Received: from localhost (cpu.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1E1224C066 for ; Mon, 10 Aug 2009 17:23:32 +0900 (JST) Date: Mon, 10 Aug 2009 17:23:32 +0900 (JST) Message-Id: <20090810.172332.59694040.nishida@sfc.wide.ad.jp> To: tcpm@ietf.org From: Yoshifumi Nishida In-Reply-To: <20090810081501.7143F3A6D0A@core3.amsl.com> References: <20090810081501.7143F3A6D0A@core3.amsl.com> X-Mailer: Mew version 6.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action:draft-nishida-newreno-modification-01.txt X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Mon, 10 Aug 2009 08:23:32 -0000 Hello people, Sorry for bothering. I've updated the I-D presented in the IETF at SF. It looks a very minor issue in newreno, but at least it degrades the communication performance significantly in a certain situation. If you could give any kind of feedbacks, I would appreciate very much. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Internet-Drafts@ietf.org Subject: I-D Action:draft-nishida-newreno-modification-01.txt Date: Mon, 10 Aug 2009 01:15:01 -0700 (PDT) Message-ID: <20090810081501.7143F3A6D0A@core3.amsl.com> > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : NewReno Modification for Smooth Recovery After Fast Retransmission > Author(s) : Y. Nishida > Filename : draft-nishida-newreno-modification-01.txt > Pages : 14 > Date : 2009-08-10 > > This memo describes a feeble point in Fast Recovery algorithm in > NewReno defined in RFC3782 and proposes a simple modification to > solve the problem. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From alexander.zimmermann@nets.rwth-aachen.de Wed Aug 12 08:36:18 2009 Return-Path: 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 8F5CD3A6A2C for ; Wed, 12 Aug 2009 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, J_CHICKENPOX_33=0.6, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, 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 A-7OAGcG0z5d for ; Wed, 12 Aug 2009 08:36:11 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 850F93A69CE for ; Wed, 12 Aug 2009 08:36:11 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KO900DMXSKDKL20@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 12 Aug 2009 17:33:49 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,368,1246831200"; d="sig'?scan'208";a="22285571" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 12 Aug 2009 17:33:50 +0200 Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7CFXnSh028217; Wed, 12 Aug 2009 17:33:49 +0200 (CEST) Message-id: <86AE6E70-2944-48F4-BD79-E9E197E813A1@nets.rwth-aachen.de> From: Alexander Zimmermann To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= In-reply-to: Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-2--946389268 Content-transfer-encoding: 7bit Date: Wed, 12 Aug 2009 17:33:24 +0200 References: X-Pgp-Agent: GPGMail 1.2.0 (v56) X-Mailer: Apple Mail (2.936) Cc: "tcpm@ietf.org" , Markku Kojo Subject: Re: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01 X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Wed, 12 Aug 2009 15:36:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--946389268 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi all, after carefully reading Ilpo's I-D I fully support it as a WG item. =20 All in all it describes Linux "interpretation" of RFC3517, which is IMHO a more secure way than =20 simply counting DUPACKs. *** Comments * I think we need a clear definition what the term DUPACK means when =20 SACK is enabled. The I-D says (page 5): We also note that the defination of a =20= duplicate acknowledgement already suggests that an incoming ACK can be considered as a duplicate =20= ACK if it "contains previously unknown SACK information" [RFC2581bis]. What does it mean exactly? Is the fact that an ACK contains new SACK =20 blocks a necessary or a sufficient property to delcare the ACK as DUPACK? Example: ACK =20 with new SACK blocks, but containing data: DUPACK or not? ACK with new SACK blocks and FIN =20 bit: DUPACK or not? * Section 2, 5A) Why do you set HightRxt to SND.UNA? * Section 3.1, paragraph 3: ... a TCP sender that is able to discern segment boundaries... Example? * Section 3.1, Note: ...the problem is not unique to this algorithm ... because of how =20 IsLost() is defined. Do you know a better way how we can implement IsLost()? :-) *** Minor comments * IMHO %s/RFC2581/RFC2581bis/g * Section 1, paragraph 4 (without ADDME): Add a reference (RFC) for =20 Limited Transmit. * Section 3.2: ... case is the case ... Sounds not optimal. *** Misspellings %s/acknowledgements/acknowledgments/g %s/heurestic/heuristic/g %s/defination/definition/g %s/approproate/appropriate/g %s/discontiguous/discontinuous/g %s/advertises/advertizes/g %s/detemining/determining/g Am 05.08.2009 um 13:12 schrieb Ilpo J=C3=A4rvinen: > Hi all, > > We've just uploaded 01 version which is effectively the same version =20= > as > the unofficial 01a that was used as the basis of the presentation in > the Stockholm meeting. Only the following placeholders for TBD items > were added to -01 version: > - A note on Window Updates, yet another case where the improved > algorithm has a benefit (thanks to corridor talk with Anna =20 > Brunstr=C3=B6m) > - Clarified the dupack counting rule for the case where the > duplicate ACKs don't come "in a row" > > Any feedback is more than welcome. > > In the meeting it was also decided take to the mailing list the > further discussion on whether there's interest in adopting this > as a WG item? > > -- > i. > > From: IETF I-D Submission Tool > To: ilpo.jarvinen@helsinki.fi > Cc: kojo@cs.helsinki.fi > Subject: New Version Notification for > draft-jarvinen-tcpm-sack-recovery-entry-01 > Date: Wed, 5 Aug 2009 02:06:14 -0700 (PDT) > > > A new version of I-D, draft-jarvinen-tcpm-sack-recovery-entry-01.txt =20= > has been successfuly submitted by Ilpo Jarvinen and posted to the =20 > IETF repository. > > Filename: draft-jarvinen-tcpm-sack-recovery-entry > Revision: 01 > Title: Using TCP Selective Acknowledgement (SACK) = Information to =20 > Determine Duplicate Acknowledgements for Loss Recovery Initiation > Creation_date: 2009-08-05 > WG ID: Independent Submission > Number_of_pages: 15 > > Abstract: > This document describes a TCP sender algorithm to trigger loss > recovery based on the information gathered on a SACK scoreboard > instead of simply counting the number of arriving duplicate > acknowledgements in the traditional way. The given algorithm is more > robust to ACK losses, ACK reordering, missed duplicate > acknowledgements due to delayed acknowledgements, and extra > duplicate acknowledgements due to duplicated segments and out-of- > window segments. The algorithm allows not only a timely initiation > of TCP loss recovery but also reduces false fast retransmits. It > has a low implementation cost on top of the SACK scoreboard defined > in RFC 3517. > > > > The IETF Secretariat. > // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22220 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-2--946389268 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkqC4OEACgkQdyiq39b9uS6igwCfUsARP7WGW3+HbrgOY3cXPLxQ peYAoNsCBVC6rziT+8T3xWaU2pykquYt =u/XV -----END PGP SIGNATURE----- --Apple-Mail-2--946389268-- From andrew.knutsen@bluecoat.com Thu Aug 13 11:52:03 2009 Return-Path: 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 EF02128C198 for ; Thu, 13 Aug 2009 11:52:03 -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 A5PzQq4Iolbc for ; Thu, 13 Aug 2009 11:52:03 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 4558328C190 for ; Thu, 13 Aug 2009 11:52:03 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DIplNd009694; Thu, 13 Aug 2009 11:51:47 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 11:51:41 -0700 Message-ID: <4A8460BE.1060105@bluecoat.com> Date: Thu, 13 Aug 2009 11:51:42 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: tcpm@ietf.org References: <4A775C60.7030204@bluecoat.com> In-Reply-To: <4A775C60.7030204@bluecoat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2009 18:51:41.0929 (UTC) FILETIME=[18E35D90:01CA1C47] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Thu, 13 Aug 2009 18:52:04 -0000 Are there any comments on this draft? We'd like to proceed ASAP, so we can begin working the new option assignments into our protocols. Andrew Andrew Knutsen wrote: > > We've just posted > . > The intended category is Informational. > > Current technology uses several experimental and unassigned option > kinds for this function, by different vendors. This draft represents > an effort to allow use of a single, standard, flexible option. We > appreciate your attention, so we can begin moving toward an assigned > option kind. > > Abstract > > This document describes a TCP option intended to facilitate > transparent detection of middleboxes (or services playing that role) > along the path of a TCP connection as the connection is made. The > option has no effect if an appropriate middlebox is not on the path. > > > From wesley.m.eddy@nasa.gov Thu Aug 13 12:40:36 2009 Return-Path: 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 788093A6D59 for ; Thu, 13 Aug 2009 12:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, 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 JR4BXZgcWghg for ; Thu, 13 Aug 2009 12:40:29 -0700 (PDT) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 9794A3A6D53 for ; Thu, 13 Aug 2009 12:40:29 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 785A82D8172; Thu, 13 Aug 2009 14:40:33 -0500 (CDT) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7DJeX4V002953; Thu, 13 Aug 2009 14:40:33 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Thu, 13 Aug 2009 14:40:33 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Andrew Knutsen , "tcpm@ietf.org" Date: Thu, 13 Aug 2009 14:40:31 -0500 Thread-Topic: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery Thread-Index: AcocRzAqllodToj0QIynnblhzNXSRwAAraPQ Message-ID: References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> In-Reply-To: <4A8460BE.1060105@bluecoat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-13_15:2009-08-11, 2009-08-13, 2009-08-13 signatures=0 Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Thu, 13 Aug 2009 19:40:36 -0000 >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Andrew Knutsen >Sent: Thursday, August 13, 2009 2:52 PM >To: tcpm@ietf.org > > Are there any comments on this draft? We'd like to proceed ASAP, so >we can begin working the new option assignments into our protocols. > Here are some comments ... First, it's definitely good to see this kind of thing being brought for a proper number assignment rather than simply silently poaching one. Just from the abstract, I wasn't sure what "transparent detection" meant ..= . or if it should've been "detection of transparent middleboxes". To me, "transparent detection" sounds like the detection itself is undetectable :)= . In terminology, should client and server really be described in terms of request/response or should it be based on TCP concepts like sending a SYN or being in LISTEN? Requests MUST have the "R" bit set to 0, and Responses MUST have the "R" bi= t set to 1 ... but Requests MUST be in a SYN packet ... so I guess I don't se= e what the R-bit is accomplishing that the ACK bit doesn't already. If SYN-A= CK is set, it's a response, and if SYN (but not ACK), then it's a request, rig= ht, or am I missing something? Does this need to think about simultaneous open at all ... it's probably a non-issue, but worth mentioning just to make sure the bases are covered. The security considerations isn't quite right specifically, as it doesn't distinguish between different modes or ESP/AH in IPsec that affect the option's visibility and protection. My biggest question, simply because I'm totally naive about these things is who will use it, and if they already have something like it that this is ju= st formalizing and standardizing on. Further, I'm guessing that there's some way that the data from this option gets shared outside the TCP implementati= on with the app, but I don't totally understand what the app is going to do wi= th this knowledge. I guess maybe section 7 (empty, currently) will discuss th= at? Sorry if everyone else knows this already and I'm just late to the party :)= . My overall take-away from a quick read is that it seems a bit like this is hacking something into TCP to assist applications in creating layer violati= ons, and I don't quite understand the driving requirement or the benefits that c= an be gained by having it. Maybe there are some references or further discuss= ion to be included to motivate the mechanism? --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From andrew.knutsen@bluecoat.com Thu Aug 13 12:59:25 2009 Return-Path: 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 063EB28C1F3 for ; Thu, 13 Aug 2009 12:59:25 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Naz7v6UO48e1 for ; Thu, 13 Aug 2009 12:59:23 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 6633928C121 for ; Thu, 13 Aug 2009 12:59:04 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DJvDN9020089; Thu, 13 Aug 2009 12:58:54 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 12:58:08 -0700 Message-ID: <4A847050.7080007@bluecoat.com> Date: Thu, 13 Aug 2009 12:58:08 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080701030009040807020407" X-OriginalArrivalTime: 13 Aug 2009 19:58:08.0013 (UTC) FILETIME=[60C783D0:01CA1C50] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Thu, 13 Aug 2009 19:59:25 -0000 This is a multi-part message in MIME format. --------------080701030009040807020407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To answer your fundamental question, yes this is existing technology, implemented by at least three companies for several years. You can check our website (www.bluecoat.com) for one example. This assignment will not change the basic operation of these WAN Optimization products. "Transparent detection" refers to the fact that there is no explicit detection protocol; instead the detection is piggybacked on the TCP connection transaction, which goes through to the OCS (as we say; Original Content Server, the host explicitly addresses by the SYN packet) if the connection is not intercepted. Again, this is existing multivendor practice, used for the reasons mentioned in the draft. The "R" bit is to detect hosts which misbehave, and reflect options back to the sender. This does happen. Simultaneous opens have never been an issue because this is client/server technology. We can make this explicit. I can't comment on the security aspects right now because its not my area, but I'm sure we can add more info there. Perhaps one of my colleagues will answer ;-). We can add some information to section 7 if desired, but middleboxes typically run proprietary operating systems and thus the APIs are not standard... And yes, WAN Optimization can be considered a layering violation, along with most other security and load-balancing middleboxes, but that won't make them go away... Andrew Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >> Andrew Knutsen >> Sent: Thursday, August 13, 2009 2:52 PM >> To: tcpm@ietf.org >> >> Are there any comments on this draft? We'd like to proceed ASAP, so >> we can begin working the new option assignments into our protocols. >> >> > > > Here are some comments ... > > First, it's definitely good to see this kind of thing being brought for a > proper number assignment rather than simply silently poaching one. > > Just from the abstract, I wasn't sure what "transparent detection" meant ... > or if it should've been "detection of transparent middleboxes". To me, > "transparent detection" sounds like the detection itself is undetectable :). > > In terminology, should client and server really be described in terms of > request/response or should it be based on TCP concepts like sending a SYN > or being in LISTEN? > > Requests MUST have the "R" bit set to 0, and Responses MUST have the "R" bit > set to 1 ... but Requests MUST be in a SYN packet ... so I guess I don't see > what the R-bit is accomplishing that the ACK bit doesn't already. If SYN-ACK > is set, it's a response, and if SYN (but not ACK), then it's a request, right, > or am I missing something? > > Does this need to think about simultaneous open at all ... it's probably a > non-issue, but worth mentioning just to make sure the bases are covered. > > The security considerations isn't quite right specifically, as it doesn't > distinguish between different modes or ESP/AH in IPsec that affect the > option's visibility and protection. > > My biggest question, simply because I'm totally naive about these things is > who will use it, and if they already have something like it that this is just > formalizing and standardizing on. Further, I'm guessing that there's some > way that the data from this option gets shared outside the TCP implementation > with the app, but I don't totally understand what the app is going to do with > this knowledge. I guess maybe section 7 (empty, currently) will discuss that? > Sorry if everyone else knows this already and I'm just late to the party :). > > My overall take-away from a quick read is that it seems a bit like this is > hacking something into TCP to assist applications in creating layer violations, > and I don't quite understand the driving requirement or the benefits that can > be gained by having it. Maybe there are some references or further discussion > to be included to motivate the mechanism? > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > --------------080701030009040807020407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    To answer your fundamental question, yes this is existing technology, implemented by at least three companies for several years. You can check our website (www.bluecoat.com) for one example. This assignment will not change the basic operation of these WAN Optimization products.

    "Transparent detection" refers to the fact that there is no explicit detection protocol; instead the detection is piggybacked on the TCP connection transaction, which goes through to the OCS (as we say; Original Content Server, the host explicitly addresses by the SYN packet) if the connection is not intercepted.  Again, this is existing multivendor practice, used for the reasons mentioned in the draft.

    The "R" bit is to detect hosts which misbehave, and reflect options back to the sender.  This does happen.

    Simultaneous opens have never been an issue because this is client/server technology. We can make this explicit.

    I can't comment on the security aspects right now because its not my area, but I'm sure we can add more info there. Perhaps one of my colleagues will answer ;-).

    We can add some information to section 7 if desired, but middleboxes typically run proprietary operating systems and thus the APIs are not standard...  And yes, WAN Optimization can be considered a layering violation, along with most other security and load-balancing middleboxes, but that won't make them go away...

Andrew

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: 
-----Original Message-----
From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
Andrew Knutsen
Sent: Thursday, August 13, 2009 2:52 PM
To: tcpm@ietf.org

   Are there any comments on this draft?  We'd like to proceed ASAP, so
we can begin working the new option assignments into our protocols.

    


Here are some comments ...

First, it's definitely good to see this kind of thing being brought for a
proper number assignment rather than simply silently poaching one.

Just from the abstract, I wasn't sure what "transparent detection" meant ...
or if it should've been "detection of transparent middleboxes".  To me,
"transparent detection" sounds like the detection itself is undetectable :).

In terminology, should client and server really be described in terms of
request/response or should it be based on TCP concepts like sending a SYN
or being in LISTEN?

Requests MUST have the "R" bit set to 0, and Responses MUST have the "R" bit
set to 1 ... but Requests MUST be in a SYN packet ... so I guess I don't see
what the R-bit is accomplishing that the ACK bit doesn't already.  If SYN-ACK
is set, it's a response, and if SYN (but not ACK), then it's a request, right,
or am I missing something?

Does this need to think about simultaneous open at all ... it's probably a
non-issue, but worth mentioning just to make sure the bases are covered.

The security considerations isn't quite right specifically, as it doesn't
distinguish between different modes or ESP/AH in IPsec that affect the
option's visibility and protection.

My biggest question, simply because I'm totally naive about these things is
who will use it, and if they already have something like it that this is just
formalizing and standardizing on.  Further, I'm guessing that there's some
way that the data from this option gets shared outside the TCP implementation
with the app, but I don't totally understand what the app is going to do with
this knowledge.  I guess maybe section 7 (empty, currently) will discuss that?
Sorry if everyone else knows this already and I'm just late to the party :).

My overall take-away from a quick read is that it seems a bit like this is
hacking something into TCP to assist applications in creating layer violations,
and I don't quite understand the driving requirement or the benefits that can
be gained by having it.  Maybe there are some references or further discussion
to be included to motivate the mechanism?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

--------------080701030009040807020407-- From wesley.m.eddy@nasa.gov Thu Aug 13 13:53:22 2009 Return-Path: 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 AED3D3A67B6 for ; Thu, 13 Aug 2009 13:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, 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 ynqBqaVBBzok for ; Thu, 13 Aug 2009 13:53:21 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 868493A6972 for ; Thu, 13 Aug 2009 13:53:21 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id BB8FF328563; Thu, 13 Aug 2009 15:23:40 -0500 (CDT) Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7DKNeuv002167; Thu, 13 Aug 2009 15:23:40 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Thu, 13 Aug 2009 15:23:40 -0500 From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" To: Andrew Knutsen Date: Thu, 13 Aug 2009 15:23:38 -0500 Thread-Topic: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery Thread-Index: AcocUIYfE3fVWiemRBKzsgBai+Q3PgAAQUdA Message-ID: References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> <4A847050.7080007@bluecoat.com> In-Reply-To: <4A847050.7080007@bluecoat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-13_15:2009-08-11, 2009-08-13, 2009-08-13 signatures=0 Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Thu, 13 Aug 2009 20:53:22 -0000 Ok; just a couple easy follow-up questions: >-----Original Message----- >From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] >Sent: Thursday, August 13, 2009 3:58 PM > > To answer your fundamental question, yes this is existing >technology, implemented by at least three companies for several years. >You can check our website (www.bluecoat.com) for one example. This >assignment will not change the basic operation of these WAN Optimization >products. Ok; so what option number do they use? Do they all use the same one, or does each company pick its own? How was the option format arrived at (is it just Bluecoat's or do all the vendors use their own variation)? I guess that's all just background information that's needed to put the effort in context. > "Transparent detection" refers to the fact that there is no explicit >detection protocol; instead the detection is piggybacked on the TCP >connection transaction, which goes through to the OCS (as we say; >Original Content Server, the host explicitly addresses by the SYN >packet) if the connection is not intercepted. Again, this is existing >multivendor practice, used for the reasons mentioned in the draft. Ah; so there's terminology confusion between calling a middlebox transparent (meaning without end-application/transport knowledge) and calli= ng the detection transparent (meaning no extra packets sent). I guess it woul= d be more clear as "in-band detection"? > The "R" bit is to detect hosts which misbehave, and reflect options >back to the sender. This does happen. Ick! That makes sense, but it should be explicitly stated in the discussio= n of the R-bit if that's its full reason for existing, rather than only menti= oned in passing in the interoperability issues section. > Simultaneous opens have never been an issue because this is >client/server technology. We can make this explicit. It seems reasonable to do so. > We can add some information to section 7 if desired, but middleboxes >typically run proprietary operating systems and thus the APIs are not >standard... Right, but (correct this if I'm wrong ...) you have to also modify the TCP and application on the endpoints that initiate communications, right? Or will this only be intended for middlebox-to-middlebox? I'm still trying to understand what an application does now that it knows something about the middlebox(es), what changes about its behavior? The draft is pretty good in explaining the format of the option itself, but doesn't really speak to how the knowledge the option conveys gets used productively. As the application-writer, now that a know company X's gizmo 123 is in my path, how does that affect me versus not knowing it, or knowing that company Y's doohickey 456 is on the path? > And yes, WAN Optimization can be considered a layering >violation, along with most other security and load-balancing >middleboxes, but that won't make them go away... Fully understood and I don't disagree :). --------------------------- Wes Eddy Network & Systems Architect Verizon FNS / NASA GRC Office: (216) 433-6682 --------------------------- From andrew.knutsen@bluecoat.com Thu Aug 13 15:52:45 2009 Return-Path: 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 17FC83A6D0C for ; Thu, 13 Aug 2009 15:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zr5UcFjGQBZH for ; Thu, 13 Aug 2009 15:52:43 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 487853A692B for ; Thu, 13 Aug 2009 15:52:43 -0700 (PDT) Received: from exchfront1.internal.cacheflow.com (exchfront1 [10.2.2.114]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7DMp1gZ017630; Thu, 13 Aug 2009 15:52:47 -0700 (PDT) Received: from [10.9.84.209] ([10.9.84.209]) by exchfront1.internal.cacheflow.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Aug 2009 15:51:57 -0700 Message-ID: <4A84990C.9080002@bluecoat.com> Date: Thu, 13 Aug 2009 15:51:56 -0700 From: Andrew Knutsen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com> <4A847050.7080007@bluecoat.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070307030806030007010202" X-OriginalArrivalTime: 13 Aug 2009 22:51:57.0415 (UTC) FILETIME=[A92FF770:01CA1C68] Cc: Jamshid Mahdavi , Ron Frederick , Qing Li , "tcpm@ietf.org" , Wei Jen Yeh Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Thu, 13 Aug 2009 22:52:45 -0000 This is a multi-part message in MIME format. --------------070307030806030007010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'll put my responses inline this time... Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: > Ok; just a couple easy follow-up questions: > > >> -----Original Message----- >> From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com] >> Sent: Thursday, August 13, 2009 3:58 PM >> >> To answer your fundamental question, yes this is existing >> technology, implemented by at least three companies for several years. >> You can check our website (www.bluecoat.com) for one example. This >> assignment will not change the basic operation of these WAN Optimization >> products. >> > > > Ok; so what option number do they use? Do they all use the same one, > or does each company pick its own? How was the option format arrived > at (is it just Bluecoat's or do all the vendors use their own variation)? > I guess that's all just background information that's needed to put the > effort in context. > > > We use one of the "experimental" numbers, 0xFD. Cisco uses 0x21, and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions on how they were picked ;-). Although this info can be easily "sniffed", its probably not appropriate to put it in the draft. In fact, I'm not making any promises or representations about BlueCoats, or anyone else's, use or non-use of any of these or any other numbers in the future or the past. I hope that keeps the lawyers happy. >> "Transparent detection" refers to the fact that there is no explicit >> detection protocol; instead the detection is piggybacked on the TCP >> connection transaction, which goes through to the OCS (as we say; >> Original Content Server, the host explicitly addresses by the SYN >> packet) if the connection is not intercepted. Again, this is existing >> multivendor practice, used for the reasons mentioned in the draft. >> > > > Ah; so there's terminology confusion between calling a middlebox > transparent (meaning without end-application/transport knowledge) and calling > the detection transparent (meaning no extra packets sent). I guess it would > be more clear as "in-band detection"? > > > Well, our implementation is transparent in both ways.. although another vendor uses a slightly different transparent exchange, where extra packets are sent if a peer is detected. The current proposal could be used for many of these mechanisms. "In-band" doesn't really imply that the connection works if the middlebox is not present, does it? The word "transparent" is used fairly widely in the sense of no explicit configuration, although it can also refer to use of the same addresses on a tunnel connection as on the client and server connections (see below). Also, the "no extra packets" isn't a common use of the word, although one might consider it "transparent in time" ;-). Its just a real-world requirement. >> The "R" bit is to detect hosts which misbehave, and reflect options >> back to the sender. This does happen. >> > > > Ick! That makes sense, but it should be explicitly stated in the discussion > of the R-bit if that's its full reason for existing, rather than only mentioned > in passing in the interoperability issues section. > > We felt that it is an interoperability issue, and discussing it earlier would detract from the discussion of the primary purpose. >> Simultaneous opens have never been an issue because this is >> client/server technology. We can make this explicit. >> > > > It seems reasonable to do so. > Will do. > > >> We can add some information to section 7 if desired, but middleboxes >> typically run proprietary operating systems and thus the APIs are not >> standard... >> > > > Right, but (correct this if I'm wrong ...) you have to also modify the > TCP and application on the endpoints that initiate communications, right? > Or will this only be intended for middlebox-to-middlebox? I'm still > trying to understand what an application does now that it knows something > about the middlebox(es), what changes about its behavior? > Our use for this, which I think is the most common, if not the only use at present, is to set up "tunnels" as described in section 1. Since this draft is not a protocol spec, we didn't add detail about how these work. However for the purpose of this discussion: There are usually four "boxes" involved when a tunnel (as described here) is used: the client and the server, which don't know anything about this option, and two middleboxes, which we may call the "edge" (near the client) and the "core" (near the server). However, it is possible for the edge function to be implemented in the client box. It is also possible to have multiple tunnels along a path, so one box is both edge and core. Server and core are less likely to be combined because that would add load to the server. Both the client and the edge can use either explicit or transparent connection methods. The simplest, and currently most common, use of this option is transparent detection of the core by the edge (ie to see if the server is fronted by a core box), for the purpose of setting up a tunnel between two middleboxes. Note that there are other kinds of "tunnels" which are really more like relays, in that there is only one middebox. There are also tunnels where transparency is not appropriate, such as VPN tunnels. The tunnels I'm talking about are most often used for compression (aka WAN Optimization). I could add a lot of pictures to this, but at this level they're just series of boxes with lines between them ;-). Again, we didn't feel this level of background was appropriate for the draft, partly because we don't want to prejudice any future efforts towards protocol-level interoperability in this area, and partly for legal reasons (I haven't compromised myself here, I don't think, but if I went into more detail I might). However perhaps we could add a sentence saying "tunnels", as defined in the draft, are a primary use case. > The draft is pretty good in explaining the format of the option itself, > but doesn't really speak to how the knowledge the option conveys gets > used productively. As the application-writer, now that a know > company X's gizmo 123 is in my path, how does that affect me versus > not knowing it, or knowing that company Y's doohickey 456 is on the path? > In order to request interception by company X, you'd want to find out how they registered their option (OUI or IANA), and what particular info they want in the option. Then you'd need to know what to do if they responded. Also, you wouldn't really need this if you knew what was in the path (you'd likely use an explicit arrangement). However, if you were writing a server-side app and looking at all the options received, you'd at least know to ignore this option. Or, if you were writing a network monitoring tool, you could keep track of interception requests and responses. If you were writing a firewall, you could do policy on it. Etc... Andrew > > >> And yes, WAN Optimization can be considered a layering >> violation, along with most other security and load-balancing >> middleboxes, but that won't make them go away... >> > > > Fully understood and I don't disagree :). > > > --------------------------- > Wes Eddy > Network & Systems Architect > Verizon FNS / NASA GRC > Office: (216) 433-6682 > --------------------------- > --------------070307030806030007010202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    I'll put my responses inline this time... 

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote: 
Ok; just a couple easy follow-up questions:

  
-----Original Message-----
From: Andrew Knutsen [mailto:andrew.knutsen@bluecoat.com]
Sent: Thursday, August 13, 2009 3:58 PM

   To answer your fundamental question, yes this is existing
technology, implemented by at least three companies for several years.
You can check our website (www.bluecoat.com) for one example. This
assignment will not change the basic operation of these WAN Optimization
products.
    


Ok; so what option number do they use?  Do they all use the same one,
or does each company pick its own?  How was the option format arrived
at (is it just Bluecoat's or do all the vendors use their own variation)?
I guess that's all just background information that's needed to put the
effort in context.
    We use one of the "experimental" numbers, 0xFD.  Cisco uses 0x21, and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions on how they were picked ;-). Although this info can be easily "sniffed", its probably not appropriate to put it in the draft. In fact, I'm not making any promises or representations about BlueCoats, or anyone else's, use or non-use of any of these or any other numbers in the future or the past.  I hope that keeps the lawyers happy.

  

    
   "Transparent detection" refers to the fact that there is no explicit
detection protocol; instead the detection is piggybacked on the TCP
connection transaction, which goes through to the OCS (as we say;
Original Content Server, the host explicitly addresses by the SYN
packet) if the connection is not intercepted.  Again, this is existing
multivendor practice, used for the reasons mentioned in the draft.
    

  

  


Ah; so there's terminology confusion between calling a middlebox
transparent (meaning without end-application/transport knowledge) and calling
the detection transparent (meaning no extra packets sent).  I guess it would
be more clear as "in-band detection"?


  



    Well, our implementation is transparent in both ways..  although
another vendor uses a slightly different transparent exchange, where
extra packets are sent if a peer is detected.  The current proposal
could be used for many of these mechanisms.  "In-band" doesn't really
imply that the connection works if the middlebox is not present, does
it?



    The word "transparent" is used fairly widely in the sense of no
explicit configuration, although it can also refer to use of the same
addresses on a tunnel connection as on the client and server
connections (see below).



    Also, the "no extra packets" isn't a common use of the word,
although one might consider it "transparent in time" ;-). Its just a
real-world requirement.





  

  

    
   The "R" bit is to detect hosts which misbehave, and reflect options
back to the sender.  This does happen.
    

  

  


Ick!  That makes sense, but it should be explicitly stated in the discussion
of the R-bit if that's its full reason for existing, rather than only mentioned
in passing in the interoperability issues section.

  



    We felt that it is an interoperability issue, and discussing it
earlier would detract from the discussion of the primary purpose.





  

    
   Simultaneous opens have never been an issue because this is
client/server technology. We can make this explicit.
    

  

  


It seems reasonable to do so.
  



    Will do.



  

  

  

    
   We can add some information to section 7 if desired, but middleboxes
typically run proprietary operating systems and thus the APIs are not
standard...
    

  

  


Right, but (correct this if I'm wrong ...) you have to also modify the
TCP and application on the endpoints that initiate communications, right?
Or will this only be intended for middlebox-to-middlebox?  I'm still
trying to understand what an application does now that it knows something
about the middlebox(es), what changes about its behavior?
  



    Our use for this, which I think is the most common, if not the only
use at present, is to set up "tunnels" as described in section 1. Since
this draft is not a protocol spec, we didn't add detail about how these
work.  However for the purpose of this discussion:



     There are usually four "boxes" involved when a tunnel (as
described here) is used: the client and the server, which don't know
anything about this option, and two middleboxes, which we may call the
"edge" (near the client) and the "core" (near the server). However, it
is possible for the edge function to be implemented in the client box.
It is also possible to have multiple tunnels along a path, so one box
is both edge and core. Server and core are less likely to be combined
because that would add load to the server.



    Both the client and the edge can use either explicit or transparent
connection methods. The simplest, and currently most common, use of
this option is transparent detection of the core by the edge (ie to see
if the server is fronted by a core box), for the purpose of setting up
a tunnel between two middleboxes.



    Note that there are other kinds of "tunnels" which are really more
like relays, in that there is only one middebox.  There are also
tunnels where transparency is not appropriate, such as VPN tunnels. The
tunnels I'm talking about are most often used for compression (aka WAN
Optimization).



    I could add a lot of pictures to this, but at this level they're
just series of boxes with lines between them ;-).



    Again, we didn't feel this level of background was appropriate for
the draft, partly because we don't want to prejudice any future efforts
towards protocol-level interoperability in this area, and partly for
legal reasons (I haven't compromised myself here, I don't think, but if
I went into more detail I might). However perhaps we could add a
sentence saying "tunnels", as defined in the draft, are a primary use
case.





  
The draft is pretty good in explaining the format of the option itself,
but doesn't really speak to how the knowledge the option conveys gets
used productively.  As the application-writer, now that a know
company X's gizmo 123 is in my path, how does that affect me versus
not knowing it, or knowing that company Y's doohickey 456 is on the path?
  



    In order to request interception by company X, you'd want to find
out how they registered their option (OUI or IANA), and what particular
info they want in the option. Then you'd need to know what to do if
they responded. Also, you wouldn't really need this if you knew what
was in the path (you'd likely use an explicit arrangement).



    However, if you were writing a server-side app and looking at all
the options received, you'd at least know to ignore this option. Or, if
you were writing a network monitoring tool, you could keep track of
interception requests and responses. If you were writing a firewall,
you could do policy on it.  Etc...



Andrew





  

  

  

    
 And yes, WAN Optimization can be considered a layering
violation, along with most other security and load-balancing
middleboxes, but that won't make them go away...
    

  

  


Fully understood and I don't disagree :).


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------
  








--------------070307030806030007010202--

From alexander.zimmermann@nets.rwth-aachen.de  Fri Aug 14 03:09:38 2009
Return-Path: 
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 68AFC3A687D for ; Fri, 14 Aug 2009 03:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.457
X-Spam-Level: 
X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.855,  BAYES_05=-1.11, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 am9GfKKq9-zP for ; Fri, 14 Aug 2009 03:09:37 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 523D83A67B5 for ; Fri, 14 Aug 2009 03:09:36 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOD00CAH2RM5MG0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 14 Aug 2009 12:06:58 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.43,379,1246831200"; d="sig'?scan'208";a="22492389"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 14 Aug 2009 12:06:58 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7EA6vbd013239; Fri, 14 Aug 2009 12:06:57 +0200 (CEST)
Message-id: 
From: Alexander Zimmermann 
To: Mark Allman 
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-18--793204669
Content-transfer-encoding: 7bit
Date: Fri, 14 Aug 2009 12:06:58 +0200
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Cc: tcpm@ietf.org
Subject: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Fri, 14 Aug 2009 10:09:38 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-18--793204669
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi Mark, hi TCPM

as requested at the last TCPM meeting in Stockholm that we need some  
reviews for Early Retransmit (draft-ietf-tcpm-early-rexmt-01), here  
are some comments from me:

*** Content

* First of all I like the draft. Short and easy. There exist a byte- 
based and a packet-based version. In both cases there is also a SACK  
and a non-SACK version described.

* The "entry point" of the algorithm could be better described. For  
example lets begin paragraph 2 in section 2.1 as follows: When an  
acknowledgment arrives at the sender, the sender ...

* What about RFC4653 - Improving the Robustness of TCP to Non- 
Congestion Events? Is Early Retransmit compatible to RFC4653? At first  
glance I think yes, when we define a priority which algo should alter  
Dupthresh


*** Minor comments

* Section 1, para 3: s/Small windows/Small congestion windows/

* Section 1, last para: Explanation of the difference between Limited  
Transmit and Early Retransmit. Maybe we can put here a pointer to the  
aforementioned case why a CWND can be small. For example (last  
sentence): The "Early Retransmit" mechanism outlined in this document  
covers the case when previously unsent data is not available (case 2)  
for transmission or cannot be transmitted due to an advertised window  
limitation (case 1).

* Check nits: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-tcpm-early-rexmt-01.txt 
. Broken references and so on.

*** Misspellings

* Consistent quotation marks: Line 94/95 - s/``Fast Retransmit''/"Fast  
Retransmit"/

* Ref [RFC2018], line 440: s/Acknowledgement/Acknowledgment/g :-)

Alex


//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-18--793204669
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqFN0IACgkQdyiq39b9uS6DyQCgm/tJeWbbUwB4NC8BvqUbZhMc
FfAAoN8V9GtPOeRp38SdEZ2Zcgy4d6jn
=jepG
-----END PGP SIGNATURE-----

--Apple-Mail-18--793204669--

From alexander.zimmermann@nets.rwth-aachen.de  Fri Aug 14 06:07:17 2009
Return-Path: 
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 820D13A6961 for ; Fri, 14 Aug 2009 06:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.629
X-Spam-Level: 
X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=1.172,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 qnKGJd51pYym for ; Fri, 14 Aug 2009 06:07:16 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 6121D3A67E7 for ; Fri, 14 Aug 2009 06:07:15 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOD00AZB9FWS990@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 14 Aug 2009 14:31:08 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.43,380,1246831200"; d="sig'?scan'208";a="22509333"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 14 Aug 2009 14:31:08 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7ECV8tb028834; Fri, 14 Aug 2009 14:31:08 +0200 (CEST)
Message-id: 
From: Alexander Zimmermann 
To: tcpm@ietf.org, iccrg IRTF list 
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-23--784553288
Content-transfer-encoding: 7bit
Date: Fri, 14 Aug 2009 14:31:09 +0200
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Subject: [tcpm] A new performance measurement tool - flowgrind
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Fri, 14 Aug 2009 13:07:17 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-23--784553288
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi all,

during our last research projects we ran into some problems with the  
current performance measurement tools like iperf, netperf, and the  
like. Mostly these tools are not able to schedule a bunch of flows  
among a number of nodes in a easy way or report more than throughput  
(e.g., kernel variables like CWND, SSTHRESH).

Amongst others flowgrind implements the following features:

* Distributed architecture
* Sophisticated flow scheduling
* Linux kernel TCP statistics
* Split control and data connection
* Application layer 1-way (IAT) and 2-way (RTT) delay
* Customizable socket options
* Anderson-Darling statistical test
* Monitoring, measuring, and accounting
* Rate-limited flows (Uniform and poisson packet distribution)

For more information, please check our site: http://www.umic-mesh.net/research/flowgrind/

If you interest in flowgrind you can download there tarball or  
directly access the code via
our subversion repository: svn://svn.umic-mesh.net/flowgrind/trunk

Comments and patches are more than welcome!

NB: At moment flowgrind runs only under Linux :-(

Alex

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-23--784553288
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqFWQ0ACgkQdyiq39b9uS5dOQCg9bnFKx19yfHsjoDembljOoxP
nCIAoNrX/DJhKiEkdiz1l6FMrzLH75Rj
=bCFq
-----END PGP SIGNATURE-----

--Apple-Mail-23--784553288--

From alexander.zimmermann@nets.rwth-aachen.de  Fri Aug 14 07:11:51 2009
Return-Path: 
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 B7CCB3A6A14 for ; Fri, 14 Aug 2009 07:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.019
X-Spam-Level: 
X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[AWL=0.782,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 EQSGSRjs4HZI for ; Fri, 14 Aug 2009 07:11:50 -0700 (PDT)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 8D73E3A694A for ; Fri, 14 Aug 2009 07:11:50 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOD00CR2E1F9FA0@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Fri, 14 Aug 2009 16:10:27 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.43,380,1246831200"; d="sig'?scan'208";a="22520724"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 14 Aug 2009 16:10:27 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7EEAR0p009733	for ; Fri, 14 Aug 2009 16:10:27 +0200 (CEST)
Message-id: <995026F6-22B0-4952-B831-D543918C92E8@nets.rwth-aachen.de>
From: Alexander Zimmermann 
To: tcpm@ietf.org
In-reply-to: <3A6B38C4-17F7-46CD-B75C-A502FBE08183@nets.rwth-aachen.de>
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-28--778594291
Content-transfer-encoding: 7bit
Date: Fri, 14 Aug 2009 16:10:28 +0200
References: <3A6B38C4-17F7-46CD-B75C-A502FBE08183@nets.rwth-aachen.de>
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Subject: Re: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-01
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Fri, 14 Aug 2009 14:11:51 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-28--778594291
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi again,

at the TCPM meeting in Stockholm it was decided to take the discussion  
on whether there's interest in adopting this as a WG item to the  
mailing list since besides a dozen supporters we had only two or three  
readers...

Alex

Am 13.07.2009 um 22:43 schrieb Alexander Zimmermann:

> Hi folks,
>
> I upload a new version of our draft to the IETF repository:
> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-01.txt
>
> Comments are more than welcome.
> I'm looking forward to seeing you in Stockholm.
>
> Alex
>
>
> Filename:	 draft-zimmermann-tcp-lcd
> Revision:	 01
> Title:		 Make TCP more Robust to Long Connectivity Disruptions
> Creation_date:	 2009-07-13
> WG ID:		 Independent Submission
> Number_of_pages: 16
>
> Abstract:
> Disruptions in end-to-end path connectivity which last longer than
> one retransmission timeout cause suboptimal TCP performance.  The
> reason for the performance degradation is that TCP interprets segment
> loss induced by connectivity disruptions as a sign of congestion,
> resulting in repeated backoffs of the retransmission timer.  This
> leads in turn to a deferred detection of the re-establishment of the
> connection since TCP waits until the next retransmission timeout
> occurs before attempting the retransmission.
>
> This document describes how standard ICMP messages can be exploited
> to disambiguate true congestion loss from non-congestion loss caused
> by long connectivity disruptions.  Moreover, a revert strategy of the
> retransmission timer is specified that enables a more prompt
> detection of whether the connectivity to a previously disconnected
> peer node has been restored or not.  The specified algorithm is a TCP
> sender-only modification that effectively improves TCP performance in
> presence of connectivity disruptions.
> 

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-28--778594291
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqFcFQACgkQdyiq39b9uS46UACeJUKMfAQxH88snvQxUTB8BMBD
RUcAn2eHNpmZaNAA/mWfKfVPX0VofeHa
=dVmm
-----END PGP SIGNATURE-----

--Apple-Mail-28--778594291--

From jamshid.mahdavi@bluecoat.com  Fri Aug 14 09:14:16 2009
Return-Path: 
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 45F843A6D50 for ; Fri, 14 Aug 2009 09:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 dCKhdhiEBS7U for ; Fri, 14 Aug 2009 09:14:14 -0700 (PDT)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by core3.amsl.com (Postfix) with ESMTP id 265FB3A6D37 for ; Fri, 14 Aug 2009 09:14:14 -0700 (PDT)
Received: from bcs-mail04.internal.cacheflow.com (bcsmail04.internal.cacheflow.com [10.2.2.56] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n7EGEH68011153; Fri, 14 Aug 2009 09:14:18 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1CFA.2583D034"
Date: Fri, 14 Aug 2009 09:13:22 -0700
Message-ID: 
In-Reply-To: <4A84990C.9080002@bluecoat.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
Thread-Index: AcocaKlmhggx7SJERnC98HqwicIOHgAjzGQg
References: <4A775C60.7030204@bluecoat.com> <4A8460BE.1060105@bluecoat.com>  <4A847050.7080007@bluecoat.com>  <4A84990C.9080002@bluecoat.com>
From: "Mahdavi, Jamshid" 
To: "Knutsen, Andrew" , "Eddy, Wesley M. \(GRC-MS00\)[Verizon]" 
Cc: "Frederick, Ron" , "Li, Qing" , tcpm@ietf.org, "Yeh, Wei  Jen" 
Subject: Re: [tcpm] New ID available: TCP Option for Transparent Middlebox Discovery
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Fri, 14 Aug 2009 16:14:16 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA1CFA.2583D034
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'd like to add one thing to Andrew's last point regarding
interoperability.
=20
We tried to design the option specification to allow for companies with
proprietary protocols to do discovery via the OUI ("Private") mechanism.
In this case the expectation is that the option is largely used in a
"Private" fashion -- in our case, one Blue Coat device finding another
Blue Coat device.
=20
For cases where there is a desire for real interoperability between
multiple products from different vendors and/or open source packages,
our hope is that such applications would define a non-private "device
type" and have this allocated by IANA.  A suitable RFC would have to be
provided specifying how discovery for that device type is supposed to
work and that is really where things would open up for anyone to be able
to use this option in an interoperable fashion.
=20
I can try to give one hypothetical example of what this might look like.
In HTTP, browsers provide slightly different formatting for the URL
depending on whether they are using a proxy or speaking directly to a
server.  When companies write transparent HTTP proxies, they must deal
with the server format of the URL.
=20
One could imagine a transparent middlebox discovery option defined for
the purpose of discovering transparent HTTP proxies.  If present, the
application (the web browser) could adjust the HTTP header to be more
suitable for an HTTP proxy.
=20
This is somewhat of a contrived example since no one really needs this
today, but we've defined the option formatting to allow for
standardization of such mechanisms that would allow applications to
discover and cooperate with middleboxes in the path (if they are present
and if they are interested in such cooperation).
=20
--J
=20

________________________________

From: Knutsen, Andrew=20
Sent: Thursday, August 13, 2009 3:52 PM
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: tcpm@ietf.org; Mahdavi, Jamshid; Frederick, Ron; Li, Qing; Yeh, Wei
Jen
Subject: Re: [tcpm] New ID available: TCP Option for Transparent
Middlebox Discovery



    I'll put my responses inline this time... =20

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:=20

	Ok; just a couple easy follow-up questions:
=09
	 =20

		-----Original Message-----
		From: Andrew Knutsen
[mailto:andrew.knutsen@bluecoat.com]
		Sent: Thursday, August 13, 2009 3:58 PM
	=09
		   To answer your fundamental question, yes this is
existing
		technology, implemented by at least three companies for
several years.
		You can check our website (www.bluecoat.com) for one
example. This
		assignment will not change the basic operation of these
WAN Optimization
		products.
		   =20

=09
=09
	Ok; so what option number do they use?  Do they all use the same
one,
	or does each company pick its own?  How was the option format
arrived
	at (is it just Bluecoat's or do all the vendors use their own
variation)?
	I guess that's all just background information that's needed to
put the
	effort in context.
=09
=09
	 =20

    We use one of the "experimental" numbers, 0xFD.  Cisco uses 0x21,
and Riverbed uses both 0x4C and 0x4E. You can draw your own conclusions
on how they were picked ;-). Although this info can be easily "sniffed",
its probably not appropriate to put it in the draft. In fact, I'm not
making any promises or representations about BlueCoats, or anyone
else's, use or non-use of any of these or any other numbers in the
future or the past.  I hope that keeps the lawyers happy.


=09

		   "Transparent detection" refers to the fact that there
is no explicit
		detection protocol; instead the detection is piggybacked
on the TCP
		connection transaction, which goes through to the OCS
(as we say;
		Original Content Server, the host explicitly addresses
by the SYN
		packet) if the connection is not intercepted.  Again,
this is existing
		multivendor practice, used for the reasons mentioned in
the draft.
		   =20

=09
=09
	Ah; so there's terminology confusion between calling a middlebox
	transparent (meaning without end-application/transport
knowledge) and calling
	the detection transparent (meaning no extra packets sent).  I
guess it would
	be more clear as "in-band detection"?
=09
=09
	 =20

    Well, our implementation is transparent in both ways..  although
another vendor uses a slightly different transparent exchange, where
extra packets are sent if a peer is detected.  The current proposal
could be used for many of these mechanisms.  "In-band" doesn't really
imply that the connection works if the middlebox is not present, does
it?

    The word "transparent" is used fairly widely in the sense of no
explicit configuration, although it can also refer to use of the same
addresses on a tunnel connection as on the client and server connections
(see below).

    Also, the "no extra packets" isn't a common use of the word,
although one might consider it "transparent in time" ;-). Its just a
real-world requirement.



=09

		   The "R" bit is to detect hosts which misbehave, and
reflect options
		back to the sender.  This does happen.
		   =20

=09
=09
	Ick!  That makes sense, but it should be explicitly stated in
the discussion
	of the R-bit if that's its full reason for existing, rather than
only mentioned
	in passing in the interoperability issues section.
=09
	 =20

    We felt that it is an interoperability issue, and discussing it
earlier would detract from the discussion of the primary purpose.



		   Simultaneous opens have never been an issue because
this is
		client/server technology. We can make this explicit.
		   =20

=09
=09
	It seems reasonable to do so.
	 =20

    Will do.


=09
	 =20

		   We can add some information to section 7 if desired,
but middleboxes
		typically run proprietary operating systems and thus the
APIs are not
		standard...
		   =20

=09
=09
	Right, but (correct this if I'm wrong ...) you have to also
modify the
	TCP and application on the endpoints that initiate
communications, right?
	Or will this only be intended for middlebox-to-middlebox?  I'm
still
	trying to understand what an application does now that it knows
something
	about the middlebox(es), what changes about its behavior?
	 =20

    Our use for this, which I think is the most common, if not the only
use at present, is to set up "tunnels" as described in section 1. Since
this draft is not a protocol spec, we didn't add detail about how these
work.  However for the purpose of this discussion:

     There are usually four "boxes" involved when a tunnel (as described
here) is used: the client and the server, which don't know anything
about this option, and two middleboxes, which we may call the "edge"
(near the client) and the "core" (near the server). However, it is
possible for the edge function to be implemented in the client box. It
is also possible to have multiple tunnels along a path, so one box is
both edge and core. Server and core are less likely to be combined
because that would add load to the server.

    Both the client and the edge can use either explicit or transparent
connection methods. The simplest, and currently most common, use of this
option is transparent detection of the core by the edge (ie to see if
the server is fronted by a core box), for the purpose of setting up a
tunnel between two middleboxes.

    Note that there are other kinds of "tunnels" which are really more
like relays, in that there is only one middebox.  There are also tunnels
where transparency is not appropriate, such as VPN tunnels. The tunnels
I'm talking about are most often used for compression (aka WAN
Optimization).

    I could add a lot of pictures to this, but at this level they're
just series of boxes with lines between them ;-).

    Again, we didn't feel this level of background was appropriate for
the draft, partly because we don't want to prejudice any future efforts
towards protocol-level interoperability in this area, and partly for
legal reasons (I haven't compromised myself here, I don't think, but if
I went into more detail I might). However perhaps we could add a
sentence saying "tunnels", as defined in the draft, are a primary use
case.



	The draft is pretty good in explaining the format of the option
itself,
	but doesn't really speak to how the knowledge the option conveys
gets
	used productively.  As the application-writer, now that a know
	company X's gizmo 123 is in my path, how does that affect me
versus
	not knowing it, or knowing that company Y's doohickey 456 is on
the path?
	 =20

    In order to request interception by company X, you'd want to find
out how they registered their option (OUI or IANA), and what particular
info they want in the option. Then you'd need to know what to do if they
responded. Also, you wouldn't really need this if you knew what was in
the path (you'd likely use an explicit arrangement).

    However, if you were writing a server-side app and looking at all
the options received, you'd at least know to ignore this option. Or, if
you were writing a network monitoring tool, you could keep track of
interception requests and responses. If you were writing a firewall, you
could do policy on it.  Etc...

Andrew



=09
	 =20

		 And yes, WAN Optimization can be considered a layering
		violation, along with most other security and
load-balancing
		middleboxes, but that won't make them go away...
		   =20

=09
=09
	Fully understood and I don't disagree :).
=09
=09
	---------------------------
	Wes Eddy
	Network & Systems Architect
	Verizon FNS / NASA GRC
	Office: (216) 433-6682
	---------------------------
	 =20



------_=_NextPart_001_01CA1CFA.2583D034
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







I'd like to add one thing to Andrew's last =
point regarding=20
interoperability.


 


We tried to design the option specification to =
allow for=20
companies with proprietary protocols to do discovery via the OUI =
("Private")=20
mechanism.  In this case the expectation is that the option is =
largely used=20
in a "Private" fashion -- in our case, one Blue Coat device finding =
another Blue=20
Coat device.


 


For cases where there is a desire for real =
interoperability=20
between multiple products from different vendors and/or open source =
packages,=20
our hope is that such applications would define a non-private "device =
type" and=20
have this allocated by IANA.  A suitable RFC would have to be =
provided=20
specifying how discovery for that device type is supposed to work and =
that is=20
really where things would open up for anyone to be able to use this =
option in an=20
interoperable fashion.


 


I can try to give one hypothetical example =
of what=20
this might look like.  In HTTP, browsers provide slightly different =

formatting for the URL depending on whether they are using a proxy or =
speaking=20
directly to a server.  When companies write transparent HTTP =
proxies, they=20
must deal with the server format of the URL.


 


One could imagine a transparent middlebox =
discovery option=20
defined for the purpose of discovering transparent HTTP proxies.  =
If=20
present, the application (the web browser) could adjust the HTTP header =
to be=20
more suitable for an HTTP proxy.


 


This is somewhat of a contrived example since =
no one really=20
needs this today, but we've defined the option formatting to =
allow=20
for standardization of such mechanisms that would allow =
applications to=20
discover and cooperate with middleboxes in the path (if they are =
present=20
and if they are interested in such cooperation).


 


--J


 






From: Knutsen, Andrew =

Sent: Thursday,=20
August 13, 2009 3:52 PM
To: Eddy, Wesley M.=20
(GRC-MS00)[Verizon]
Cc: tcpm@ietf.org; Mahdavi, Jamshid; =
Frederick,=20
Ron; Li, Qing; Yeh, Wei Jen
Subject: Re: [tcpm] New ID =
available: TCP=20
Option for Transparent Middlebox Discovery




    I'll put my responses inline this=20
time...  

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:=20

Ok; just a couple easy follow-up questions:

  

  
-----Original Message-----
From: Andrew Knutsen [mailto:andrew.knutsen@bluecoa=
t.com]
Sent: Thursday, August 13, 2009 3:58 PM

   To answer your fundamental question, yes this is existing
technology, implemented by at least three companies for several years.
You can check our website (www.bluecoat.com) for one example. =
This
assignment will not change the basic operation of these WAN Optimization
products.
    


Ok; so what option number do they use?  Do they all use the same one,
or does each company pick its own?  How was the option format arrived
at (is it just Bluecoat's or do all the vendors use their own =
variation)?
I guess that's all just background information that's needed to put the
effort in context.


  
    We use one of the "experimental" =

numbers, 0xFD.  Cisco uses 0x21, and Riverbed uses both 0x4C and =
0x4E. You=20
can draw your own conclusions on how they were picked ;-). Although this =
info=20
can be easily "sniffed", its probably not appropriate to put it in the =
draft. In=20
fact, I'm not making any promises or representations about BlueCoats, or =
anyone=20
else's, use or non-use of any of these or any other numbers in the =
future or the=20
past.  I hope that keeps the lawyers happy.



  
   "Transparent detection" =
refers to the fact that there is no explicit
detection protocol; instead the detection is piggybacked on the TCP
connection transaction, which goes through to the OCS (as we say;
Original Content Server, the host explicitly addresses by the SYN
packet) if the connection is not intercepted.  Again, this is existing
multivendor practice, used for the reasons mentioned in the draft.
    


Ah; so there's terminology confusion between calling a middlebox
transparent (meaning without end-application/transport knowledge) and =
calling
the detection transparent (meaning no extra packets sent).  I guess it =
would
be more clear as "in-band detection"?


  
    Well, our implementation is =
transparent=20
in both ways..  although another vendor uses a slightly different=20
transparent exchange, where extra packets are sent if a peer is =
detected. =20
The current proposal could be used for many of these mechanisms.  =
"In-band"=20
doesn't really imply that the connection works if the middlebox is not =
present,=20
does it?

    The word "transparent" is used fairly =
widely=20
in the sense of no explicit configuration, although it can also refer to =
use of=20
the same addresses on a tunnel connection as on the client and server=20
connections (see below).

    Also, the "no extra =
packets"=20
isn't a common use of the word, although one might consider it =
"transparent in=20
time" ;-). Its just a real-world requirement.




  
   The "R" bit is to detect =
hosts which misbehave, and reflect options
back to the sender.  This does happen.
    


Ick!  That makes sense, but it should be explicitly stated in the =
discussion
of the R-bit if that's its full reason for existing, rather than only =
mentioned
in passing in the interoperability issues section.

  
    We felt that it is an =
interoperability=20
issue, and discussing it earlier would detract from the discussion of =
the=20
primary purpose.



  
   Simultaneous opens have =
never been an issue because this is
client/server technology. We can make this explicit.
    


It seems reasonable to do so.
  
    Will do.


  

  
   We can add some =
information to section 7 if desired, but middleboxes
typically run proprietary operating systems and thus the APIs are not
standard...
    


Right, but (correct this if I'm wrong ...) you have to also modify the
TCP and application on the endpoints that initiate communications, =
right?
Or will this only be intended for middlebox-to-middlebox?  I'm still
trying to understand what an application does now that it knows =
something
about the middlebox(es), what changes about its behavior?
  
    Our use for this, which I think =
is the=20
most common, if not the only use at present, is to set up "tunnels" as =
described=20
in section 1. Since this draft is not a protocol spec, we didn't add =
detail=20
about how these work.  However for the purpose of this=20
discussion:

     There are usually four =
"boxes"=20
involved when a tunnel (as described here) is used: the client and the =
server,=20
which don't know anything about this option, and two middleboxes, which =
we may=20
call the "edge" (near the client) and the "core" (near the server). =
However, it=20
is possible for the edge function to be implemented in the client box. =
It is=20
also possible to have multiple tunnels along a path, so one box is both =
edge and=20
core. Server and core are less likely to be combined because that would =
add load=20
to the server.

    Both the client and the edge =
can use=20
either explicit or transparent connection methods. The simplest, and =
currently=20
most common, use of this option is transparent detection of the core by =
the edge=20
(ie to see if the server is fronted by a core box), for the purpose of =
setting=20
up a tunnel between two middleboxes.

    Note that =
there=20
are other kinds of "tunnels" which are really more like relays, in that =
there is=20
only one middebox.  There are also tunnels where transparency is =
not=20
appropriate, such as VPN tunnels. The tunnels I'm talking about are most =
often=20
used for compression (aka WAN Optimization).

    I =
could=20
add a lot of pictures to this, but at this level they're just series of =
boxes=20
with lines between them ;-).

    Again, we didn't =
feel=20
this level of background was appropriate for the draft, partly because =
we don't=20
want to prejudice any future efforts towards protocol-level =
interoperability in=20
this area, and partly for legal reasons (I haven't compromised myself =
here, I=20
don't think, but if I went into more detail I might). However perhaps we =
could=20
add a sentence saying "tunnels", as defined in the draft, are a primary =
use=20
case.



The draft is pretty good in explaining the =
format of the option itself,
but doesn't really speak to how the knowledge the option conveys gets
used productively.  As the application-writer, now that a know
company X's gizmo 123 is in my path, how does that affect me versus
not knowing it, or knowing that company Y's doohickey 456 is on the =
path?
  
    In order to request interception =
by=20
company X, you'd want to find out how they registered their option (OUI =
or=20
IANA), and what particular info they want in the option. Then you'd need =
to know=20
what to do if they responded. Also, you wouldn't really need this if you =
knew=20
what was in the path (you'd likely use an explicit=20
arrangement).

    However, if you were writing a=20
server-side app and looking at all the options received, you'd at least =
know to=20
ignore this option. Or, if you were writing a network monitoring tool, =
you could=20
keep track of interception requests and responses. If you were writing a =

firewall, you could do policy on it.  Etc...

Andrew



  

  
 And yes, WAN Optimization =
can be considered a layering
violation, along with most other security and load-balancing
middleboxes, but that won't make them go away...
    


Fully understood and I don't disagree :).


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------
  



------_=_NextPart_001_01CA1CFA.2583D034--

From ilpo.jarvinen@helsinki.fi  Mon Aug 17 05:37:31 2009
Return-Path: 
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 CFA0E3A6EEF for ; Mon, 17 Aug 2009 05:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.547
X-Spam-Level: 
X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, 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 ZVlS+kG-BtGb for ; Mon, 17 Aug 2009 05:37:30 -0700 (PDT)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 971593A6CF3 for ; Mon, 17 Aug 2009 05:37:30 -0700 (PDT)
Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 17 Aug 2009 15:37:33 +0300 id 000704CA.4A894F0D.0000262D
Received: by wel-95.cs.helsinki.fi (Postfix, from userid 50795) id 58D3B20208F; Mon, 17 Aug 2009 15:37:33 +0300 (EEST)
Received: from localhost (localhost [127.0.0.1]) by wel-95.cs.helsinki.fi (Postfix) with ESMTP id 56826202011; Mon, 17 Aug 2009 15:37:33 +0300 (EEST)
Date: Mon, 17 Aug 2009 15:37:33 +0300 (EEST)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" 
X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi
To: Alexander Zimmermann 
In-Reply-To: <86AE6E70-2944-48F4-BD79-E9E197E813A1@nets.rwth-aachen.de>
Message-ID: 
References:  <86AE6E70-2944-48F4-BD79-E9E197E813A1@nets.rwth-aachen.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" , Markku Kojo 
Subject: Re: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Mon, 17 Aug 2009 12:37:31 -0000

On Wed, 12 Aug 2009, Alexander Zimmermann wrote:

> after carefully reading Ilpo's I-D I fully support it as a WG item. All in 
> all it describes Linux
> "interpretation" of RFC3517, which is IMHO a more secure way than simply 
> counting
> DUPACKs.
>
>
> *** Comments
>
> * I think we need a clear definition what the term DUPACK means when SACK is
> enabled. The I-D says (page 5): We also note that the defination of a 
> duplicate acknowledgement
> already suggests that an incoming ACK can be considered as a duplicate ACK if 
> it "contains
> previously unknown SACK information" [RFC2581bis].
>
> What does it mean exactly? Is the fact that an ACK contains new SACK blocks a 
> necessary
> or a sufficient property to delcare the ACK as DUPACK? Example: ACK with new 
> SACK blocks,
> but containing data: DUPACK or not? ACK with new SACK blocks and FIN bit: 
> DUPACK or not?

This comes quite directly from rfc2581bis, but I can understand that
it's considerably harder to understand without having duplicate 
ACK said like in RFC2581bis. I'll change it to '...as a "duplicate" ACK if 
it "contains previously unknown SACK information" [RFC2581bis]'. But even 
with that change I agree that it is useful to add a very precise 
description what should be considered as a "duplicate" ACK in the context 
of this algorithm. And that would then be made to cover also the cases 
where the ACK is in fact cumulative (either due to minor reordering or 
out-of-sync due to ACK loss).

However, I don't find problematic the examples you mention. We are not 
interested in emulating behavior of dupack counter with bug-to-bug 
compatibility. Dupack counter is an artificial metric, the real metric 
the sender is interested is the number of in-window segments that receiver 
already has buffered (and how accurately the dupack counter could estimate 
that depends on scenario). After all, we try to fix the inaccuracies in 
the dupack counter, not to duplicate them. In the cases you mentioned, we 
may miss some "duplicate" ACKs because of ACK losses but never 
overestimate them because we have not received those earlier, "real" 
duplicate ACKs. While considering all this it is good to keep in mind 
that the duplicate ACK part is just a fallback for the small segment 
sender case, the IsLost() check takes care of the other cases.

> * Section 2, 5A)
> Why do you set HightRxt to SND.UNA?

This is there to avoid implementer confusion, as RFC3517 from which we 
"borrow" the SetPipe() requires a valid HighRxt.

> * Section 3.1, paragraph 3:
> ... a TCP sender that is able to discern segment boundaries...
> Example?

You mean an implementation or something else?

> * Section 3.1, Note:
> ...the problem is not unique to this algorithm ... because of how IsLost() is 
> defined.
> Do you know a better way how we can implement IsLost()? :-)

Sure, but I guess somebody might think that having to keeping track of 
segment boundaries of all segments is relatively expensive and that we 
should not be forcing all implementations to do that (please see the 
trick they used in early-rexmit to avoid keeping track of every boundary; 
though the wording there was slightly milder than what I had read into it
earlier).

> *** Minor comments
>
> * IMHO %s/RFC2581/RFC2581bis/g

Seems sensible for the two remaining, changed.

> * Section 1, paragraph 4 (without ADDME): Add a reference (RFC) for Limited 
> Transmit.

Added.

> * Section 3.2: ... case is the case ... Sounds not optimal.
>
>
> *** Misspellings
...snip...
> %s/advertises/advertizes/g

??

Thanks for the feedback.

-- 
  i.

From wesley.m.eddy@nasa.gov  Tue Aug 18 08:43:02 2009
Return-Path: 
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 2E44F3A6AEC for ; Tue, 18 Aug 2009 08:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.392
X-Spam-Level: 
X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599, 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 vA9NAYN-9Fbu for ; Tue, 18 Aug 2009 08:42:53 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 99FBA3A6872 for ; Tue, 18 Aug 2009 08:42:48 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 8C67D2D8018 for ; Tue, 18 Aug 2009 10:42:53 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7IFgriL006486 for ; Tue, 18 Aug 2009 10:42:53 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Tue, 18 Aug 2009 10:42:53 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
To: "tcpm@ietf.org" 
Date: Tue, 18 Aug 2009 10:41:08 -0500
Thread-Topic: WG status update
Thread-Index: AcogGk4ul0bSkc3SQ6eG8Vbmte0ydQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-18_13:2009-08-11, 2009-08-18, 2009-08-18 signatures=0
Subject: [tcpm] WG status update
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 18 Aug 2009 15:43:02 -0000

Since TCPM has a healthy plateful of items we're tracking and
either trying to wrap-up or trying to start-up, David and I
thought it would be a good idea to periodically send the list
a snapshot of the work items and actions needed as we see them.
The first such, is below.  If there are items not on the list
that you know of, please notify us :).


WG Items
=3D=3D=3D=3D=3D=3D=3D=3D

TCP Authentication Option
http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-05.txt
Milestone Target: Proposed Standard in April 2009
Action: Needs update parallel to AO-Crypto draft and then WGLC

TCP Authentication Option Crypto
http://www.ietf.org/internet-drafts/draft-lebovitz-ietf-tcpm-tcp-ao-crypto-=
02.txt
Milestone Target: Same as AO?  Need to clarify.
Action: Needs update parallel to AO draft and then WGLC

ICMP Attacks
http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-05.txt
Milestone Target: Informational in July 2009
Action: Needs update and then WGLC

Early-Retransmit
http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-early-rexmt/
Milestone Target: Experimental in July 2009
Action: WGLC is finished; check if authors intend to update ... then send t=
o IESG

1323bis
http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt
Milestone Target: Proposed Standard in July 2009
Action: Revise & WGLC

MSS Option
http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt
Milestone Target: Proposed Standard in July 2009
Action: Needs WGLC

Urgent Pointer
http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-00.txt
Milestone Target: Proposed Standard in January 2010
Action: Continue WG reviews

TCP Security
(Fernando will submit -00 I-D outline)
Milestone Target: need to submit for charter page - BCP in August 2010
Action: Fernando will be editor; WG needs to begin vetting and helping
revise into prescriptive format for BCP


Other Proposals
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Persist
http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt
Action: WG Review

Timestamps
http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt
Action: ???

Parameter Tuning
(no I-D yet)
Action: continue good discussion on mailing list
Presentation given in Stockholm

Long Connectivity Disruptions
http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-01.txt
Action: need WG to read/discuss
2x presentations (SFO and Stockholm) have been given

SACK Entry
http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-00
Action: need WG to read/discuss
presentation in Stockholm given

TCP Option for Transparent Middlebox Discovery
http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-=
00.txt
Action: Needs WG review / discussion


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From wesley.m.eddy@nasa.gov  Tue Aug 18 10:38:29 2009
Return-Path: 
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 F01C53A6E54 for ; Tue, 18 Aug 2009 10:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.411
X-Spam-Level: 
X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188,  BAYES_00=-2.599, 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 h2g8PN7tYP4U for ; Tue, 18 Aug 2009 10:38:29 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 313F63A6E4C for ; Tue, 18 Aug 2009 10:38:29 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7E57C3283D5 for ; Tue, 18 Aug 2009 12:38:22 -0500 (CDT)
Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7IHcLHo026432 for ; Tue, 18 Aug 2009 12:38:22 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 18 Aug 2009 12:38:21 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
To: "tcpm@ietf.org" 
Date: Tue, 18 Aug 2009 12:38:20 -0500
Thread-Topic: WGLC for MSS document
Thread-Index: AcogKq2J3U0wZe+BSOyl5yg0yZvwRQ==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-18_13:2009-08-11, 2009-08-18, 2009-08-18 signatures=0
Subject: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 18 Aug 2009 17:38:30 -0000

This note starts a 2-week Working Group Last Call on the TCPM document:
http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
Please send any comments to the TCPM list.  The WGLC will last until
September 1.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From wesley.m.eddy@nasa.gov  Tue Aug 18 10:51:29 2009
Return-Path: 
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 4A09128C365 for ; Tue, 18 Aug 2009 10:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.427
X-Spam-Level: 
X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599, 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 LzEN-P1ve-yj for ; Tue, 18 Aug 2009 10:51:28 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 163EA28C377 for ; Tue, 18 Aug 2009 10:50:07 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 618EAE8019; Tue, 18 Aug 2009 12:49:37 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7IHnbiZ012108; Tue, 18 Aug 2009 12:49:37 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Tue, 18 Aug 2009 12:49:36 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
To: "tcpm@ietf.org" 
Date: Tue, 18 Aug 2009 12:49:36 -0500
Thread-Topic: IETF 75 TCPM minutes
Thread-Index: AcogLEA3HJ+tblCeSuekJ4xJLFry8Q==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-18_13:2009-08-11, 2009-08-18, 2009-08-18 signatures=0
Subject: [tcpm] IETF 75 TCPM minutes
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 18 Aug 2009 17:51:29 -0000

The draft minutes from the TCPM meeting at IETF 75 are online:
http://www.ietf.org/proceedings/75/minutes/tcpm.txt

Thanks to Dave Craig for taking the notes, but don't blame him
for anything that might be wrong :).

Please submit any corrections to the chairs (or list) by
September 9, so we have time to put them into the proceedings.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From root@core3.amsl.com  Wed Aug 19 06:30:01 2009
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id C1B573A6CED; Wed, 19 Aug 2009 06:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090819133001.C1B573A6CED@core3.amsl.com>
Date: Wed, 19 Aug 2009 06:30:01 -0700 (PDT)
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-security-00.txt
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Wed, 19 Aug 2009 13:30:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.


	Title           : Security Assessment of the Transmission Control Protocol (TCP)
	Author(s)       : F. Gont
	Filename        : draft-ietf-tcpm-tcp-security-00.txt
	Pages           : 29
	Date            : 2009-08-19

This document contains a security assessment of the specifications of
the Transmission Control Protocol (TCP), and of a number of
mechanisms and policies in use by popular TCP implementations.
Additionally, it contains best current practices for hardening a TCP
implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-security-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tcpm-tcp-security-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-08-19062201.I-D@ietf.org>


--NextPart--

From fernando@gont.com.ar  Wed Aug 19 20:14:37 2009
Return-Path: 
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 6E95D3A6403 for ; Wed, 19 Aug 2009 20:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Level: 
X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=0.324,  BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1]
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 Ag77KGY8EN52 for ; Wed, 19 Aug 2009 20:14:36 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E03EA3A6CD5 for ; Wed, 19 Aug 2009 20:14:33 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BCAE56B664F; Thu, 20 Aug 2009 00:14:43 -0300 (ART)
Received: from [192.168.0.151] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7K3EMXX026476; Thu, 20 Aug 2009 00:14:22 -0300
Message-ID: <4A8CBF98.1070809@gont.com.ar>
Date: Thu, 20 Aug 2009 00:14:32 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "tcpm@ietf.org" 
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 20 Aug 2009 00:14:40 -0300 (ART)
Cc: "tcpm-chairs@tools.ietf.org" 
Subject: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 03:14:37 -0000

Folks,

As mentioned by David Borman, draft-gont-tcp-security has been adopted
as a wg item. It has been resubmitted as draft-ietf-tcpm-tcp-security, now.

I'd like to receive feedback on the outline of the document, i.e.,
whether you like the outline as-is or you think it should be modified.
(It should be noted that the document is aimed at TCP implementers, and
that's the reason for which most of the discussion is organized on a
per-protocol-field basis rather than on e.g., a per-attack-type basis).

We'll wait for your input on the outline of the document till August
26th, 2009 (one week from now).

BTW, as you may see, draft-ietf-tcpm-tcp-security contains only the
document outline, and the contents for the Introduction and the section
on the TCP "Source Port". The rationale for removing the rest of the
contents from the draft-ietf version of this document is that we want
the draft-ietf version to always represent wg consensus, to avoid having
implementers implement what's in the I-D assuming that it represents wg
consensus. Of course, the I-D will also contain the section that is
being currently discussed by the wg (hence the inclusion of the section
on "Source Port").

Once we are done with the outline, the plan is to move one section at a
time from draft-gont-tcp-security into draft-ietf-tcpm-tcp-security,
giving the wg enought time to provide feedback. (The first section to be
"discussed will be the one about the TCP "Source Port").

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando@gont.com.ar  Thu Aug 20 01:59:55 2009
Return-Path: 
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 546DA3A6FA2 for ; Thu, 20 Aug 2009 01:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.076
X-Spam-Level: 
X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 7TLpWCssBO7O for ; Thu, 20 Aug 2009 01:59:54 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E54C13A6E93 for ; Thu, 20 Aug 2009 01:59:05 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5F5276B65D5; Thu, 20 Aug 2009 05:59:10 -0300 (ART)
Received: from [192.168.0.151] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7K8x3QP018425; Thu, 20 Aug 2009 05:59:04 -0300
Message-ID: <4A8D1056.5060602@gont.com.ar>
Date: Thu, 20 Aug 2009 05:59:02 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 20 Aug 2009 05:59:07 -0300 (ART)
Cc: tcpm@ietf.org, Markku Kojo 
Subject: Re: [tcpm] Fwd: New Version Notification for draft-jarvinen-tcpm-sack-recovery-entry-01
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 08:59:55 -0000

Ilpo Järvinen wrote:

> We've just uploaded 01 version which is effectively the same version as
> the unofficial 01a that was used as the basis of the presentation in
> the Stockholm meeting. Only the following placeholders for TBD items
> were added to -01 version:
> - A note on Window Updates, yet another case where the improved
>   algorithm has a benefit (thanks to corridor talk with Anna Brunström)
> - Clarified the dupack counting rule for the case where the
>   duplicate ACKs don't come "in a row"

I'm planning to review this document anytime soon. In the man time, have
you had a look at Section 9.2 of
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf ?

IIRC, that of rquiring dupacks to contain new sack information came up
while discussing Section 9.2 with Mark Allman a while ago.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From alexander.zimmermann@nets.rwth-aachen.de  Thu Aug 20 02:47:56 2009
Return-Path: 
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 A969C3A6BD1 for ; Thu, 20 Aug 2009 02:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.215
X-Spam-Level: 
X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=0.586,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 o0s1S6ASJ0q8 for ; Thu, 20 Aug 2009 02:47:55 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 67C7B3A6D76 for ; Thu, 20 Aug 2009 02:47:55 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOO00MCJ5VZKBC0@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 20 Aug 2009 11:47:59 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.43,413,1246831200"; d="sig'?scan'208";a="23105701"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 20 Aug 2009 11:47:59 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7K9lwbP010586; Thu, 20 Aug 2009 11:47:58 +0200 (CEST)
Message-id: 
From: Alexander Zimmermann 
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
In-reply-to: 
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-67--275940777
Content-transfer-encoding: 7bit
Date: Thu, 20 Aug 2009 11:48:02 +0200
References: 
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] WG status update
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 09:47:56 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-67--275940777
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi Wes,

two short comments:

1. What is about "draft-nishida-newreno-modification-01"? I think
we should add his draft too.

2. Minor correction :-): The draft "SACK Entry" was not only presented  
in
Stockholm but also in SFO by M. Kojo.

Alex

Am 18.08.2009 um 17:41 schrieb Eddy, Wesley M. (GRC-MS00)[Verizon]:

> Since TCPM has a healthy plateful of items we're tracking and
> either trying to wrap-up or trying to start-up, David and I
> thought it would be a good idea to periodically send the list
> a snapshot of the work items and actions needed as we see them.
> The first such, is below.  If there are items not on the list
> that you know of, please notify us :).
>
>
> WG Items
> ========
>
> TCP Authentication Option
> http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-05.txt
> Milestone Target: Proposed Standard in April 2009
> Action: Needs update parallel to AO-Crypto draft and then WGLC
>
> TCP Authentication Option Crypto
> http://www.ietf.org/internet-drafts/draft-lebovitz-ietf-tcpm-tcp-ao-crypto-02.txt
> Milestone Target: Same as AO?  Need to clarify.
> Action: Needs update parallel to AO draft and then WGLC
>
> ICMP Attacks
> http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-05.txt
> Milestone Target: Informational in July 2009
> Action: Needs update and then WGLC
>
> Early-Retransmit
> http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-early-rexmt/
> Milestone Target: Experimental in July 2009
> Action: WGLC is finished; check if authors intend to update ... then  
> send to IESG
>
> 1323bis
> http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt
> Milestone Target: Proposed Standard in July 2009
> Action: Revise & WGLC
>
> MSS Option
> http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt
> Milestone Target: Proposed Standard in July 2009
> Action: Needs WGLC
>
> Urgent Pointer
> http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-00.txt
> Milestone Target: Proposed Standard in January 2010
> Action: Continue WG reviews
>
> TCP Security
> (Fernando will submit -00 I-D outline)
> Milestone Target: need to submit for charter page - BCP in August 2010
> Action: Fernando will be editor; WG needs to begin vetting and helping
> revise into prescriptive format for BCP
>
>
> Other Proposals
> ===============
>
> Persist
> http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt
> Action: WG Review
>
> Timestamps
> http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt
> Action: ???
>
> Parameter Tuning
> (no I-D yet)
> Action: continue good discussion on mailing list
> Presentation given in Stockholm
>
> Long Connectivity Disruptions
> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-01.txt
> Action: need WG to read/discuss
> 2x presentations (SFO and Stockholm) have been given
>
> SACK Entry
> http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-00
> Action: need WG to read/discuss
> presentation in Stockholm given
>
> TCP Option for Transparent Middlebox Discovery
> http://www.ietf.org/internet-drafts/draft-knutsen-tcpm-middlebox-discovery-00.txt
> Action: Needs WG review / discussion
>
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-67--275940777
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqNG9IACgkQdyiq39b9uS5lgACeJ3Dz83IALD7megcvbgWkVsUB
ns8AoOgYgZ5pR2rQ1mM09Hmy0XCDN3jP
=pAAw
-----END PGP SIGNATURE-----

--Apple-Mail-67--275940777--

From fernando@gont.com.ar  Thu Aug 20 03:29:57 2009
Return-Path: 
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 6E42828C284 for ; Thu, 20 Aug 2009 03:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=1.238,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 lRYnkOO3agdL for ; Thu, 20 Aug 2009 03:29:56 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 2A6C528C1EA for ; Thu, 20 Aug 2009 03:29:48 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 1C7196B65DA; Thu, 20 Aug 2009 07:29:53 -0300 (ART)
Received: from [192.168.0.151] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7KATkXS016580; Thu, 20 Aug 2009 07:29:48 -0300
Message-ID: <4A8D259B.4060409@gont.com.ar>
Date: Thu, 20 Aug 2009 07:29:47 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 20 Aug 2009 07:29:52 -0300 (ART)
Cc: "tcpm@ietf.org" , David Borman 
Subject: Re: [tcpm] WG status update
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 10:29:57 -0000

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> Timestamps
> http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt
> Action: ???

This document could possibly become a BCP.

I recall we talked with David Borman a little bit about this one in
MPLS, and I seem to recall that this one of the possible outcomes. I
also seem to recall that David was thinking about tweaking rfc1323 in
response to this I-D (e.g., recommend timestamps to be monotonically
increasing across connections).

David? (CC'ed)

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From alexander.zimmermann@nets.rwth-aachen.de  Thu Aug 20 07:50:40 2009
Return-Path: 
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 1D4E93A6D61 for ; Thu, 20 Aug 2009 07:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.332
X-Spam-Level: 
X-Spam-Status: No, score=-4.332 tagged_above=-999 required=5 tests=[AWL=0.469,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 LCPSQMlhMR8E for ; Thu, 20 Aug 2009 07:50:39 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id A6E143A7027 for ; Thu, 20 Aug 2009 07:50:28 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOO001QCJW0DC90@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Thu, 20 Aug 2009 16:50:24 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.43,414,1246831200"; d="sig'?scan'208";a="23147572"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Thu, 20 Aug 2009 16:50:24 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7KEoOPL014081; Thu, 20 Aug 2009 16:50:24 +0200 (CEST)
Message-id: <723AF71D-AC54-4AA8-BD4A-903F569D836D@nets.rwth-aachen.de>
From: Alexander Zimmermann 
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" , David Borman 
In-reply-to: 
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-72--257794436
Content-transfer-encoding: 7bit
Date: Thu, 20 Aug 2009 16:50:28 +0200
References: 
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 14:50:40 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-72--257794436
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi David,

some minor comments on the draft.

1. Needs boilerplate update (Copyright section)

2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP  
options/

3. Just one sentence later: "RFC-1122 [Braden89] attempted to clarify  
this in section 4.2.2.6, but
there still seems to be confusion." What is the problem here with RFC  
1122? Why does RFC 1122
does not manage to clarify the situation. I think one or two sentence  
more explanation would be
great.

Alex


Am 18.08.2009 um 19:38 schrieb Eddy, Wesley M. (GRC-MS00)[Verizon]:

> This note starts a 2-week Working Group Last Call on the TCPM  
> document:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-72--257794436
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqNYrQACgkQdyiq39b9uS4uaQCfSfxKICf+wGDLu2zeLm7qsxAO
7iIAoLAxY7bev8xKzermgp/X9jD62bXI
=6OAJ
-----END PGP SIGNATURE-----

--Apple-Mail-72--257794436--

From touch@ISI.EDU  Thu Aug 20 11:19:57 2009
Return-Path: 
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 DBA933A69B3 for ; Thu, 20 Aug 2009 11:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, LONGWORDS=1.803]
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 1HjYwxip7MXW for ; Thu, 20 Aug 2009 11:19:57 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 40AFF3A6781 for ; Thu, 20 Aug 2009 11:19:24 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7KIJAsp008620; Thu, 20 Aug 2009 11:19:12 -0700 (PDT)
Message-ID: <4A8D939E.9050008@isi.edu>
Date: Thu, 20 Aug 2009 11:19:10 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont 
References: <4A8CBF98.1070809@gont.com.ar>
In-Reply-To: <4A8CBF98.1070809@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm-chairs@tools.ietf.org" , "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 18:19:57 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Folks,
> 
> As mentioned by David Borman, draft-gont-tcp-security has been adopted
> as a wg item. It has been resubmitted as draft-ietf-tcpm-tcp-security, now.
> 
> I'd like to receive feedback on the outline of the document, i.e.,
> whether you like the outline as-is or you think it should be modified.

I'll start with the observation that the WG approved an outline as the
WG starting point. The current doc has a few sections that are not an
outline; they should be omitted until we agree as a WG on their content.
This includes:
	1.1
	2.
	3.
	3.1
	3.1.1
	3.6.7

An exception would be only Sec 1.2, which is scoping the doc, and
providing a list of RFCs that might be relevant.

It seems useful to step back to the highest level of the outline.
Excepting required sections, they are:
	
	1 intro
	2 scope
	3 header fields
	4 common options
	5 connection establishment
	6 connection termination
	7 buffer management
	8 reassembly
	9 cong control
	10 API
	11 blind in-window attacks
	12 info leaking
	13 covert channels
	14 port scanning
	15 ICMP
	16 IP

It's not clear why 4 isn't part of 3, why 5 and 6 are separate, etc.
Overall, it'd be useful to have a more conventional structure:

	1 intro
		including scope
	2 background - to introduce terminology
		a) breakdown of TCP into:
			control
			data
			performance
			implementation
		b) threat model
		briefly explain attacks:
		- on-path vs. off-path
		- control vs. data vs. performance
		- injection vs. DOS

Then it'd be useful to break down TCP into its component parts, as
introduced in 2a:

	3 control attacks
		header fields
		option fields
		connection establishment
		connection termination
		port scanning

	4 data attacks
		injection
		info leaking

	5 performance
		cong control / ACK attacks
		reassy attacks

	6 implementation issues
		performance, e.g., SYN cookies, buffer mgt.
		API, IP interface issues

	7 security considerations
		this can be used as a catchall for items that don't
		fit as directly above and aren't specific to TCP,
		e.g., covert channel issues, info leaking etc.

IMO, this presents the info in a way that is still organized for
implementers, but structures it in a way that the info can be more
easily located when needed.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqNk54ACgkQE5f5cImnZrtnwQCcDzubosjOVH9JZtQUSmMeD0g7
GhoAn1276imjsf0rlK1hQCMDgqLbzu6v
=SZPc
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Thu Aug 20 11:28:35 2009
Return-Path: 
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 2E3E53A6EFA for ; Thu, 20 Aug 2009 11:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  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 2u2kOazF3c2X for ; Thu, 20 Aug 2009 11:28:34 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 42BE13A6CC1 for ; Thu, 20 Aug 2009 11:28:34 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7KIS4iO010744; Thu, 20 Aug 2009 11:28:06 -0700 (PDT)
Message-ID: <4A8D95B4.3040209@isi.edu>
Date: Thu, 20 Aug 2009 11:28:04 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 18:28:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> This note starts a 2-week Working Group Last Call on the TCPM document:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.

I'd like to suggest the following for this doc:

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC. The ROHC doc missed an opportunity to address the interaction of
variable MSS with TCP, and this might be a good place to include a
sentence or two on it, e.g. (IMO):

- ---

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest
possible MSS, to support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at their
endpoint compressor/decompressors. If the largest MSS is advertised, TCP
retransmission may interfere with compressor resynchonization.

As a result, when effective MSS varies, TCP SHOULD compute its
advertised MSS based on the smallest effective MSS.

- ---

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqNlbQACgkQE5f5cImnZrt7iQCfVF1g9/X6Zk8K0RJJaNFunbED
G50AoNdo3TnIP3psCkItjlWm9AP+tiE4
=Pu6T
-----END PGP SIGNATURE-----

From L.Wood@surrey.ac.uk  Thu Aug 20 13:00:59 2009
Return-Path: 
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 8F12328C1B8 for ; Thu, 20 Aug 2009 13:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.523
X-Spam-Level: 
X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=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 DEwrEJH9uvyq for ; Thu, 20 Aug 2009 13:00:58 -0700 (PDT)
Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by core3.amsl.com (Postfix) with SMTP id DE2D03A6A3B for ; Thu, 20 Aug 2009 13:00:57 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-6.tower-80.messagelabs.com!1250798462!71056855!1
X-StarScan-Version: 6.1.3; banners=-,-,-
X-Originating-IP: [131.227.102.140]
Received: (qmail 3755 invoked from network); 20 Aug 2009 20:01:02 -0000
Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-6.tower-80.messagelabs.com with SMTP; 20 Aug 2009 20:01:02 -0000
Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.139]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 20 Aug 2009 21:01:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA21D0.F0E2EC8B"
Date: Thu, 20 Aug 2009 20:59:14 +0100
Message-ID: <4835AFD53A246A40A3B8DA85D658C4BE01368955@EVS-EC1-NODE4.surrey.ac.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] WGLC for MSS document
Thread-Index: AcohxA/eBV9XnLxLRKyYuqK76i42XgADKGPK
References:  <4A8D95B4.3040209@isi.edu>
From: 
To: , 
X-OriginalArrivalTime: 20 Aug 2009 20:01:01.0830 (UTC) FILETIME=[F1462260:01CA21D0]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 20:00:59 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA21D0.F0E2EC8B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can't TCP MSS also vary across multipath environments? Strikes me
that these are more common than header compression - which should
be advertising conservative minimum MTUs for their link interfaces.





-----Original Message-----
From: tcpm-bounces@ietf.org on behalf of Joe Touch
Sent: Thu 2009-08-20 19:28
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
=20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> This note starts a 2-week Working Group Last Call on the TCPM =
document:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.

I'd like to suggest the following for this doc:

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC. The ROHC doc missed an opportunity to address the interaction of
variable MSS with TCP, and this might be a good place to include a
sentence or two on it, e.g. (IMO):

- ---

MSSs can sometimes vary, as when used with variable compression, e.g.,
ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest
possible MSS, to support the most efficient use of compressed payloads.
Unfortunately, some compression schemes occasionally need to transmit
full headers (and thus smaller payloads) to resynchronize state at their
endpoint compressor/decompressors. If the largest MSS is advertised, TCP
retransmission may interfere with compressor resynchonization.

As a result, when effective MSS varies, TCP SHOULD compute its
advertised MSS based on the smallest effective MSS.

- ---

Joe


------_=_NextPart_001_01CA21D0.F0E2EC8B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [tcpm] WGLC for MSS document





Can't TCP MSS also vary across multipath environments? =
Strikes me

that these are more common than header compression - which should

be advertising conservative minimum MTUs for their link interfaces.



<http://www.ee.surrey=
.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>







-----Original Message-----

From: tcpm-bounces@ietf.org on behalf of Joe Touch

Sent: Thu 2009-08-20 19:28

To: Eddy, Wesley M. (GRC-MS00)[Verizon]

Cc: tcpm@ietf.org

Subject: Re: [tcpm] WGLC for MSS document



-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



Hi, all,



Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> This note starts a 2-week Working Group Last Call on the TCPM =
document:

> http://tool=
s.ietf.org/html/draft-ietf-tcpm-tcpmss-02

> Please send any comments to the TCPM list.  The WGLC will last =
until

> September 1.



I'd like to suggest the following for this doc:



MSSs can sometimes vary, as when used with variable compression, =
e.g.,

ROHC. The ROHC doc missed an opportunity to address the interaction =
of

variable MSS with TCP, and this might be a good place to include a

sentence or two on it, e.g. (IMO):



- ---



MSSs can sometimes vary, as when used with variable compression, =
e.g.,

ROHC [RFC5255]. It is tempting for TCP to want to advertise the =
largest

possible MSS, to support the most efficient use of compressed =
payloads.

Unfortunately, some compression schemes occasionally need to =
transmit

full headers (and thus smaller payloads) to resynchronize state at =
their

endpoint compressor/decompressors. If the largest MSS is advertised, =
TCP

retransmission may interfere with compressor resynchonization.



As a result, when effective MSS varies, TCP SHOULD compute its

advertised MSS based on the smallest effective MSS.



- ---



Joe









------_=_NextPart_001_01CA21D0.F0E2EC8B--

From touch@ISI.EDU  Thu Aug 20 13:35:43 2009
Return-Path: 
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 98EE63A6950 for ; Thu, 20 Aug 2009 13:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022,  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 i5wu26lhex73 for ; Thu, 20 Aug 2009 13:35:42 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 8A5763A6885 for ; Thu, 20 Aug 2009 13:35:42 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7KKZdNZ007999; Thu, 20 Aug 2009 13:35:41 -0700 (PDT)
Message-ID: <4A8DB398.2090903@isi.edu>
Date: Thu, 20 Aug 2009 13:35:36 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: L.Wood@surrey.ac.uk
References:  <4A8D95B4.3040209@isi.edu> <4835AFD53A246A40A3B8DA85D658C4BE01368955@EVS-EC1-NODE4.surrey.ac.uk>
In-Reply-To: <4835AFD53A246A40A3B8DA85D658C4BE01368955@EVS-EC1-NODE4.surrey.ac.uk>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 20 Aug 2009 20:35:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Lloyd,

L.Wood@surrey.ac.uk wrote:
> Can't TCP MSS also vary across multipath environments? 

Yes, but that's discovered by PMTUD. I think this doc is focusing more
on what the interface says is available - which ROHC might have an
effect on.

> Strikes me
> that these are more common than header compression - which should
> be advertising conservative minimum MTUs for their link interfaces.

I'm not sure what's more common, but they're separate effects AFAICT.

Joe

> -----Original Message-----
> From: tcpm-bounces@ietf.org on behalf of Joe Touch
> Sent: Thu 2009-08-20 19:28
> To: Eddy, Wesley M. (GRC-MS00)[Verizon]
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] WGLC for MSS document
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
> 
> Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
>> This note starts a 2-week Working Group Last Call on the TCPM document:
>> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
>> Please send any comments to the TCPM list.  The WGLC will last until
>> September 1.
> 
> I'd like to suggest the following for this doc:
> 
> MSSs can sometimes vary, as when used with variable compression, e.g.,
> ROHC. The ROHC doc missed an opportunity to address the interaction of
> variable MSS with TCP, and this might be a good place to include a
> sentence or two on it, e.g. (IMO):
> 
> - ---
> 
> MSSs can sometimes vary, as when used with variable compression, e.g.,
> ROHC [RFC5255]. It is tempting for TCP to want to advertise the largest
> possible MSS, to support the most efficient use of compressed payloads.
> Unfortunately, some compression schemes occasionally need to transmit
> full headers (and thus smaller payloads) to resynchronize state at their
> endpoint compressor/decompressors. If the largest MSS is advertised, TCP
> retransmission may interfere with compressor resynchonization.
> 
> As a result, when effective MSS varies, TCP SHOULD compute its
> advertised MSS based on the smallest effective MSS.
> 
> - ---
> 
> Joe
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqNs5gACgkQE5f5cImnZrubugCeJ4Kb4SsRAun/ywcbJ4ZgRL7o
uCUAoKu0j0eIMLSwj7GAqZH/184RSqoR
=7QTE
-----END PGP SIGNATURE-----

From root@core3.amsl.com  Mon Aug 24 15:15:01 2009
Return-Path: 
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id CF3CD3A6D3D; Mon, 24 Aug 2009 15:15:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090824221501.CF3CD3A6D3D@core3.amsl.com>
Date: Mon, 24 Aug 2009 15:15:01 -0700 (PDT)
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-06.txt
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Mon, 24 Aug 2009 22:15:01 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.


	Title           : ICMP attacks against TCP
	Author(s)       : F. Gont
	Filename        : draft-ietf-tcpm-icmp-attacks-06.txt
	Pages           : 37
	Date            : 2009-08-24

This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols.
Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these
issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tcpm-icmp-attacks-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-08-24150105.I-D@ietf.org>


--NextPart--

From wesley.m.eddy@nasa.gov  Tue Aug 25 09:17:00 2009
Return-Path: 
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 4004E3A67A8 for ; Tue, 25 Aug 2009 09:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.451
X-Spam-Level: 
X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599, 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 QFGIGS-0o4BB for ; Tue, 25 Aug 2009 09:16:59 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 5F10A3A6ABA for ; Tue, 25 Aug 2009 09:16:59 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 4801BAC76; Tue, 25 Aug 2009 11:17:03 -0500 (CDT)
Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n7PGH3Xg030331; Tue, 25 Aug 2009 11:17:04 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 25 Aug 2009 11:17:02 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
To: Joe Touch , Fernando Gont 
Date: Tue, 25 Aug 2009 11:17:03 -0500
Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document
Thread-Index: AcohwuOGrbF1dSPtQ7SU9PXJaVk8LQD2tPOQ
Message-ID: 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>
In-Reply-To: <4A8D939E.9050008@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-08-25_05:2009-08-11, 2009-08-25, 2009-08-25 signatures=0
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 16:17:00 -0000

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>Joe Touch
>Sent: Thursday, August 20, 2009 2:19 PM
>
>Then it'd be useful to break down TCP into its component parts, as
>introduced in 2a:
>
>	3 control attacks
>		header fields
>		option fields
>		connection establishment
>		connection termination
>		port scanning
>
>	4 data attacks
>		injection
>		info leaking
>
>	5 performance
>		cong control / ACK attacks
>		reassy attacks
>
>	6 implementation issues
>		performance, e.g., SYN cookies, buffer mgt.
>		API, IP interface issues
>
>	7 security considerations
>		this can be used as a catchall for items that don't
>		fit as directly above and aren't specific to TCP,
>		e.g., covert channel issues, info leaking etc.
>
>IMO, this presents the info in a way that is still organized for
>implementers, but structures it in a way that the info can be more
>easily located when needed.


I like the hierarchy that Joe suggests; it groups similar issues and
recommendations together, and I agree with  him that it would pose
no difficulty for implementers to use.

David had suggested that however the document content is organized,
an appendix can index the recommendations differently.  That makes
sense to me too, though from the standpoint of actually reading the
document itself, I think something like Joe's outline is much better.

However, my opinion isn't very strong on this, and I'm comfortable
with however this thread converges.


---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From fernando@gont.com.ar  Tue Aug 25 11:42:24 2009
Return-Path: 
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 1A7513A6C7E for ; Tue, 25 Aug 2009 11:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.825
X-Spam-Level: 
X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.774,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 sa3ionkibIgq for ; Tue, 25 Aug 2009 11:42:23 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B242C3A6B75 for ; Tue, 25 Aug 2009 11:42:18 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E711C6B680E; Tue, 25 Aug 2009 15:42:17 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7PIg4D1011237; Tue, 25 Aug 2009 15:42:06 -0300
Message-ID: <4A94307E.2080209@gont.com.ar>
Date: Tue, 25 Aug 2009 15:42:06 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu> 
In-Reply-To: 
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 25 Aug 2009 15:42:17 -0300 (ART)
Cc: "tcpm@ietf.org" , Joe Touch 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 18:42:24 -0000

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:


>> Then it'd be useful to break down TCP into its component parts, as
>> introduced in 2a:
>>
>> 	3 control attacks
>> 		header fields
>> 		option fields
>> 		connection establishment
>> 		connection termination
>> 		port scanning
[....]
> 
> I like the hierarchy that Joe suggests; it groups similar issues and
> recommendations together, and I agree with  him that it would pose
> no difficulty for implementers to use.

I think that for many attacks, the outline Joe is proposing becomes
ambiguous.

e.g., think about the "Rose attack" described in the MSS section. The
attack employs the TCP MSS option (and thus would be included in
"control attacks" according to Joe's outline). However, the attack
attempts to degrade performance. So.. where would the attack be finally
included?

Joe argues that "info leaking" and that port scanning is a "control
attack". But one might argue that port scanning is, in some sense, an
info leaking attack.


> David had suggested that however the document content is organized,
> an appendix can index the recommendations differently.  

I feel comfortable with David proposal, btw.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Aug 25 12:38:32 2009
Return-Path: 
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 C10593A69BB for ; Tue, 25 Aug 2009 12:38:32 -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 q4uwm2MkY2Kk for ; Tue, 25 Aug 2009 12:38:31 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A08623A6FEA for ; Tue, 25 Aug 2009 12:37:54 -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 n7PJZ6aY007464; Tue, 25 Aug 2009 12:35:08 -0700 (PDT)
Message-ID: <4A943CEA.4000905@isi.edu>
Date: Tue, 25 Aug 2009 12:35:06 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>  <4A94307E.2080209@gont.com.ar>
In-Reply-To: <4A94307E.2080209@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 19:38:32 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> 
> 
>>> Then it'd be useful to break down TCP into its component parts, as
>>> introduced in 2a:
>>>
>>> 	3 control attacks
>>> 		header fields
>>> 		option fields
>>> 		connection establishment
>>> 		connection termination
>>> 		port scanning
> [....]
>> I like the hierarchy that Joe suggests; it groups similar issues and
>> recommendations together, and I agree with  him that it would pose
>> no difficulty for implementers to use.
> 
> I think that for many attacks, the outline Joe is proposing becomes
> ambiguous.
> 
> e.g., think about the "Rose attack" described in the MSS section. The
> attack employs the TCP MSS option (and thus would be included in
> "control attacks" according to Joe's outline). However, the attack
> attempts to degrade performance. So.. where would the attack be finally
> included?
> 
> Joe argues that "info leaking" and that port scanning is a "control
> attack". But one might argue that port scanning is, in some sense, an
> info leaking attack.

That's a property of any way of organizing the topics - there are bound
to be overlapping cases. The issue to me is that the outline I proposed
has easily recognized structure to it, and I at least know where various
attacks should go (even if they go in one place and are cross-referenced
and also discussed in others).

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKlDzqE5f5cImnZrsRAsh4AKC6IVV3YsRKffKyhpT31tWy35TF2wCfdeR+
iZPojsKI6SCcBhmC2hM3Ubc=
=6s++
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Tue Aug 25 13:31:04 2009
Return-Path: 
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 D720428C20B for ; Tue, 25 Aug 2009 13:31:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.688,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 lFB4e8to+o+H for ; Tue, 25 Aug 2009 13:31:04 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E2B5B28C24E for ; Tue, 25 Aug 2009 13:31:02 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 86A406B6621; Tue, 25 Aug 2009 17:31:11 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7PKUvDK003625; Tue, 25 Aug 2009 17:30:58 -0300
Message-ID: <4A944A03.1090803@gont.com.ar>
Date: Tue, 25 Aug 2009 17:30:59 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar> <4A943CEA.4000905@isi.edu>
In-Reply-To: <4A943CEA.4000905@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 25 Aug 2009 17:31:10 -0300 (ART)
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 20:31:04 -0000

Joe Touch wrote:

>> e.g., think about the "Rose attack" described in the MSS section. The
>> attack employs the TCP MSS option (and thus would be included in
>> "control attacks" according to Joe's outline). However, the attack
>> attempts to degrade performance. So.. where would the attack be finally
>> included?
> 
>> Joe argues that "info leaking" and that port scanning is a "control
>> attack". But one might argue that port scanning is, in some sense, an
>> info leaking attack.
> 
> That's a property of any way of organizing the topics - there are bound
> to be overlapping cases. 

I don't think there's overlap in the current structure of the document.


> The issue to me is that the outline I proposed
> has easily recognized structure to it, and I at least know where various
> attacks should go (even if they go in one place and are cross-referenced
> and also discussed in others).

IMO, the issue here is not whether one knows where to put them, but
rather whether implementers would know where to find them.

IMHO, I'd live the main structure "as is", and would add an alternate
index (e.g., the one you proposed) in an appendix (as David suggested).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Aug 25 13:39:02 2009
Return-Path: 
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 46C683A6F96 for ; Tue, 25 Aug 2009 13:39:02 -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 UYBqeTyLn9wr for ; Tue, 25 Aug 2009 13:39:01 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 04E563A6C69 for ; Tue, 25 Aug 2009 13:39:01 -0700 (PDT)
Received: from [70.213.211.43] (43.sub-70-213-211.myvzw.com [70.213.211.43]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7PKacNF021239; Tue, 25 Aug 2009 13:36:40 -0700 (PDT)
Message-ID: <4A944B56.5080200@isi.edu>
Date: Tue, 25 Aug 2009 13:36:38 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar> <4A943CEA.4000905@isi.edu> <4A944A03.1090803@gont.com.ar>
In-Reply-To: <4A944A03.1090803@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 20:39:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> e.g., think about the "Rose attack" described in the MSS section. The
>>> attack employs the TCP MSS option (and thus would be included in
>>> "control attacks" according to Joe's outline). However, the attack
>>> attempts to degrade performance. So.. where would the attack be finally
>>> included?
>>> Joe argues that "info leaking" and that port scanning is a "control
>>> attack". But one might argue that port scanning is, in some sense, an
>>> info leaking attack.
>> That's a property of any way of organizing the topics - there are bound
>> to be overlapping cases. 
> 
> I don't think there's overlap in the current structure of the document.

The current document doesn't have the kind of structure I'm suggesting
is important.

>> The issue to me is that the outline I proposed
>> has easily recognized structure to it, and I at least know where various
>> attacks should go (even if they go in one place and are cross-referenced
>> and also discussed in others).
> 
> IMO, the issue here is not whether one knows where to put them, but
> rather whether implementers would know where to find them.
> 
> IMHO, I'd live the main structure "as is", and would add an alternate
> index (e.g., the one you proposed) in an appendix (as David suggested).

I don't see that as a useful way forward.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqUS1YACgkQE5f5cImnZrtyngCeIu1SCaxiA04zoWuvq3ap12lP
En0AoLemlz2eQCngpm/zpRZgN62iaZ/0
=sR5K
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Tue Aug 25 14:41:20 2009
Return-Path: 
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 174D43A6882 for ; Tue, 25 Aug 2009 14:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Level: 
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.619,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5KtA5XgX0MAi for ; Tue, 25 Aug 2009 14:41:19 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B9DB43A67F8 for ; Tue, 25 Aug 2009 14:41:17 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DFD146B65C5; Tue, 25 Aug 2009 18:41:26 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7PLf602007820; Tue, 25 Aug 2009 18:41:07 -0300
Message-ID: <4A945A72.7040303@gont.com.ar>
Date: Tue, 25 Aug 2009 18:41:06 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <4A8CBF98.1070809@gont.com.ar> <4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar> <4A943CEA.4000905@isi.edu> <4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu>
In-Reply-To: <4A944B56.5080200@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 25 Aug 2009 18:41:21 -0300 (ART)
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 25 Aug 2009 21:41:20 -0000

Joe Touch wrote:

>>> The issue to me is that the outline I proposed
>>> has easily recognized structure to it, and I at least know where various
>>> attacks should go (even if they go in one place and are cross-referenced
>>> and also discussed in others).
>> IMO, the issue here is not whether one knows where to put them, but
>> rather whether implementers would know where to find them.
> 
>> IMHO, I'd live the main structure "as is", and would add an alternate
>> index (e.g., the one you proposed) in an appendix (as David suggested).
> 
> I don't see that as a useful way forward.

Well, no need to say that I have no problem to change the outline if the
wg feels that's the best way forward....

Also, regardless of our possible disagreement on this issue, your input
is always appreciated.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From toby.moncaster@bt.com  Wed Aug 26 04:43:32 2009
Return-Path: 
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 318DF3A6AD5 for ; Wed, 26 Aug 2009 04:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level: 
X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=0.398,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Z7guLrz5iM-m for ; Wed, 26 Aug 2009 04:43:30 -0700 (PDT)
Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 2DEF33A6A24 for ; Wed, 26 Aug 2009 04:42:44 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 26 Aug 2009 12:41:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Aug 2009 12:40:29 +0100
Message-ID: 
In-Reply-To: <4A944B56.5080200@isi.edu>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [tcpm] tcp-security: Request for feedback on the outline of the document
Thread-Index: AcolxBs0HSBOzCEGQqWY1s2AssRguAAfTO3Q
References: <4A8CBF98.1070809@gont.com.ar><4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar><4A943CEA.4000905@isi.edu> <4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu>
From: 
To: , 
X-OriginalArrivalTime: 26 Aug 2009 11:41:12.0777 (UTC) FILETIME=[1CE24B90:01CA2642]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Wed, 26 Aug 2009 11:43:32 -0000

I definitely agree that Joe's structure looks more organised. As he =
points out, it is impossible to create a comprehensive structure that =
removes all overlap or contradictions. If you want this document to =
succeed (rather than join an ever-growing pile of RFCs that no-one =
outside the IETF have even read) then making it easily readable has to =
be the first requirement. A significant part of readability is the =
structure used to present the data in the document. It is always hard as =
an author to accept recommendations that seem to alter one's work so =
fundamentally but remember that other people are able to take a step =
back from the detail in a way you, as an author, may not find so easy.

Toby

____________________________________________________________________=20
Toby Moncaster,  Networks Research Centre, BT=20
B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20



> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf =
Of
> Joe Touch
> Sent: 25 August 2009 21:37
> To: Fernando Gont
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] tcp-security: Request for feedback on the outline
> of the document
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>=20
>=20
> Fernando Gont wrote:
> > Joe Touch wrote:
> >
> >>> e.g., think about the "Rose attack" described in the MSS section.
> The
> >>> attack employs the TCP MSS option (and thus would be included in
> >>> "control attacks" according to Joe's outline). However, the attack
> >>> attempts to degrade performance. So.. where would the attack be
> finally
> >>> included?
> >>> Joe argues that "info leaking" and that port scanning is a =
"control
> >>> attack". But one might argue that port scanning is, in some sense,
> an
> >>> info leaking attack.
> >> That's a property of any way of organizing the topics - there are
> bound
> >> to be overlapping cases.
> >
> > I don't think there's overlap in the current structure of the
> document.
>=20
> The current document doesn't have the kind of structure I'm suggesting
> is important.
>=20
> >> The issue to me is that the outline I proposed
> >> has easily recognized structure to it, and I at least know where
> various
> >> attacks should go (even if they go in one place and are cross-
> referenced
> >> and also discussed in others).
> >
> > IMO, the issue here is not whether one knows where to put them, but
> > rather whether implementers would know where to find them.
> >
> > IMHO, I'd live the main structure "as is", and would add an =
alternate
> > index (e.g., the one you proposed) in an appendix (as David
> suggested).
>=20
> I don't see that as a useful way forward.
>=20
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>=20
> iEYEARECAAYFAkqUS1YACgkQE5f5cImnZrtyngCeIu1SCaxiA04zoWuvq3ap12lP
> En0AoLemlz2eQCngpm/zpRZgN62iaZ/0
> =3DsR5K
> -----END PGP SIGNATURE-----
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

From mallman@icir.org  Wed Aug 26 06:59:26 2009
Return-Path: 
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 BF12F3A67DA for ; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Level: 
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211,  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 jTfdDSAbPbHj for ; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 145683A67B5 for ; Wed, 26 Aug 2009 06:59:26 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n7QDuvmi024562; Wed, 26 Aug 2009 06:56:57 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id AB7CA3C82EDD; Wed, 26 Aug 2009 09:56:47 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 00EF23F8684; Wed, 26 Aug 2009 09:56:50 -0400 (EDT)
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
From: Mark Allman 
In-Reply-To: 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Streets of Philadelphia
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma16160-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 26 Aug 2009 09:56:50 -0400
Sender: mallman@icir.org
Message-Id: <20090826135651.00EF23F8684@lawyers.icir.org>
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] WGLC for MSS document
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Aug 2009 13:59:26 -0000

----------ma16160-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


> This note starts a 2-week Working Group Last Call on the TCPM document:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-02
> Please send any comments to the TCPM list.  The WGLC will last until
> September 1.

I am in general in favor of this document.  But, this document is sorta
confusing to me and so I'd vote "not ready" at the moment.  

The statement that the MSS advertisement should not include the bytes
consumed by options is clear, but in the explanation of that rule.

  + I had to work through the table to figure out "length" on the y-axis
    was the overall packet length.

  + I find it strange that the table is left as the sole justification
    without even a little bit of prose that explains it.  In fact, I
    would think a little prose instead of the table would make the whole
    thing more clear.

  + The other thing you might note is that the MSS advertisement cannot
    possibly capture the right number of option bytes for every packet
    in a connection because options are variable (e.g., SACK).  So, even
    if one tries to capture option lengths in the header the length will
    still have to be hacked on the fly (or, you'll have to take a
    pessimal view of option usage as "using all of it").

FWIW.

allman




----------ma16160-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqVPyIACgkQWyrrWs4yIs5mWQCfaBiJTmIuYlHvWiwbQqxI/f4a
bGwAnR76guU+st1sgC7AEPCkE7XDl4FP
=hZEr
-----END PGP SIGNATURE-----
----------ma16160-1--

From mallman@icir.org  Wed Aug 26 07:01:28 2009
Return-Path: 
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 EC4463A6A8B for ; Wed, 26 Aug 2009 07:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.409
X-Spam-Level: 
X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190,  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 4QaV-H+TrjTc for ; Wed, 26 Aug 2009 07:01:28 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 4D13B3A67EF for ; Wed, 26 Aug 2009 07:01:28 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id n7QDxBoc024583; Wed, 26 Aug 2009 06:59:11 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id C10483C82EE2; Wed, 26 Aug 2009 09:59:01 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5BF5E3F86C0; Wed, 26 Aug 2009 09:59:05 -0400 (EDT)
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" 
From: Mark Allman 
In-Reply-To: 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Streets of Philadelphia
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma16297-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 26 Aug 2009 09:59:05 -0400
Sender: mallman@icir.org
Message-Id: <20090826135905.5BF5E3F86C0@lawyers.icir.org>
Cc: "tcpm@ietf.org" 
Subject: Re: [tcpm] WG status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Aug 2009 14:01:29 -0000

----------ma16297-1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


> Early-Retransmit
> http://tools.ietf.org/wg/tcpm/draft-ietf-tcpm-early-rexmt/
> Milestone Target: Experimental in July 2009
> Action: WGLC is finished; check if authors intend to update ... then
> send to IESG 

We have received two reviews (from Zimmerman & Touch) and intend to rev
the document based on those reviews.  (Right now this is on my docket
for late next week, but that's far enough out that Things Could Change.)

allman




----------ma16297-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqVP6kACgkQWyrrWs4yIs7wKgCgkphBIzyfRFKu/s5wjTyUi2bY
GAEAn2Q/5BdAfGvw8DF+ppIw+GxN1Nj0
=EUOC
-----END PGP SIGNATURE-----
----------ma16297-1--

From alexander.zimmermann@nets.rwth-aachen.de  Wed Aug 26 07:13:32 2009
Return-Path: 
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 6E3AF3A6BBD for ; Wed, 26 Aug 2009 07:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.41
X-Spam-Level: 
X-Spam-Status: No, score=-4.41 tagged_above=-999 required=5 tests=[AWL=0.391,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 0JE+3045inwI for ; Wed, 26 Aug 2009 07:13:31 -0700 (PDT)
Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 0FFE23A6A8B for ; Wed, 26 Aug 2009 07:12:37 -0700 (PDT)
MIME-version: 1.0
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KOZ0061PKHX0B10@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 26 Aug 2009 15:37:09 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.44,279,1249250400"; d="sig'?scan'208";a="23747586"
Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 26 Aug 2009 15:37:09 +0200
Received: from miami.nets.RWTH-Aachen.DE (miami.nets.RWTH-Aachen.DE [137.226.12.180])	by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n7QDb96T010670	for ; Wed, 26 Aug 2009 15:37:09 +0200 (CEST)
Message-id: 
From: Alexander Zimmermann 
To: tcpm@ietf.org
Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-11-256207881
Content-transfer-encoding: 7bit
Date: Wed, 26 Aug 2009 15:37:11 +0200
X-Pgp-Agent: GPGMail 1.2.0 (v56)
X-Mailer: Apple Mail (2.936)
Subject: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-02
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Wed, 26 Aug 2009 14:13:32 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-11-256207881
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

Hi folks,

I upload a new version of our draft to the IETF repository:
http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt

As always, comments are more than welcome.

Alex

---

Main change from draft-zimmermann-tcp-lcd-01

The algorithm in Section 4.2 was slightly changed. Instead of reverting
the RTO by halving it, it is recalculated with help of the "Backoff_cnt"
variable. This fixes an issue that occurred when the retransmission  
timer
was backed off but bounded by a maximum value. The algorithm in the
previous version of the draft, would have "reverted" to half of that
maximum value, instead of using the value, before the RTO was doubled
(and then bounded).

---

Filename:	 draft-zimmermann-tcp-lcd
Revision:	 02
Title:		 Make TCP more Robust to Long Connectivity Disruptions
Creation_date:	 2009-08-26
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
Disruptions in end-to-end path connectivity which last longer than
one retransmission timeout cause suboptimal TCP performance.  The
reason for the performance degradation is that TCP interprets segment
loss induced by connectivity disruptions as a sign of congestion,
resulting in repeated backoffs of the retransmission timer.  This
leads in turn to a deferred detection of the re-establishment of the
connection since TCP waits until the next retransmission timeout
occurs before attempting the retransmission.

This document describes how standard ICMP messages can be exploited
to disambiguate true congestion loss from non-congestion loss caused
by long connectivity disruptions.  Moreover, a revert strategy of the
retransmission timer is specified that enables a more prompt
detection of whether the connectivity to a previously disconnected
peer node has been restored or not.  The specified algorithm is a TCP
sender-only modification that effectively improves TCP performance in
presence of connectivity disruptions.


//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: zimmermann@cs.rwth-aachen.de
// web: http://www.umic-mesh.net
//


--Apple-Mail-11-256207881
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: Signierter Teil der Nachricht
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkqVOocACgkQdyiq39b9uS7IKQCgpuATZlOaJO52OqRjpfhHUY8F
Ig8AoN0cYCux6zPq/8tLRtSvn02MCXmM
=RrHK
-----END PGP SIGNATURE-----

--Apple-Mail-11-256207881--

From touch@ISI.EDU  Wed Aug 26 09:00:46 2009
Return-Path: 
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 92AE628C15D for ; Wed, 26 Aug 2009 09:00:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 OilpVCQ6ZeYJ for ; Wed, 26 Aug 2009 09:00:44 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D49863A709E for ; Wed, 26 Aug 2009 09:00:44 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7QG0YsY021945; Wed, 26 Aug 2009 09:00:35 -0700 (PDT)
Message-ID: <4A955C21.1010301@isi.edu>
Date: Wed, 26 Aug 2009 09:00:33 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Alexander Zimmermann 
References: 
In-Reply-To: 
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Mark Allman 
Subject: Re: [tcpm] Review: draft-ietf-tcpm-early-rexmt-01
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Wed, 26 Aug 2009 16:00:46 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Here is a copy of the review I sent to Mark, so others know what issues
I raised:

Overall, the doc reads well, and is well organized. I found it nicely
self-contained (an exception for most transport mod docs, IMO). The
motivation was clear, and I think the doc is in fairly good shape.

Constructive edit suggestions follow.

The intro is nicely done and self-contained. Gave me enough context to
understand the problem without needing to dig up numerous RFCs and read
portions thereof, which is an exception in TCPM AFAICT.

Regarding Jac88, it's useful to make sure you're referencing the right
paper. There are several versions of this doc, at least two are often
confused: the Sigcomm version (most often cited):
	http://portal.acm.org/citation.cfm?doid=205447.205462
	This is 16 pages, and has only a very brief appendices section

and an extended version that has a long appendix with footnotes (this is
the one that discusses idle times, too):
	http://ccr.sigcomm.org/archive/1995/jan95/ccr-9501-jacobson.html
	This one is 21 pages, and decidedly NOT a reprint (even with
	formatting changes) of the one published at Sigcomm 1988, 	
	despite the note on the web page.

The second version has most of the details that ended up in TCP
implementations, several of which have been dogging us for years (lack
of slow-start restart after idle in the Web in particular). I don't know
if this is the case for the issues you're citing it for, but it's
certainly worth a check.

The example on page three considers a window of three segments (FWIW, it
should probably read "a window of three segments' worth of data", since
windows are in bytes not segments). I'm wondering if ACK compression (as
required) affects the example. It's worth either fixing the example, or
addressing the effect of ACK compression (even if to clarify that there
is none) somewhere in the doc.

The data from BPS+98 implies that the bulk of RTOs can be avoided with
early rexmit. Is that true? Or could there be other reasons for large
numbers of RTOs that early rexmit won't help? If so, it'd be useful to
caveat the impact of the proposed mod. Also, this paragraph makes an
error I saw at the last TCPM meeting from the Google guy's talk - it
equates median transfer size with median TCP connection duration. HTTP
still has persistent connections, AFAIK, which mean that these aren't
correlated. The conclusion that non-RTO recovery would be useful may be
true for short transfers over persistent connections, not just short TCP
connections (which is how I read "short TCP transfers", since a TCP
transfer is over when the FIN sings  ;-)

Section 2 again starts with math that appears to assume ACK per segment
(maybe I'm not catching this - maybe it's that ACKs aren't compressed --
or compressable -- when the data comes out of order, but that's worth
noting if so. Sorry, I figure you know this better than I do, so I'll
ask you before I dig into figuring it out. Let me know if you want me to
dig as well...).

Section 2 talks about TCP in bytes and SCTP in messages, neither one in
segments. It might be useful to put in enough context there, e.g., that
SCTP includes message boundaries, but that they don't correspond to
segment boundaries (right?).

Doublecheck the term 'packet' throughout; I think you mean segments
(i.e., TCP segments don't necessarily map to IP packets, e.g., given
fragmentation).

Sec 2 talks about additional state at the sender for precision; this is
the first time you mention a side-specific cost. It might be useful to
hint earlier whether you are doing a send-side, receiver-side, or
require mods on both sides to achieve a benefit. Seems like it's all
send-side, but the benefit is receiver-side. Also worth noting that this
then would allow widescale impact by deploying this at busy servers,
avoiding per-client deployment for benefit.

In 2.1, do you want to define this in terms a fixed value of 4*SMSS, or
define it as a pointer (i.e., to the initial CWND, so if init CWND
increases, so does this?) same for the part about packet-based (again,
would that be segment-based?) not referring to 4, but the number of
segments in the initial CWND (e.g., as "currently 4" -- PS, should that
be 4, or shouldn't it be "initial_CWND/SMSS", i.e., a max of 4, but in
most current cases it seems like this would still be 3).

(2.b) should call it the 'advertised receive window' (or
receiver-advertised window, whatever is more common) for clarity

These rules (2.a, 2.b) seem odd in the context of saying this is a MAY
for SCTP (above the list) and then have a different set of rules in the
paragraph below (end of page 4). IMO, put in two different rulesets
(ditto for section 3, FWIW):

	1. TCP without SACK or for connections not supporting SACK

	2. TCP with SACK and SCTP

This would avoid the self-reference to Early Rexmit in the last
paragraph, which is (AFAICT, again), not yet defined. Did you mean to
define it above:

    When the above two conditions hold and the connection does not
    support SACK the duplicate ACK threshold used to trigger a
    retransmission MUST be reduced to:

                  ER_thresh = ceiling (ownd/SMSS) - 1

I would add "we call this reduced ACK threshhold enabling 'Early
Retransimission',and when a retransmission occurs because of ER_thresh,
we call that an Early Retransmission.", even if you split out the rules
for non-SACK and SACK. This allows you to refer to it at the top of page
5 correctly, since it would now be defined.

Also, maybe I'm missing something, but I searched for ER_thresh all over
the place. It isn't *used* anywhere. I.e., you define a variable but
never use it. Seems like you need to use it where you say "the timer
(ER_thresh) goes off and ..." somewhere specific. However, you say that
you're lowering the fast rexmit threshold. So then wouldn't you be
setting "FR_thresh", not "ER_thresh"? Even if so, it's useful to recap
how the *_thresh value is used.

The examples on page 5 need to include a bit about Nagle; if Nagle is
on, you would never have three outstanding 400-byte segments  ;-)

When you talk about packet-based rexmit, did you want to say as well
that "a TCP or SCTP that implements packet-based rexmit MUST NOT also
implement byte-based rexmit", i.e., that packet-based rexmit supecedes
byte-based rexmit? I could see the two MAYs being considered
simultaneously, and that would be bad, no?

When you say MUST NOT use ER, do you mean to use FR (fast) and LR
(Limited), or is LR a superset of FR?

Not sure about the explanation of the circular list for keeping track of
segment boundaries. You say "fall within this region", but with SACK the
region can be disconnected, so I'm not sure how to interpret "region".
Also, seems like you need to know the length of the segments too, no?
You can't assume they're all the same size...

Which brings me to a wrinkle - what happens if TCP resends data with
different segment sizes, resulting in some segments being on different
boundaries than those that may already be received (e.g., on multipath
when a PMTU update comes in, and data is resent and resegmented
differently). Your segment alg needs to be robust to this, or you need
to explain why that doesn't matter.

Sec 3 (Discussion) should start with an overview of what you intend to
discuss. Are these all issues? Do you want to say the benefits too?
Impact on legacy receivers (if any)? Deployment motivation (who does it
benefit, and who does the work?) Deployment asymmetry? etc. I'd then
break the section down to these sorts of topics (e.g., benefits, impact
of failure, deployment). (right now you jump in to the details of the
preferred variant - which IMO belongs in the packet-based section, not
here, then jump to the impact of failure without giving examples of
benefit first)

The SACK preference discussion needs more lead-in. The first paragraph
could easily be broken into three paragraphs with better context, and
would make the argument more clear.

Related work needs an intro. I.e., that ECN avoids dropping the segments
in the first place (which benefits TCP in many ways, but notably avoids
cases that would currently take an RTO to recover), and other ways to
cope with not having data to send (which implies loss, but different
ways to recover). Also, doesn't the second one (Bal98) also result in a
self-attack, i.e., it opens the CWND because an additional ACK will be
received, even though no data is sent? I.e., there's a side-effect to
this that is probably worth avoiding... (separate question - has anyone
noted that 0-window segment ACKs shouldn't open the window, or is that
already the case?)

Other considerations: seems like you're making TCP send more segments
into the net when data is being lost, vs. the existing mechanisms. If
that's the case, and if loss is due to buffer overload, are you making
things potentially worse? If not, please explain.

I don't see why you have a normative reference to Eiffel; you don't
depend on it that way. Seems like that's an informational reference in
this case - esp. since you refer to it in the appendix discussing
research options, not the body.

- ----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqVXCEACgkQE5f5cImnZrvEyACgheiAH9eYdDEHEOqtdU3aKt25
vzEAn26+gQX6fP4unRIFs3vqGm8LlqwK
=sX93
-----END PGP SIGNATURE-----

From A.Hoenes@tr-sys.de  Wed Aug 26 15:38:47 2009
Return-Path: 
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 DD25A3A63CB for ; Wed, 26 Aug 2009 15:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.74
X-Spam-Level: **
X-Spam-Status: No, score=2.74 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 AnSCafeMEZ7l for ; Wed, 26 Aug 2009 15:38:47 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id B47D53A6AB0 for ; Wed, 26 Aug 2009 15:38:45 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA260446292; Thu, 27 Aug 2009 00:38:12 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA06336; Thu, 27 Aug 2009 00:38:11 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= 
Message-Id: <200908262238.AAA06336@TR-Sys.de>
To: tcpm@ietf.org
Date: Thu, 27 Aug 2009 00:38:10 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Wed, 26 Aug 2009 22:38:47 -0000

Folks,
I strongly disagree with Joe's proposal.
For detailed rationale see below.

Furthermore, the envisioned procedure for the treatment of the
document is perceiced as discriminating; it gives much more
influence to WG participants with an always open time budget, who
can continually follow the discussion and participate quickly,
and it makes contributing by folks like me (who have a 'bursty'
primary business and can only spend cycles for IETF purposes
irregularly) rather difficult and/or inefficient.
Starting this important work, with very short timelines, during
the major summer vacation period is even more unfortunate.
The apparent outcome I observe is that very few but very active
voices already have started majorizing the discussion, and that
I have not heard voices of implementers recently.


Regarding document structure:

The various past reviewers of the original document had
appreciated the focus on implementer's point of view, which
is closely related to the document structure, and among those
reviewers were quite a couple of implementers.

For instance, when implementing checks on a protocol field,
a comprehensive discussion of the properties of that field
is needed, with a summary of known attacks using that field,
and a presentation of restrictions and extensibility properties
of such field, in order to allow the reader to easily make an
educated decision on what checks to implement and what possible
other related hardening measures/knobs for his/her implementation
are needed.
Scattering that information throughout the document will make
the utility of the document highly questionable.
BTW: I could not even see where the fundamental basic discussion
of protocol field properties might be located in the stucture
Joe proposed.

IMO, far-reaching structural changes should only be applied with
strong support from the TCP implementers' community.


As a mathematician, I have a strong preference for a bottom-up
document structure, starting with the definitions and proceeding
to the properties and gradually more complex conclusions;
in the context of protocol design and implementation, that means
a good document (after a short overview) should start with the
basic data structures and protocol fields.
The worst documents I ever had to read and understand were those
that gave the basics last (e.g., many OSPF documents, defining
the PDU fields and formats in Appendices -- ugly!)

Fernando's outline roughly follows that natural bottom-up paradigm,
starting with the PDUs and the field properties, specific attacks
related to each single field, and general considerations regarding
particular groups of fields -- that's what will go into header
files (in 'C' implementations) and low-level code;
then the original outline proceeds to major procedures to be
implemented (connection setup and teardown, data buffer and data
segment management, congestion control, 'abstract' / socket API
-- modules that typically will have identifiable components in an
implementation and which hence are worth a high-level block of
discussion in a document useful for implementers;
the final chapters discuss more general topics spanning multiple
of the previous topics, and the final chapters regarding ICMP
and the interface to IP help to align with related protocol
components -- you know, strict layer separation isn't a
property of TCP/IP!


There are indeed details to be discussed, e.g., whether the
section on TCP Options better be a subsection of the preceding
section.
IMO, that's not a good idea; the basic TCP Header is mandatory
and (almost) static, it won't change -- even in the long term
future evolution of TCP --, whereas TCP Options are a truly
optional ensemble subject to yes/no implementation decisions;
option design is an ongoing effort making it worth to separate
TCP Options off the basic TCP Header for the exposition, allowing
to discuss general topics specific to these circumstances there.

However, I suggest to re-organize the subsections on the src/dst
port fields:
A general discussion of port numbers, including server ports vs.
(ephemeral) client ports, and the case (and pros/cons) of
(symmetric) peer-to-peer applications operation with fixed port
numbers on both sides should precede the discussion of the
src and dst prot number fields, because the logical properties
of the port numbers (as mentioned above) are not bound to their
per-packet role as src/dst.


In any case, the document structure should be such that
important details can be located in the Table of Contents.
The RFC Editor usually limits the ToC to a certain nesting level
(based on style and available tools); therefore, nesting sections
too deeply should be avoided in favor of more primary sections.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From fernando@gont.com.ar  Wed Aug 26 21:41:49 2009
Return-Path: 
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 D50FD28C124 for ; Wed, 26 Aug 2009 21:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.036
X-Spam-Level: 
X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=0.563,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 jd2QsPgSH5VY for ; Wed, 26 Aug 2009 21:41:48 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9FCA03A6A4B for ; Wed, 26 Aug 2009 21:41:46 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A84B96B6A22; Thu, 27 Aug 2009 01:41:56 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7R4fa4J008705; Thu, 27 Aug 2009 01:41:36 -0300
Message-ID: <4A960E85.8000608@gont.com.ar>
Date: Thu, 27 Aug 2009 01:41:41 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: toby.moncaster@bt.com
References: <4A8CBF98.1070809@gont.com.ar><4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar><4A943CEA.4000905@isi.edu>	<4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu> 
In-Reply-To: 
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 27 Aug 2009 01:41:55 -0300 (ART)
Cc: tcpm@ietf.org, touch@ISI.EDU
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 27 Aug 2009 04:41:49 -0000

Hello, Toby,

> I definitely agree that Joe's structure looks more organised. As he
> points out, it is impossible to create a comprehensive structure that
> removes all overlap or contradictions. If you want this document to
> succeed (rather than join an ever-growing pile of RFCs that no-one
> outside the IETF have even read) then making it easily readable has
> to be the first requirement. A significant part of readability is the
> structure used to present the data in the document. 

Before bringing this document to the IETF, most major vendors (including
Cisco, Juniper, Microsoft, and others) received a copy of it, and had
the chance to review it. Nobody complained about the document
outline/structure. Actually, they were very happy with it. So I'd argue
that *more* people from *outside* the IETF has read the document than
the people that



> It is always hard
> as an author to accept recommendations that seem to alter one's work
> so fundamentally but remember that other people are able to take a
> step back from the detail in a way you, as an author, may not find so
> easy.

A few comments/clarifications with respect to your note:

* My disagreement with the structure proposed by Joe should not be taken
as me "not accepting recommendations". As a wg participant, I guess I
can still have an opinion that differs from that of others'. That
doesn't mean that I won't accept recommendations when they reflect wg
consensus or are obvious improvements to the document.

* The current version of the document was thoroughly reviewed during two
years. Among the reviewers were many implementers, many of which are
listed in the "Acknowledgements" section. *Lots* of changes were made in
response to the feedback I got. Even during the last couple of months
before the official release of the UK CPNI version of it, I added around
15 pages in response to the feedback I received.

* I have always welcomed reviews of the document. For instance, I tried
to get reviews from the people that were likely to object the document
or suggest changes. e.g., I asked Joe myself to review the document
(both this TCP one and the IP counterpart)... even before the first IETF
Internet-Draft version of this document was published. I also asked
Alfred (whose reviews usually lead to lots and lots of changes) to
review the document, and I had to make lots of changes (in the
organization, prose, technical contents, etc.) and even had to add more
than ten pages at the last minute before publication to address
virtually all his comments.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Wed Aug 26 22:48:37 2009
Return-Path: 
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 D1DA73A6D5A for ; Wed, 26 Aug 2009 22:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  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 l95dLaJbAh+q for ; Wed, 26 Aug 2009 22:48:36 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DD85128C101 for ; Wed, 26 Aug 2009 22:48:26 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7R5loEl017581; Wed, 26 Aug 2009 22:47:51 -0700 (PDT)
Message-ID: <4A961E05.4020100@isi.edu>
Date: Wed, 26 Aug 2009 22:47:49 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont 
References: <4A8CBF98.1070809@gont.com.ar><4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar><4A943CEA.4000905@isi.edu>	<4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu>  <4A960E85.8000608@gont.com.ar>
In-Reply-To: <4A960E85.8000608@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 27 Aug 2009 05:48:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Hello, Toby,
> 
>> I definitely agree that Joe's structure looks more organised. As he
>> points out, it is impossible to create a comprehensive structure that
>> removes all overlap or contradictions. If you want this document to
>> succeed (rather than join an ever-growing pile of RFCs that no-one
>> outside the IETF have even read) then making it easily readable has
>> to be the first requirement. A significant part of readability is the
>> structure used to present the data in the document. 
> 
> Before bringing this document to the IETF, most major vendors (including
> Cisco, Juniper, Microsoft, and others) received a copy of it, and had
> the chance to review it.

It'd be useful to get input from a high-end server vendor. I would value
their input on TCP security/performance issues more.

As to input from outside the IETF, they're welcome to participate here.
The feedback from the meeting in Stockholm was to start with an outline,
and work the outline first, which is what I thought we were doing.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqWHgUACgkQE5f5cImnZrurygCdFS+NJhwcy/1zDEd/SVmMrFpP
fcYAoNRkBl7HTCbLU4FUTULDWqXVFsk8
=fXjO
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Wed Aug 26 23:02:01 2009
Return-Path: 
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 2DCA93A6CC6 for ; Wed, 26 Aug 2009 23:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.783
X-Spam-Level: 
X-Spam-Status: No, score=-2.783 tagged_above=-999 required=5 tests=[AWL=0.216,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Kj8N+kpBYReK for ; Wed, 26 Aug 2009 23:02:00 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 345413A6C0E for ; Wed, 26 Aug 2009 23:01:58 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 4C6256B6AAB; Thu, 27 Aug 2009 03:02:10 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7R61dX9006939; Thu, 27 Aug 2009 03:01:48 -0300
Message-ID: <4A962148.5050100@gont.com.ar>
Date: Thu, 27 Aug 2009 03:01:44 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <4A8CBF98.1070809@gont.com.ar><4A8D939E.9050008@isi.edu>		<4A94307E.2080209@gont.com.ar><4A943CEA.4000905@isi.edu>	<4A944A03.1090803@gont.com.ar> <4A944B56.5080200@isi.edu>  <4A960E85.8000608@gont.com.ar> <4A961E05.4020100@isi.edu>
In-Reply-To: <4A961E05.4020100@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 27 Aug 2009 03:02:08 -0300 (ART)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 27 Aug 2009 06:02:01 -0000

Joe Touch wrote:

>> Before bringing this document to the IETF, most major vendors (including
>> Cisco, Juniper, Microsoft, and others) received a copy of it, and had
>> the chance to review it.
> 
> It'd be useful to get input from a high-end server vendor. I would value
> their input on TCP security/performance issues more.

Anyone you're thinking of? Do let me know, and I will do my best to get
them involved.



> As to input from outside the IETF, they're welcome to participate here.
> The feedback from the meeting in Stockholm was to start with an outline,
> and work the outline first, which is what I thought we were doing.

One might argue that we had already adopted the document by that point
(e.g., see the chair's slides). So in some sense one might argue that
zero'ing the contents of the document and moving the structure around is
sort of going backwards. Nevertheless, I'm always open to do whatever it
takes to improve the document.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Wed Aug 26 23:17:02 2009
Return-Path: 
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 62A333A6A95 for ; Wed, 26 Aug 2009 23:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018,  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 wTA3k80387bY for ; Wed, 26 Aug 2009 23:17:01 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4EDAA3A690A for ; Wed, 26 Aug 2009 23:17:01 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7R6GijF023183; Wed, 26 Aug 2009 23:16:45 -0700 (PDT)
Message-ID: <4A9624CB.6040203@isi.edu>
Date: Wed, 26 Aug 2009 23:16:43 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Alfred_=3F?= 
References: <200908262238.AAA06336@TR-Sys.de>
In-Reply-To: <200908262238.AAA06336@TR-Sys.de>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Thu, 27 Aug 2009 06:17:02 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Alfred ? wrote:
...
> Regarding document structure:
> 
> The various past reviewers of the original document had
> appreciated the focus on implementer's point of view,...

This is a good point. This isn't just an implementer's guide, however.
Some of the issues are being discussed in detail for the first time in
this doc.

I.e., there are two separate issues:

1) what are the vulnerabilities

2) how to address the vulnerabilities

Some of the ways to address vulnerabilities are choices that the specs
left open to implementers. Some are weaknesses in the protocol itself
that a clever implementation can overcome (e.g. SYN cookies to overcome
the state introduced at SYN receipt). Others are created by inefficient
implementations (e.g., badly implemented TIME-WAIT state lists).

The first two are useful to discuss in a general outline form. The last
can be covered separately, since it's just bad coding to be avoided, and
often there are common causes (buffer overrun, bounds checking,
efficiency of lists).

The original outline I proposed was:

	1 intro
	2 background
	3 control attacks
	4 data attacks
	5 performance
	6 implementation issues
	7 security considerations

Based on the above, I'd update to be more like:

	1 intro
	2 background
	3 attacks
	  a in-band control plane (TCP header/options)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  b out-of-band control plane (ICMP)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c data plane
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c API
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	4 mitigations
	  a in-band control plane (TCP header/options)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  b out-of-band control plane (ICMP)
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c data plane
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	  c API
	    i   protocol weaknesses
	    ii  implementer's choice weaknesses
	5 implementations to avoid
	  a that create direct vulnerabilities
	  b that create performance vulnerabilities
	6 security issues

The last section (6) includes topics of security interest that are not
specific to a field, e.g., covert channel issues.

...
> BTW: I could not even see where the fundamental basic discussion
> of protocol field properties might be located in the stucture
> Joe proposed.

Protocol fields are part of the header, so they are "control attacks",
and listed among the items that would be covered in section 3.

In the submitted I-D, protocol field properties are covered in sections
3,5,8,9,11,13,14,15. That is the issue the outline I proposed is
intended to address. Note that the outline I proposed didn't leave
things out; it was intended to organize things so that they tended to
fall into expected categories.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqWJMsACgkQE5f5cImnZruAVACfXkBqsR2WbjB9wAIvuGP6t1Br
1hQAoJdjGqIAXwyKOm7s+tpR2L8Bm2F/
=MEdd
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Fri Aug 28 19:39:14 2009
Return-Path: 
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 857053A6878 for ; Fri, 28 Aug 2009 19:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Level: 
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 QsQF67kTEJKk for ; Fri, 28 Aug 2009 19:39:13 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3BB433A6806 for ; Fri, 28 Aug 2009 19:39:12 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EED4B6B681D; Fri, 28 Aug 2009 23:39:23 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n7T2d470008071; Fri, 28 Aug 2009 23:39:05 -0300
Message-ID: <4A9894C3.4020300@gont.com.ar>
Date: Fri, 28 Aug 2009 23:38:59 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu>
In-Reply-To: <4A9624CB.6040203@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Fri, 28 Aug 2009 23:39:22 -0300 (ART)
Cc: Alfred ? , tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Sat, 29 Aug 2009 02:39:14 -0000

Joe Touch wrote:

>> The various past reviewers of the original document had
>> appreciated the focus on implementer's point of view,...
> 
> This is a good point. This isn't just an implementer's guide, however.
> Some of the issues are being discussed in detail for the first time in
> this doc.

The latter is true, but the document is still meant to target
implementers. If you spread the advice on a per-attack basis, or on a
protocol-weaknesses vs. implementer's-choice-weaknesses, you're
basically spreading the advice about a single protocol field or option
among multiple sections.

As an implementer, you don't want that. You want the whole advice in a
single place. You want to know everything that can go wrong with a
specific protocol-field or option (or mechanism, for instance), so that
you can easily convert that advice into code.

Spreading the advice on specific fields or options (or mechanisms) among
several sections would be a nightmare for anybody wanting to use this
document for hardening a TCP implementation (which is the target of this
document in the first place).



> Some of the ways to address vulnerabilities are choices that the specs
> left open to implementers. Some are weaknesses in the protocol itself
> that a clever implementation can overcome (e.g. SYN cookies to overcome
> the state introduced at SYN receipt). Others are created by inefficient
> implementations (e.g., badly implemented TIME-WAIT state lists).

What's the difference in here? Are we concerned about "who gets the blame"?

Again, if you are an implementer, and you're e.g. hacking the ACK
processing code, you want to know all you need to do with the field
(sanity checks, whatever), exactly. Whether the advice is considered an
implementer's BCP or a fix to the protocol, doesn't matter. Your TCP is
resilient, or it is not. That's what matters.



> In the submitted I-D, protocol field properties are covered in sections
> 3,5,8,9,11,13,14,15. 

I disagree. Protocol field properties are covered in Sections 3 and 4.
e.g., Sections 5 through 9 cover specific mechanisms or policies, but
not the fields themselves.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Sun Aug 30 10:24:31 2009
Return-Path: 
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 D08003A6BB6 for ; Sun, 30 Aug 2009 10:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.282
X-Spam-Level: 
X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_50=0.001]
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 b9e4tCd0lfMp for ; Sun, 30 Aug 2009 10:24:30 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A54613A6AF4 for ; Sun, 30 Aug 2009 10:24:30 -0700 (PDT)
Received: from [192.168.1.47] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n7UHOI5h026340; Sun, 30 Aug 2009 10:24:20 -0700 (PDT)
Message-ID: <4A9AB5C2.4090209@isi.edu>
Date: Sun, 30 Aug 2009 10:24:18 -0700
From: Joe Touch 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Fernando Gont 
References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu> <4A9894C3.4020300@gont.com.ar>
In-Reply-To: <4A9894C3.4020300@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Alfred ? , tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Sun, 30 Aug 2009 17:24:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> The various past reviewers of the original document had
>>> appreciated the focus on implementer's point of view,...
>> This is a good point. This isn't just an implementer's guide, however.
>> Some of the issues are being discussed in detail for the first time in
>> this doc.
> 
> The latter is true, but the document is still meant to target
> implementers. If you spread the advice on a per-attack basis, or on a
> protocol-weaknesses vs. implementer's-choice-weaknesses, you're
> basically spreading the advice about a single protocol field or option
> among multiple sections.

Maybe - some fields are susceptible to only a small set of attacks that
may be related. However, we'd also be allowing (if not encouraging) use
of protections as appropriate, rather than encouraging everyone to
implement every protection - some of which are not agreed as recommended
by the WG.

...
>> Some of the ways to address vulnerabilities are choices that the specs
>> left open to implementers. Some are weaknesses in the protocol itself
>> that a clever implementation can overcome (e.g. SYN cookies to overcome
>> the state introduced at SYN receipt). Others are created by inefficient
>> implementations (e.g., badly implemented TIME-WAIT state lists).
> 
> What's the difference in here? Are we concerned about "who gets the blame"?

This doc isn't only useful to implementers. People developing specs care
about #1 - maybe these are holes to be filled. #2 can result in
interactions between the solution and the protocol that were unintended.
#3 is just good design.

An implementer needs to know when they're playing inside a box the spec
created (#1), playing around in ways that could affect the protocol now
or in the future (#2), or just need to apply known algorithms rather
than modify the protocol.

...
>> In the submitted I-D, protocol field properties are covered in sections
>> 3,5,8,9,11,13,14,15. 
> 
> I disagree. Protocol field properties are covered in Sections 3 and 4.
> e.g., Sections 5 through 9 cover specific mechanisms or policies, but
> not the fields themselves.

Well, I found 8 places. You found 2 places at least, if not another 2
for a total of 4 (I don't care whether it's a mechanism or policy, if it
affects the field).

The point is that in the outline proposed in ID-0, there are multiple
top-level sections where these issues are discussed. The idea that "an
implementer wants to find things in one place" is fine, but IMO the
outline I proposed may to a mode useful job of aggregating this
information than ID-0.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqatcIACgkQE5f5cImnZrsKVwCePmS9DAO6Xxt4+weErbm/wBRL
YnwAn2awO7qNPzPmrhn4LsJZR9bt3htO
=+qJs
-----END PGP SIGNATURE-----

From ilpo.jarvinen@helsinki.fi  Mon Aug 31 07:47:37 2009
Return-Path: 
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 1CC3F3A6AD1 for ; Mon, 31 Aug 2009 07:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.872
X-Spam-Level: 
X-Spam-Status: No, score=-5.872 tagged_above=-999 required=5 tests=[AWL=0.427,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Y9fGiZ-ib3-C for ; Mon, 31 Aug 2009 07:47:36 -0700 (PDT)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 31D793A68D5 for ; Mon, 31 Aug 2009 07:47:35 -0700 (PDT)
Received: from wel-95.cs.helsinki.fi (wel-95.cs.helsinki.fi [128.214.10.211]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 31 Aug 2009 17:47:45 +0300 id 00063E36.4A9BE291.00006DDA
Date: Mon, 31 Aug 2009 17:47:45 +0300 (EEST)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" 
X-X-Sender: ijjarvin@wel-95.cs.helsinki.fi
To: Alexander Zimmermann 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org
Subject: Re: [tcpm] New Version Notification for draft-zimmermann-tcp-lcd-02
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Mon, 31 Aug 2009 14:47:37 -0000

On Wed, 26 Aug 2009, Alexander Zimmermann wrote:

> I upload a new version of our draft to the IETF repository:
> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt
>
> As always, comments are more than welcome.

I did read throught -01 before -02 was made available and I quickly went 
through the diffs for -02 (and also did read -00 earlier, was among those 
who had read it). I support adopting this id as WG item. After reviewing 
the Linux implementation too, I'd say it looks very straightforward, 
simple and clean to implement too (with rather little effort).

Then some comments:

2., 2nd paragraph.
I somewhat feel a bit strange on the importance that is placed in this ID 
for I-D.schuetz-... in defining the meaning "short" and "long" 
connectivity disruptions.

3., 2nd to last paragraph.
"This may very well be the case when TCP is recovering lost segments (...)."
It's very unclear to me whether you mean negative or positive statement 
here with the unclarity associated the use of "This".

4.2., 1st paragraph.
"... a timeout-based loss recovery has already been started but not 
completed". Are you sure that it is crystal clear what "not completing"
"timeout-based loss recovery" means?

4.2., the algorithm itself.
Why not just increase backoff_cnt unconditionally on rto and provide the 
proper cap in the "RTO := RTO_base * 2^(Backoff_cnt)" formula? It makes 
very little difference in practice and arquably can even be considered to 
be more "safe" to count lost retransmissions correctly if the rto cap was 
reached (and bypassed) before any icmps did come?

4.2., last paragraph.
IMHO the change to the "new started retransmission timer" isn't that good, 
however, I agree that changing it to something is necessary as the 
the previous use of "RTO" wasn't that good either. Perhaps something like 
"shortened" would be a good replacement to the "started"?

4.3., 4th paragraph.
A self-reference (see Section 4.3)?

Same paragraph.
I think that the sentence starting with "However, " is mis-comma'fied.

4.3., 5th paragraph.
Isn't it enough that any TCP flow with the same 4-tuple matches with
previous one's seqno (not required to be exactly the same flow with the 
correct seqno)? ...I guess it is most likely to happen with the same flow 
though.


Nits:

An revert -> A revert (2.)
..., back offs -> ..., backs off (4.2.)
scheme flood -> scheme to flood (7.)
to attempt to maliciously -> in attempt to maliciously (7.) ?


-- 
  i.

From fernando@gont.com.ar  Mon Aug 31 22:34:09 2009
Return-Path: 
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 0B5DF3A6EBA for ; Mon, 31 Aug 2009 22:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Level: 
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ipBnNOTJD2XP for ; Mon, 31 Aug 2009 22:34:08 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 967F63A6E1B for ; Mon, 31 Aug 2009 22:34:06 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7DAA46B6600; Tue,  1 Sep 2009 02:34:24 -0300 (ART)
Received: from [192.168.0.136] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n815Y0a1020393; Tue, 1 Sep 2009 02:34:01 -0300
Message-ID: <4A9CB254.7050802@gont.com.ar>
Date: Tue, 01 Sep 2009 02:34:12 -0300
From: Fernando Gont 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Joe Touch 
References: <200908262238.AAA06336@TR-Sys.de> <4A9624CB.6040203@isi.edu>	<4A9894C3.4020300@gont.com.ar> <4A9AB5C2.4090209@isi.edu>
In-Reply-To: <4A9AB5C2.4090209@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 01 Sep 2009 02:34:23 -0300 (ART)
Cc: Alfred ? , tcpm@ietf.org
Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document
X-BeenThere: tcpm@ietf.org
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: , 
X-List-Received-Date: Tue, 01 Sep 2009 05:34:09 -0000

Hello, Joe,

>> The latter is true, but the document is still meant to target
>> implementers. If you spread the advice on a per-attack basis, or on a
>> protocol-weaknesses vs. implementer's-choice-weaknesses, you're
>> basically spreading the advice about a single protocol field or option
>> among multiple sections.
> 
> Maybe - some fields are susceptible to only a small set of attacks that
> may be related. 

That's the exception, not the rule.


> However, we'd also be allowing (if not encouraging) use
> of protections as appropriate, rather than encouraging everyone to
> implement every protection - 

Joe, this is about hardening a TCP implementation, not about mitigating
some vulnerabilities while leaving the door open to the rest of them.



> An implementer needs to know when they're playing inside a box the spec
> created (#1), playing around in ways that could affect the protocol now
> or in the future (#2), or just need to apply known algorithms rather
> than modify the protocol.

Exactly. That's why the document does not simply provide the "what to
do", but also provides a discussion of the mitigations, etc.

But the document is still aimed at implementers. A bunch of implementers
have already reviewed the document, and found the current outline useful.



> The point is that in the outline proposed in ID-0, there are multiple
> top-level sections where these issues are discussed. The idea that "an
> implementer wants to find things in one place" is fine, but IMO the
> outline I proposed may to a mode useful job of aggregating this
> information than ID-0.

Again: the goal of this document is helping TCP implementers harden
their TCPs. And for that target, having everything about a protocol
field in a single place is the only document outline that does not get
in the middle of the developer and the implementation. If you spread the
advice among lots of places, this is what will happen: some mitigations
will be missed.

I'm not saying the outline you propose is "wrong". I'm saying it's not
the best approach for the public this document targets. That doesn't
mean that an alternative outline can be included in an appendix. -- that
may be useful.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1