From A.Hoenes@TR-Sys.de Mon Mar 1 14:00:04 2010 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 78F4A28C5D2 for ; Mon, 1 Mar 2010 14:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.751 X-Spam-Level: ** X-Spam-Status: No, score=2.751 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, 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 ywZUs+5fXNbc for ; Mon, 1 Mar 2010 14:00:03 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id DD8AA28C1A4 for ; Mon, 1 Mar 2010 14:00:01 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA211010777; Mon, 1 Mar 2010 22:59:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA15069; Mon, 1 Mar 2010 22:59:35 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003012159.WAA15069@TR-Sys.de> To: wesley.m.eddy@nasa.gov, tcpm@ietf.org Date: Mon, 1 Mar 2010 22:59:34 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 01 Mar 2010 22:00:04 -0000 Wes, sorry, I'm seriously concerned, and I oppose strongly. You wrote: > There is a sentence that can simply be removed without any loss: > "For some reason, much of the effort of the security community on the > Internet protocols did not result in official documents (RFCs) being > issued by the IETF (Internet Engineering Task Force)." This doesn't > consider the fact that protocol specifications in the IETF and many > (if not most) other SDOs are focused on producing interoperable > specifications with implementation detail left to individual vendors > to differentiate their products. In the case of many of these TCP > vulnerabilities under discussion, many clearly fall into the realm of > implementation issues rather than protocol issues, and are thus outside > the traditional scope of IETF process. As nearly all of the vendors > who have implemented these fixes participate in the IETF, it seems they > haven't felt a compelling urge to have their implementation practices > codified in RFCs. At least explaining this seems more valuable than > the nebulous "For some reason" which makes it sound like this is just > a strange occurence with no clear explanation, though I believe the > sentence can just be completely removed without any loss to the > document. Did you mean this all ironically? (I can't believe that.) This kind of arguing badly confuses reasons and results. Shall it now really be impossible to speak out in a very polite manner what happened in this WG? Do you really not want to realize that so many folks do not contribute any more to TCPM because work in this WG is continually obstructed? The subject matter is not a matter of implementation details. This is a matter of the experience in interoperable implementations being silenced by stereotypous arguments over many years in this WG. A message sent to this WG at Fri, 19 Feb 2010 15:22:49 -0800 once more concluded with: > I have criticized these documents for proposing changes to standards; > I do not have an issue with merely documenting those changes. This clearly restates the goal of all this obstruction we had over several years and that has caused so many folks to stop active participation in this WG. That's why this WG does not fulfill its mission and does not perform actual maintenance of the protocols it pretends to shepherd. I cannot imagine a more concise proof of the diagnose I had placed in a recent posting. As a mathematician, I can't resist to say: Q.E.D. ! It therefore now seems due to stop the exaggerated politeness pretending not to know what has been going on and avoiding to spell out the actual reasons for the lack of progress. It is "the WG", who prohibits this, not _the WG at large_ that has been silenced more and more. Continuing to obfuscate this reason would be inhonest and a kind of self-deception. For me personally, it does not make much sense to waste time and energy for further technical and editorial reasoning on documents on this list, as long as the frequency of postings iterating the same position ad nauseam and the voices of a few folks that happen to attend many IETF meetings and get recruited to a WG sessions are allowed to redefine the consensus of the WG and to take IETF WG procedures ad absurdum. Apparently the continued camouflage of the broken procedures need to be stopped now visibly and publicly, or otherwise it would be better to shut down this WG, the sooner the better. I hereby request that the above quote from the TCP security draft be actually clarified by making "For some reasons" much more explicit, to spell out the truth and send out a clear message to the listeners: || "Because a small minority continually has happened to silence || interested parties in this WG and discouraged and distracted them || from contributing to constructive work to enhance the standards, | much of the effort of the security community on the Internet | protocols did not result in official documents (RFCs) being issued | by the IETF (Internet Engineering Task Force)." This sentence gives the guideline and motivation to continue work on this document. Stripping it off the document would be a stab in the back of the author who has patiently sustained all the tortures so far. I now expect a clear committment of the leadership that the personal favorite "anti-tank obstacles" of one WG member that obstruct any normative improvements be stopped. It's almost only "the WG" who always says he admits (other authors) to only document behavior of the predominating code bases and who opposes to bring the Standards in agreement with what has been proven much better working interoperably in the current hostile environment of the Internet than the 'clean room' standards text cut in stone decades ago. Please either shut down the WG now, or (what I would prefer much more) encourage implementors to return and raise their voice again in the WG, and commit to adhere to the principles Jari Arkko had recalled recently, namely that the IETF should much more listen again to running code and experience. We also need such clear signals now for the IESG, that we want to overcome the lethargy and revive the WG -- isn't it, Jari? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 L.Wood@surrey.ac.uk Mon Mar 1 15:23:42 2010 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 F1ED03A8894 for ; Mon, 1 Mar 2010 15:23:41 -0800 (PST) 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 OlRKQnFuydxj for ; Mon, 1 Mar 2010 15:23:41 -0800 (PST) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with ESMTP id AFDB93A8881 for ; Mon, 1 Mar 2010 15:23:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-83.messagelabs.com!1267485819!25708713!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 30082 invoked from network); 1 Mar 2010 23:23:39 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-83.messagelabs.com with AES128-SHA encrypted SMTP; 1 Mar 2010 23:23:39 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Mon, 1 Mar 2010 23:23:39 +0000 From: To: Date: Mon, 1 Mar 2010 23:23:37 +0000 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq5ljjzwMHiCigIRsStzG4eSnQdyQ== Message-ID: References: <4B7F2881.7000700@gont.com.ar> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, fernando@gont.com.ar, L.Wood@surrey.ac.uk Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 01 Mar 2010 23:23:42 -0000 On 1 Mar 2010, at 06:23, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wr= ote: > The paragraph beginning with "This document is the result of a security a= ssessment of the IETF specifications of the Transmission Control Protocol (= TCP), from a security point of view. Possible threats are identified and, = where possible, countermeasures are proposed." should be replaced with some= thing to the effect of "This document captures the best current practices i= n implementation, configuration, and use of TCP and its supporting protocol= s and extensions and has been produced by the IETF's TCP Maintenance and Mi= nor Extensions Working Group (TCPM)." Surely, "has been roadblocked and nitpicked to death at every possible oppo= rtunity by the TCP Maintenance and Minor Extensions Working Group (TCPM), s= o that this document is a shadow of its former self, but has now been edite= d and reworked sufficiently to give TCPM the necessary sense of ownership, = dominance and authorship to permit the document to proceed." ? This group's work is no longer about TCP, but about bad document re-re-re-r= e-re-writing; not something I'd have the patience for, and if I was the pri= mary originating author I'd have moved on to more satisfying things long ag= o. Sorry, I'm with Alfred. His assessment of this group is correct. I'd insist on including a reference to the original CPNI security assessmen= t document. L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From lars.eggert@nokia.com Mon Mar 1 15:26:25 2010 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 762E93A8BCA; Mon, 1 Mar 2010 15:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=0.448, 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 ba73HstWkWQx; Mon, 1 Mar 2010 15:26:24 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 538DE3A8BCD; Mon, 1 Mar 2010 15:26:24 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21NQMUO032190; Mon, 1 Mar 2010 17:26:23 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 01:26:21 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 01:26:21 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21NQJee022432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 01:26:20 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-30--731526454; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201003012159.WAA15069@TR-Sys.de> Date: Mon, 1 Mar 2010 15:26:05 -0800 Message-Id: References: <201003012159.WAA15069@TR-Sys.de> To: ah@tr-sys.de X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 02 Mar 2010 01:26:13 +0200 (EET) X-OriginalArrivalTime: 01 Mar 2010 23:26:21.0775 (UTC) FILETIME=[9A424DF0:01CAB996] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 01 Mar 2010 23:26:25 -0000 --Apple-Mail-30--731526454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, you are raising the serious accusation that the TCPM WG is = dysfunctional. It will come as no surprise that I don't share this view. Yes, the bar for changing TCP is high. TCP is one of the core protocols = of the Internet, and the bar for changes *should* be high. I know you = follow what is going on in other areas, and neither BGP, DNS, SIP or IP = are easily modified. You might not like it, but this is a feature. We've had several documents recently for which we discussed whether they = should be on the Standards Track or not. In some cases, the WG decided = for Informational, in other cases, for PS. The chairs called the = consensus and the WG agreed. Are the arguments in TCPM sometimes heated? Absolutely. But that is not = a sign of a dysfunctional WG. It just means that the participants feel = strongly about the particular technical issues. Now, let me comment on some of your specific accusations. On 2010-3-1, at 13:59, ah@tr-sys.de wrote: > Do you really not want to realize that so many folks do not contribute > any more to TCPM because work in this WG is continually obstructed? Please back this statement up. Who are the "many folks" who have stopped = to contribute because the WG is "obstructed"? > This is a matter of the experience in interoperable implementations > being silenced by stereotypous arguments over many years in this WG. Interoperable implementations are one factor in the IETF standardization = process. Rough WG consensus is another. The former does not trump the = latter. > A message sent to this WG at Fri, 19 Feb 2010 15:22:49 -0800 > once more concluded with: >=20 >> I have criticized these documents for proposing changes to standards; >> I do not have an issue with merely documenting those changes. >=20 > This clearly restates the goal of all this obstruction we had over > several years and that has caused so many folks to stop active > participation in this WG. You again insinuate that "many folks" have left the WG. Again, please = back this up. You also imply that there is organized obstruction to TCP = changes in the WG. Again, back this accusation up with data. > That's why this WG does not fulfill its mission and does not perform > actual maintenance of the protocols it pretends to shepherd. The WG is publishing documents. There is intense discussion. The = documents are of high quality. How exactly does the WG not fulfill its = mission? Yes, the WG does not take on all or even many of the proposals that are = brought to it. This is a sign that the WG is taking its stewardship of = the TCP protocol seriously. > I cannot imagine a more concise proof of the diagnose I had placed > in a recent posting. > As a mathematician, I can't resist to say: Q.E.D. ! As a mathematician, you should know that you have not presented a proof. = You have presented an argument. > It is "the WG", who prohibits this, not _the WG at large_ that has > been silenced more and more. There is no "WG at large". The TCPM WG is defined by the individuals = that speak up on the TCPM list or in the meetings. Folks who would like = to make changes to TCP need to invest the time and effort to convince = the community of the value of those changes. Anyone can do so, and many = folks do. It is simply false to say that anyone "has been silenced."=20 > For me personally, it does not make much sense to waste time and > energy for further technical and editorial reasoning on documents > on this list, as long as the frequency of postings iterating the > same position ad nauseam and the voices of a few folks that happen > to attend many IETF meetings and get recruited to a WG sessions are > allowed to redefine the consensus of the WG and to take IETF WG > procedures ad absurdum. Nobody "gets recruited" for WG sessions. Like all other IETF WGs, = participation is open. More importantly, you claim that some group of people has "redefined" = the WG consensus. This is a serious accusation against the chairs and me = as AD. Please provide specific details or retract this accusation. > Please either shut down the WG now, or (what I would prefer much more) I'm not shutting the WG down.=20 > encourage implementors to return and raise their voice again in the = WG, Implementors have been and continue to be welcome to bring proposals to = the WG. I know that several WG participants are actively trying to = encourage this. For example, the last time I personally did this was on = February 16, when I contacted the proponents of the "TCP thin-stream = detection" mechanism that is proposed for inclusion in the Linux kernel = to write up their proposal for discussion in the IETF. (And for the third time, you insinuate that implementors has left the = WG, and I'm again asking you to back that statement up.) > and commit to adhere to the principles Jari Arkko had recalled = recently, > namely that the IETF should much more listen again to running code and > experience. Running code is great. So is rough WG consensus. One does not trump the = other. Lars= --Apple-Mail-30--731526454 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDMwMTIzMjYwNlowIwYJKoZIhvcNAQkEMRYEFHtQOY1ISQ80Geco2RI6ur8hnxfwMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQC+vkBl4XF4LaTY9P/tcBunoHwBTataop9wHF48jrxAXNtHIyR13wcKgxKodpdX3NUMGn+N U10tyAC4Htxn0FQPCLu/HcTqwaBBULFQK6tc7RP82P5Tb9bbU1kL1CVUvMz+3PY19mWFlHlWfa44 uXMivOXmVPSrcw8mg1LtJtfZmmDTZsOgZYa5pW/QTDOUqQsd6EvW4EvEaw8syVqUgYwU7lAPunPh 5a+3hdLuh1YYKO1DI7TSChrjPUeuZVpaTFfTXPKFk18Uvr+a20Alxsoi8rmhFbCuVs/SSCunZfi5 d/SJGkmIcTGQXdHuUkC68IQ+neATOkzDX1hpZxIJeBxDAAAAAAAA --Apple-Mail-30--731526454-- From wesley.m.eddy@nasa.gov Mon Mar 1 17:28:18 2010 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 B6DEB28C69A for ; Mon, 1 Mar 2010 17:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 E1UWpsXb9-3C for ; Mon, 1 Mar 2010 17:28:15 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 79E3728C679 for ; Mon, 1 Mar 2010 17:28:15 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 16EE6A8962; Mon, 1 Mar 2010 19:28:16 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o221SE5V017620; Mon, 1 Mar 2010 19:28:14 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Mon, 1 Mar 2010 19:28:14 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "ah@TR-Sys.de" , "tcpm@ietf.org" Date: Mon, 1 Mar 2010 19:28:14 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq5io846LLLScNpS9SBv0uVMeKKxQAG5kEh Message-ID: References: <201003012159.WAA15069@TR-Sys.de> In-Reply-To: <201003012159.WAA15069@TR-Sys.de> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-01_17:2010-02-06, 2010-03-01, 2010-03-01 signatures=0 Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 01:28:18 -0000 Hi Alfred, I think you misunderstand. I'm simply correcting a sentence whi= ch makes it seem mysterious that the IETF hasn't taken many of the security= patches that have been developed and codified them into RFCs. I gave a cl= ear explanation for this, and since a great deal of the patches in question= predate the formation of TCPM and have never been brought to TCPM or any o= ther WG, the rest of your message which is about that particular WG doesn't= seem to be in the right context. I was only talking about one sentence an= d the couple of decades of TCP evolution that the particular sentence is fu= zzy on. Does that make sense? ________________________________________ From: ah@TR-Sys.de [ah@TR-Sys.de] Sent: Monday, March 01, 2010 4:59 PM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; tcpm@ietf.org Cc: jari.arkko@piuha.net Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Wes, sorry, I'm seriously concerned, and I oppose strongly. You wrote: > There is a sentence that can simply be removed without any loss: > "For some reason, much of the effort of the security community on the > Internet protocols did not result in official documents (RFCs) being > issued by the IETF (Internet Engineering Task Force)." This doesn't > consider the fact that protocol specifications in the IETF and many > (if not most) other SDOs are focused on producing interoperable > specifications with implementation detail left to individual vendors > to differentiate their products. In the case of many of these TCP > vulnerabilities under discussion, many clearly fall into the realm of > implementation issues rather than protocol issues, and are thus outside > the traditional scope of IETF process. As nearly all of the vendors > who have implemented these fixes participate in the IETF, it seems they > haven't felt a compelling urge to have their implementation practices > codified in RFCs. At least explaining this seems more valuable than > the nebulous "For some reason" which makes it sound like this is just > a strange occurence with no clear explanation, though I believe the > sentence can just be completely removed without any loss to the > document. Did you mean this all ironically? (I can't believe that.) This kind of arguing badly confuses reasons and results. Shall it now really be impossible to speak out in a very polite manner what happened in this WG? Do you really not want to realize that so many folks do not contribute any more to TCPM because work in this WG is continually obstructed? The subject matter is not a matter of implementation details. This is a matter of the experience in interoperable implementations being silenced by stereotypous arguments over many years in this WG. A message sent to this WG at Fri, 19 Feb 2010 15:22:49 -0800 once more concluded with: > I have criticized these documents for proposing changes to standards; > I do not have an issue with merely documenting those changes. This clearly restates the goal of all this obstruction we had over several years and that has caused so many folks to stop active participation in this WG. That's why this WG does not fulfill its mission and does not perform actual maintenance of the protocols it pretends to shepherd. I cannot imagine a more concise proof of the diagnose I had placed in a recent posting. As a mathematician, I can't resist to say: Q.E.D. ! It therefore now seems due to stop the exaggerated politeness pretending not to know what has been going on and avoiding to spell out the actual reasons for the lack of progress. It is "the WG", who prohibits this, not _the WG at large_ that has been silenced more and more. Continuing to obfuscate this reason would be inhonest and a kind of self-deception. For me personally, it does not make much sense to waste time and energy for further technical and editorial reasoning on documents on this list, as long as the frequency of postings iterating the same position ad nauseam and the voices of a few folks that happen to attend many IETF meetings and get recruited to a WG sessions are allowed to redefine the consensus of the WG and to take IETF WG procedures ad absurdum. Apparently the continued camouflage of the broken procedures need to be stopped now visibly and publicly, or otherwise it would be better to shut down this WG, the sooner the better. I hereby request that the above quote from the TCP security draft be actually clarified by making "For some reasons" much more explicit, to spell out the truth and send out a clear message to the listeners: || "Because a small minority continually has happened to silence || interested parties in this WG and discouraged and distracted them || from contributing to constructive work to enhance the standards, | much of the effort of the security community on the Internet | protocols did not result in official documents (RFCs) being issued | by the IETF (Internet Engineering Task Force)." This sentence gives the guideline and motivation to continue work on this document. Stripping it off the document would be a stab in the back of the author who has patiently sustained all the tortures so far. I now expect a clear committment of the leadership that the personal favorite "anti-tank obstacles" of one WG member that obstruct any normative improvements be stopped. It's almost only "the WG" who always says he admits (other authors) to only document behavior of the predominating code bases and who opposes to bring the Standards in agreement with what has been proven much better working interoperably in the current hostile environment of the Internet than the 'clean room' standards text cut in stone decades ago. Please either shut down the WG now, or (what I would prefer much more) encourage implementors to return and raise their voice again in the WG, and commit to adhere to the principles Jari Arkko had recalled recently, namely that the IETF should much more listen again to running code and experience. We also need such clear signals now for the IESG, that we want to overcome the lethargy and revive the WG -- isn't it, Jari? Kind regards, Alfred H=CEnes. -- +------------------------+--------------------------------------------+ | 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 wesley.m.eddy@nasa.gov Mon Mar 1 17:33:31 2010 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 CF4923A85DB for ; Mon, 1 Mar 2010 17:33:31 -0800 (PST) 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=[AWL=0.000, 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 EuzdLX84TROD for ; Mon, 1 Mar 2010 17:33:31 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id D94283A8148 for ; Mon, 1 Mar 2010 17:33:30 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 037D13297DF; Mon, 1 Mar 2010 19:33:31 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o221XU58014194; Mon, 1 Mar 2010 19:33:30 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Mon, 1 Mar 2010 19:33:30 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "L.Wood@surrey.ac.uk" Date: Mon, 1 Mar 2010 19:28:33 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq5ljjzwMHiCigIRsStzG4eSnQdyQAEXOD1 Message-ID: References: <4B7F2881.7000700@gont.com.ar> , 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-01_17:2010-02-06, 2010-03-01, 2010-03-01 signatures=0 Cc: "tcpm@ietf.org" , "fernando@gont.com.ar" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 01:33:31 -0000 I don't know if you've read the document under discussion, but it already i= ncludes a reference to the CPNI security assessment you mention including a= reference to, and this reference immediately follows the text I suggested = clarifying to identify TCPM as the document source. My suggestion was to put a sentence in that makes the context of the docume= nt clear, as a TCPM product, with recommendations that have been reviewed b= y TCPM. It shouldn't be controversial that the WG takes ownership of a WG = product. ________________________________________ From: L.Wood@surrey.ac.uk [L.Wood@surrey.ac.uk] Sent: Monday, March 01, 2010 6:23 PM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] Cc: L.Wood@surrey.ac.uk; fernando@gont.com.ar; tcpm@ietf.org Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security On 1 Mar 2010, at 06:23, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wr= ote: > The paragraph beginning with "This document is the result of a security a= ssessment of the IETF specifications of the Transmission Control Protocol (= TCP), from a security point of view. Possible threats are identified and, = where possible, countermeasures are proposed." should be replaced with some= thing to the effect of "This document captures the best current practices i= n implementation, configuration, and use of TCP and its supporting protocol= s and extensions and has been produced by the IETF's TCP Maintenance and Mi= nor Extensions Working Group (TCPM)." Surely, "has been roadblocked and nitpicked to death at every possible oppo= rtunity by the TCP Maintenance and Minor Extensions Working Group (TCPM), s= o that this document is a shadow of its former self, but has now been edite= d and reworked sufficiently to give TCPM the necessary sense of ownership, = dominance and authorship to permit the document to proceed." ? This group's work is no longer about TCP, but about bad document re-re-re-r= e-re-writing; not something I'd have the patience for, and if I was the pri= mary originating author I'd have moved on to more satisfying things long ag= o. Sorry, I'm with Alfred. His assessment of this group is correct. I'd insist on including a reference to the original CPNI security assessmen= t document. L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood= From fernando@gont.com.ar Mon Mar 1 17:58:27 2010 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 CC2BC3A8C01; Mon, 1 Mar 2010 17:58:27 -0800 (PST) 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 l2BzcWQ2f5Qf; Mon, 1 Mar 2010 17:58:27 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8534D3A7038; Mon, 1 Mar 2010 17:58:24 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2F81A6B6839; Mon, 1 Mar 2010 22:58:29 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o221wMML025910; Mon, 1 Mar 2010 22:58:22 -0300 Message-ID: <4B8C70C0.8090708@gont.com.ar> Date: Mon, 01 Mar 2010 22:58:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <201003012159.WAA15069@TR-Sys.de> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=UTF-8 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]); Mon, 01 Mar 2010 22:58:29 -0300 (ART) Cc: ah@tr-sys.de, "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 01:58:27 -0000 Lars Eggert wrote: > More importantly, you claim that some group of people has "redefined" > the WG consensus. This is a serious accusation against the chairs and > me as AD. Please provide specific details or retract this accusation. Lars, I had made this comment a month ago or so, and at the time I preferred not to answer you "provide details" request, in the hope of looking forward. However, given that this has been raised again, I'll respond this time: Earlier this year this working group was specifically polled about adopting draft-gont-tcp-security as a WG item. The WG had unprecedented strong consensus in this respect (with people even offering to spend cycles on document review), and this consensus was even noted in the slides the wg chairs used in the TCPM meeting at IETF 75 (see: http://www.ietf.org/proceedings/75/slides/tcpm-2/tcpm-2.htm). At the meeting, you (IIRC) raised the question about whether we wanted to work on this document, or start with a new one (!). -- basically throwing out of the window the 2-year effort of writing the CPNI TCP security assessment on which draft-ietf-tcp-security is based. IMO, that's part of obstructing, and/or "not invented here" (NIH) syndrome. FWIW, It's interesting to note that IAB's Gregory Lebovitz was there at the TCPM meeting, and commented that "WGs don’t need drafts to 100% right to become WG items". (and, btw, only two or three people at that meeting said that they had actually read the document.) After the meeting, you argued (off-list) that wg consensus (allegedly as a result of IETF 75??!) was to submit a "fresh" (i.e., blank/brand-new) document, when we already had consensus *before* the meeting, on the *mailing-list* (as the IETF mandates it should be) for adopting draft-gont-tcp-security. You even suggested that tcpm should assemble "a team of editors" (when you should have probably made this observation for the non-progressing tcp-ao, rather than for this newly adopted I-D). Last, but not least, anybody interested in the meeting I'm referring to are advised to listen to the meeting recordings, rather than reading the tcpm meeting minutes. Another instance (but this one older, and in tsvwg): I could also mention that when tsvwg was polled years ago (you were co-chair of that wg at the time) about adopting draft-larsen-port-randomization (now draft-ietf-port-randomization) as a wg item, at some point something like 5+ people were supporting the adoption of the document as a tsvwg item (targeting *std* track)... but you mentioned that that didn't represent wg consensus. Then the voice of three people (yours included) changed the target from Std track to BCP. (And no... I'm not arguing that std track was more correct than bcp. I'm just arguing that the process, and your view of "consensus", are not clear to me). 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 fernando@gont.com.ar Mon Mar 1 18:09:33 2010 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 0A8BD28C5CB for ; Mon, 1 Mar 2010 18:09:33 -0800 (PST) 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 iAz0oq2HJxFI for ; Mon, 1 Mar 2010 18:09:32 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8DA7A28C61A for ; Mon, 1 Mar 2010 18:09:30 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B46696B6B12 for ; Mon, 1 Mar 2010 23:09:35 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2229SwX003444; Mon, 1 Mar 2010 23:09:28 -0300 Message-ID: <4B8C735A.1000707@gont.com.ar> Date: Mon, 01 Mar 2010 23:09:30 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.96.0 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]); Mon, 01 Mar 2010 23:09:34 -0300 (ART) Subject: [tcpm] [Fwd: Some feedback for draft-ananth-tcpm-persist-02.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: Tue, 02 Mar 2010 02:09:33 -0000 Folks, A while ago I had sent some feedback to the authors of the tcpm-persist I-D. I'm forwarding my comments to the wg. -------- Original Message -------- Subject: Some feedback for draft-ananth-tcpm-persist-02.txt Date: Sun, 10 Jan 2010 15:11:03 -0300 From: Fernando Gont To: Murali Bashyam , "Mahesh Jethanandani (mahesh)" , "Anantha Ramaiah (ananth)" Folks, See some quoted portions of your I-D, and my comments inline.... > This is important > because typically applications would want the TCP connection to stay > open unless it explicitly closes the connection. For example take > the case of user running a print job and the printer ran out of paper > waiting for the user intervention. It would be premature for TCP to > take action on its own. Hence TCP cannot act as a resource manager > and it is the system or application's responsibility to take > appropriate action. This is not necessarily the case. e.g., in the case of orphaned connections, it's *TCP*'s responsibility (or, well, the OS) to take appropriate action. > > At the same time, many existing TCP implementations that adhere > strictly to the above verbiage of RFC 1122, may fall victim to DOS > attacks, if appropriate measures are not followed. Nit: s/DOS/DoS/ (an in other places as well) > Applications on the sender can transfer all the data to the TCP > socket and subsequently close the socket leaving the connection in > orphaned state. You should probably clarify this term ("orphaned"). e.g., "connections with no controlling process".... > CERT is putting a advisory in this regard[VU723308] and is making > vendors aware of this DoS scenario. Nit: There's a missing space in "regard[VU723308]". Also, CERT-FI has publish an advisory on the same issue. And UK CPNI has published a TCP security report that contains a lengthy discussion on this attack (and different variants, and the possible counter-measures. > In such cases, and specially when the receiver is reliably > acknowledging zero window probe, to achieve robustness, the system > should be able to take appropriate action on those TCP connections > and reclaim resources. I'd s/robustness/resiliency/. (Actually, I'd argue that by aborting these connections, you're actually *reducing* TCP's robustness). > In order to accomplish this action, TCP MAY provide a feedback > regarding the persist condition to the application if requested to do > so or the application or the resource manager can query the health of > the TCP connection which would allow it to take the desired action. > All such actions are in complete compliance of RFC 793 and RFC 1122. As mentioned other times, I think the app cares about the connection making progress (or not), and not really about the reason for the lack of progress (see the discussion in the CPNI paper about these issues). Aside: FWIW, RFC 793 describes an ABORT() call that an app is free to use at any time. Therefore, I'd argue that if the *app* takes action, RFC 1122 is irrelevant. Only if you need *TCP* to take action you should mention/care about what RFC 1122 says. > It also suggests that TCP MUST not abort any connection until either > explicitly requested by the application to do so. The implementation > guidelines of the request and the action are documented in Section 7, > and the details of mitigating the DoS attack are left to the > implementer. You probably want to s/MUST not/MUST NOT/. > The interface allows applications to inform TCP that when the local > connection stays in persist condition it can be cleared after a set > time. Note that the default value of this option is indefinite. s/cleared/aborted/. Also, did you mean "infinite" rather than "indefinite"? > TCP sender will save the current time in the connection block when it > receives a zero window ACK. This time is referred to as the persist > entry time. Thereafter every time the probe timer expires and before > it sends another probe or an ACK carrying zero window is received a > check will be done to see how long the connection has been in persist > condition by comparing the current time to the persist entry time. > If the timeout has been exceeded, the connection will be aborted. > > Any time a ACK is received that advertises a non-zero window, the > persist entry time is cleared to take the connection out of persist > condition. You should probably remove this, or just mention this as a possible implementation approach. That is, one could implement the same functionality without following this specific implementation strategy. P.S.: Please let me know if you'd like me to post my feedback to the mailing-list. 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 -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From lars.eggert@nokia.com Mon Mar 1 19:23:22 2010 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 4D40B28C6BF; Mon, 1 Mar 2010 19:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 Nbd2bTmqHy3r; Mon, 1 Mar 2010 19:23:20 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6A43328C637; Mon, 1 Mar 2010 19:23:20 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o223MP7Y002304; Mon, 1 Mar 2010 21:22:29 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 05:22:18 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 05:22:18 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o223MGwR011294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 05:22:17 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-35--717371626; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B8C70C0.8090708@gont.com.ar> Date: Mon, 1 Mar 2010 19:22:00 -0800 Message-Id: References: <201003012159.WAA15069@TR-Sys.de> <4B8C70C0.8090708@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 02 Mar 2010 05:22:06 +0200 (EET) X-OriginalArrivalTime: 02 Mar 2010 03:22:18.0346 (UTC) FILETIME=[903B9CA0:01CAB9B7] X-Nokia-AV: Clean Cc: "ah@tr-sys.de" , "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 03:23:22 -0000 --Apple-Mail-35--717371626 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 2010-3-1, at 17:58, Fernando Gont wrote: > Lars Eggert wrote: >=20 >> More importantly, you claim that some group of people has "redefined" >> the WG consensus. This is a serious accusation against the chairs and >> me as AD. Please provide specific details or retract this accusation. >=20 > Lars, >=20 > I had made this comment a month ago or so, and at the time I preferred > not to answer you "provide details" request, in the hope of looking > forward. the exact phrasing in your earlier email was that I "seemed to ignore WG = consensus". Alfred now says that I "redefined" WG consensus. Both are = very serious accusations. I believe that I did not mishandle things here = (see below for details), but I'm obviously biased. I encourage others to = speak up. If you really believe I acted improperly, please start a recall = petition. Otherwise, please stop accusing me of misconduct and = apologize. This is the last email I'm going to send on this topic. > However, given that this has been raised again, I'll respond > this time: Thank you.=20 > Earlier this year this working group was specifically polled about > adopting draft-gont-tcp-security as a WG item. The WG had = unprecedented > strong consensus in this respect (with people even offering to spend > cycles on document review), and this consensus was even noted in the > slides the wg chairs used in the TCPM meeting at IETF 75 (see: > http://www.ietf.org/proceedings/75/slides/tcpm-2/tcpm-2.htm). no disagreement so far - there was strong consensus to adopt a work item = on describing a security assessment of various TCP aspects. > At the meeting, you (IIRC) raised the question about whether we wanted > to work on this document, or start with a new one (!). I don't think this is quit accurate. What happens when a WG takes on new = work is that they decide to take on a work item, and then they decide = which individual document (if any) can be adopted as the basis for = progressing this work item forward. As I said, there was strong consensus to take on the work item. When we = discussed whether the CNPI document was a good starting point, I wanted = to make it clear that we'd be taking on a very substantial piece of text = that had already been published. If I recall correctly, the WG did discuss for a while if there would be = any argument for basically republishing the CNPI document through the = IETF, and my take away from the discussion was that the WG felt that an = IETF document in this space should say something more or differently = than what the CNPI document had said. That's why we arrived at the decision to come to consensus on an new = document structure first and then merge in content from the (long) CNPI = document in a piecemeal fashion. > -- basically > throwing out of the window the 2-year effort of writing the CPNI TCP > security assessment on which draft-ietf-tcp-security is based. The CNPI document is published. Nothing the IETF can do invalidates the = effort that went into it. Starting with a different outline (that's what = the WG decided on) and merging in content from the CNPI document is not = "throwing out the window" all that effort. > IMO, that's part of obstructing, and/or "not invented here" (NIH) = syndrome. But neither of the two (irrespective of whether they are true or not) = are indicative of me ignoring WG consensus. The discussion of whether to adopt this specific draft as a basis for = the work item (and in which form) was still in full swing on the list = and during the meeting week. Sure, I spoke up during this discussion. = But that's not ignoring WG consensus. > FWIW, It's interesting to note that IAB's Gregory Lebovitz was there = at > the TCPM meeting, and commented that "WGs don=92t need drafts to 100% > right to become WG items". (and, btw, only two or three people at that > meeting said that they had actually read the document.) It may be interesting to note, but it is unrelated to the accusation you = make. > After the meeting, you argued (off-list) that wg consensus (allegedly = as > a result of IETF 75??!) was to submit a "fresh" (i.e., = blank/brand-new) > document The WG consensus after IETF-75 *was* to start with a new document = structure. That's why after IETF-75, you posted a revision that = contained just the outline and we discussed it. See = http://www.ietf.org/mail-archive/web/tcpm/current/msg04813.html and = follow-ups. > , when we already had consensus *before* the meeting, on the > *mailing-list* (as the IETF mandates it should be) for adopting > draft-gont-tcp-security. The discussion started in = http://www.ietf.org/mail-archive/web/tcpm/current/msg04641.html was = still in full swing during IETF-75 - the chairs had not declared = consensus. That happened at the end of IETF-75: = http://www.ietf.org/mail-archive/web/tcpm/current/msg04777.html > You even suggested that tcpm should assemble "a > team of editors" Yes, probably. As I said during the meeting, I believe that this would = be the largest work item in TCPM in terms of effort, so strong support = is required. > (when you should have probably made this observation > for the non-progressing tcp-ao, rather than for this newly adopted = I-D). Irrelevant for the discussion at hand. > Last, but not least, anybody interested in the meeting I'm referring = to > are advised to listen to the meeting recordings, rather than reading = the > tcpm meeting minutes. What specifically in the audio recordings backs up your accusation that = is not also in the minutes? You're making the accusation that I'm = ignoring WG consensus, so it's on you to provide the data. To summarize (because below is about a different instance): I have seen = no evidence that I mishandled anything in this case. But I'm obviously = biased. I encourage others to speak up.=20 > Another instance (but this one older, and in tsvwg): > I could also mention that when tsvwg was polled years ago (you were > co-chair of that wg at the time) about adopting > draft-larsen-port-randomization (now draft-ietf-port-randomization) as = a > wg item, at some point something like 5+ people were supporting the > adoption of the document as a tsvwg item (targeting *std* track)... = but > you mentioned that that didn't represent wg consensus. > Then the voice of three people (yours included) changed the target = from > Std track to BCP. (And no... I'm not arguing that std track was more > correct than bcp. I'm just arguing that the process, and your view of > "consensus", are not clear to me). If you want to make that accusation, please dig through the minutes to = back this up with facts to make a case, instead of giving an anecdotal = summary. I will point out that I acted as chair during the adoption of = an individual document as a WG work item, and it is normal procedure to = try and determine what the correct document type would be. The consensus = is what concludes this process, and it is called by the chairs (three in = this case). =20 If you really believe I acted improperly, please start a recall = petition. Otherwise, please stop accusing me of misconduct and = apologize. This is the last email I'm going to send on this topic. Lars= --Apple-Mail-35--717371626 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDMwMjAzMjIwMVowIwYJKoZIhvcNAQkEMRYEFPdhX+mSmbX+HX6D3fPrl+PwOK09MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBCM8vWNE0lmj87H9/tmlNRjsZeVlI6NfQOQBgQOoMYNHlrNI6AJKtd4B4t/ecBWJGuFeYF mR1Hc8IRptpSwHfXDyBM5Ti5CBY0HbcGiTstxIpgPw+RyXxx2Jrsget72N1hIz/blzl/oRsd4T4j DcilBaVBtSm7ngqNRN8YSvy3A7mseYsz71E20GbbtSusPfcOQqVIbuk7NzBVzORWGwOT96PbzpMZ /W/nhWQ/7PZhNCNV42GfOeT8r3p2c+FtfyUeJKVbjlwoO5UbxPUqZRefHAyvLt1vU2YwR0mlkECv SIOEFj0aG87TtiE6FrJjyJM4Fw3yBlPrcBW+NVtb/dd3AAAAAAAA --Apple-Mail-35--717371626-- From fernando@gont.com.ar Mon Mar 1 20:55:50 2010 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 DC24E28C16A; Mon, 1 Mar 2010 20:55:50 -0800 (PST) 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 WBpPcALCrk-5; Mon, 1 Mar 2010 20:55:50 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9564E3A8BDA; Mon, 1 Mar 2010 20:55:47 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3B88C6B6A63; Tue, 2 Mar 2010 01:55:53 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o224thR4015965; Tue, 2 Mar 2010 01:55:44 -0300 Message-ID: <4B8C9A51.1000108@gont.com.ar> Date: Tue, 02 Mar 2010 01:55:45 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <201003012159.WAA15069@TR-Sys.de> In-Reply-To: X-Enigmail-Version: 0.96.0 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, 02 Mar 2010 01:55:52 -0300 (ART) Cc: ah@tr-sys.de, "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 04:55:51 -0000 Lars Eggert wrote: >> Do you really not want to realize that so many folks do not >> contribute any more to TCPM because work in this WG is continually >> obstructed? > > Please back this statement up. Who are the "many folks" who have > stopped to contribute because the WG is "obstructed"? Some of them have made statements on the mailing-list. See, e.g., this note by OpenBSD's Theo de Raadt, circa 2005 (http://www.ietf.org/mail-archive/web/tcpm/current/msg01233.html): >> And maybe by the time we get anywhere, no one will care about the resulting >> document, because they will have already solved them (with a "draft", >> unfortunately): people want their problems to be solved. They don't care >> about labelling their products with "RFC-compliance". > > OpenBSD's tcp-ip stack is not RFC compliant. > > And we are very proud that it is not RFC compliant. > > Beause if it was RFC compliant it would be so vulnerable to so many > well known attacks. > > IETF is so misguided these days. Attempts at quality have been thrown > out the window, and a couple of old farts (mostly with corporate ties) > run the show to the detriment of a society which needs this stuff to > work as well as possible. > > Joe, it is people like you keeping TCP broken. And this other e-mail by Theo de Raadt (http://www.ietf.org/mail-archive/web/tcpm/current/msg01232.html): >> For the connection-reset attack, the proposed attack-specific fix is to >> treat hard errors as soft errors. >> BTW, TCP SHOULD (*not* "MUST") abort the connections. > > This is just so ridicilous. > > Any network stack that follows your advice is busted. > > Why do you persist in being so behind the times? P.S: This last statement by Theo was a response to Joe Touch in one of the endless threads about the ICMP attacks draft. 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 fernando@gont.com.ar Mon Mar 1 21:14:25 2010 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 D3E7228C156; Mon, 1 Mar 2010 21:14:25 -0800 (PST) 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 hf0Ca+mDj3Ni; Mon, 1 Mar 2010 21:14:24 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id AE3B928C241; Mon, 1 Mar 2010 21:14:20 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D2DBD6B6A7A; Tue, 2 Mar 2010 02:14:26 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o225EHxf026505; Tue, 2 Mar 2010 02:14:18 -0300 Message-ID: <4B8C9EAA.8000205@gont.com.ar> Date: Tue, 02 Mar 2010 02:14:18 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <201003012159.WAA15069@TR-Sys.de> <4B8C70C0.8090708@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=windows-1252 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, 02 Mar 2010 02:14:25 -0300 (ART) Cc: "ah@tr-sys.de" , "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 05:14:25 -0000 Lars Eggert wrote: >> Earlier this year this working group was specifically polled about >> adopting draft-gont-tcp-security as a WG item. The WG had >> unprecedented strong consensus in this respect (with people even >> offering to spend cycles on document review), and this consensus >> was even noted in the slides the wg chairs used in the TCPM meeting >> at IETF 75 (see: >> http://www.ietf.org/proceedings/75/slides/tcpm-2/tcpm-2.htm). > > no disagreement so far - there was strong consensus to adopt a work > item on describing a security assessment of various TCP aspects. No. The poll was about adopting draft-gont-tcpm-tcp-security as a wg item. Please dig the archives. > If I recall correctly, the WG did discuss for a while if there would > be any argument for basically republishing the CNPI document through > the IETF, and my take away from the discussion was that the WG felt > that an IETF document in this space should say something more or > differently than what the CNPI document had said. This is not what the 8+ people that supported this I-D on this mailing-list said. > That's why we arrived at the decision to come to consensus on an new > document structure first and then merge in content from the (long) > CNPI document in a piecemeal fashion. Again. This is not true. WG consensus was called for adopting of draft-gont-tcpm-tcp-security. Look at the mailing-list archives. >> IMO, that's part of obstructing, and/or "not invented here" (NIH) >> syndrome. > > But neither of the two (irrespective of whether they are true or not) > are indicative of me ignoring WG consensus. > > The discussion of whether to adopt this specific draft as a basis for > the work item (and in which form) was still in full swing on the list > and during the meeting week. Sure, I spoke up during this discussion. > But that's not ignoring WG consensus. That's not correct. >> After the meeting, you argued (off-list) that wg consensus >> (allegedly as a result of IETF 75??!) was to submit a "fresh" >> (i.e., blank/brand-new) document > > The WG consensus after IETF-75 *was* to start with a new document > structure. Consensus was arrived on the mailing-list, as it should be. And consensus was for adopting draft-gont-tcpm-tcp-security. > That's why after IETF-75, you posted a revision that > contained just the outline and we discussed it. See > http://www.ietf.org/mail-archive/web/tcpm/current/msg04813.html and > follow-ups. That's incorrect. I posted a rev that only included the stuff that we wanted to discuss. This was suggested by the chairs, as they felt that some implementers might implement whatever they found in the document, even if some stuff had not yet been discussed by the wg. Zeroing part of the document had nothing to do with "start with a clean-slate" or the like. > The discussion started in > http://www.ietf.org/mail-archive/web/tcpm/current/msg04641.html was > still in full swing during IETF-75 - the chairs had not declared > consensus. That happened at the end of IETF-75: > http://www.ietf.org/mail-archive/web/tcpm/current/msg04777.html > >> You even suggested that tcpm should assemble "a team of editors" > > Yes, probably. As I said during the meeting, I believe that this > would be the largest work item in TCPM in terms of effort, so strong > support is required. The document already had strong support. Unprecedentedly 8+ people supported the I-D, and volunteered to help. But I'm afraid that if we play the (sadly) typical game of "TCP need not be implemented in a secure way!", followed by "start with a clean-slate", followed by "let's change the outline", followed by... most of these people will get tired, and the effort will vanish... and the specs will continue to be outdated as they are. 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 L.Wood@surrey.ac.uk Tue Mar 2 00:16:40 2010 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 2620428C0E9 for ; Tue, 2 Mar 2010 00:16:40 -0800 (PST) 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 48nzF-GgD6dr for ; Tue, 2 Mar 2010 00:16:39 -0800 (PST) Received: from mail114.messagelabs.com (mail114.messagelabs.com [195.245.231.163]) by core3.amsl.com (Postfix) with ESMTP id A1A8E3A8307 for ; Tue, 2 Mar 2010 00:16:38 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-9.tower-114.messagelabs.com!1267517797!53142203!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.39] Received: (qmail 1114 invoked from network); 2 Mar 2010 08:16:37 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-9.tower-114.messagelabs.com with AES128-SHA encrypted SMTP; 2 Mar 2010 08:16:37 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 2 Mar 2010 08:16:37 +0000 From: To: Date: Tue, 2 Mar 2010 08:16:35 +0000 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq54Kzv5GucLDKOSXaA8Lz7Jt9q9A== Message-ID: <4C337366-E8A4-4B6F-AF1F-65E29389D902@surrey.ac.uk> References: <4B7F2881.7000700@gont.com.ar> , In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, fernando@gont.com.ar, L.Wood@surrey.ac.uk Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 08:16:40 -0000 On 2 Mar 2010, at 01:28, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wr= ote: > I don't know if you've read the document under discussion, but it already= includes a reference to the CPNI security assessment you mention including= a reference to, and this reference immediately follows the text I suggeste= d clarifying to identify TCPM as the document source. No, it includes it as an inline comment - i.e. it does not have the status = of an explicit reference. It's already well on its way to being elided as u= nnecessary as history is rewritten. > My suggestion was to put a sentence in that makes the context of the docu= ment clear, by removing any mention of security/threats? > as a TCPM product, with recommendations that have been reviewed by TCPM. = It shouldn't be controversial that the WG takes ownership of a WG product. You're right, that shouldn't be controversial. That it is says much about t= he way that this WG takes ownership. L. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From alexander.zimmermann@nets.rwth-aachen.de Tue Mar 2 02:03:02 2010 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 18E543A845B for ; Tue, 2 Mar 2010 02:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[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 PvGHnGBxchOm for ; Tue, 2 Mar 2010 02:03:00 -0800 (PST) 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 E56F63A6F50 for ; Tue, 2 Mar 2010 02:02:55 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KYN0099QFWVVR00@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 02 Mar 2010 11:02:55 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,565,1262559600"; d="scan'208";a="47177669" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 02 Mar 2010 11:02:56 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KYN00KIKFWVCI30@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Tue, 02 Mar 2010 11:02:55 +0100 (CET) From: Alexander Zimmermann In-reply-to: <201003012159.WAA15069@TR-Sys.de> Date: Tue, 02 Mar 2010 11:02:57 +0100 Message-id: <4469BE1B-35FC-4C9B-80CF-5632105FC8B2@nets.rwth-aachen.de> References: <201003012159.WAA15069@TR-Sys.de> To: Alfred SM5uZXM= X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org WG Extensions" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 10:03:02 -0000 Dear Alfred, > > That's why this WG does not fulfill its mission and does not perform > actual maintenance of the protocols it pretends to shepherd. > this is the second time that I read such a statement from you. It's simply not true. The WG performs maintenance... What's about RFC 5681 - TCP Congestion Control => Maintenance RFC 5682 - F-RTO => Maintenance draft-ietf-tcpm-1323bis => Maintenance draft-paxson-tcpm-rfc2988bis => Maintenance draft-ietf-tcpm-tcpmss => Maintenance draft-ietf-tcpm-tcp-auth-opt => Maintenance draft-ietf-tcpm-tcp-lcd => Maintenance in a broader sense draft-ietf-tcpm-sack-recovery-entry => Maintenance ... You should not tar everything with the same brush, only because you are dissatisfied with the progress of one (or two) particular ID. > Please either shut down the WG now, or (what I would prefer much more) > encourage implementors to return and raise their voice again in the WG, > and commit to adhere to the principles Jari Arkko had recalled recently, > namely that the IETF should much more listen again to running code and > experience. The WG listens to running code. For example "draft-ietf-tcpm-sack-recovery-entry": The author Ilpo Jarvinen is currently the most active TCP Linux implementer! // // 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 // From nishida@sfc.wide.ad.jp Tue Mar 2 03:04:20 2010 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 B18933A8788 for ; Tue, 2 Mar 2010 03:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[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 76yfHwv5Ss-M for ; Tue, 2 Mar 2010 03:04:19 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id CA3923A877E for ; Tue, 2 Mar 2010 03:04:19 -0800 (PST) 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 387B64C53A for ; Tue, 2 Mar 2010 20:04:16 +0900 (JST) Date: Tue, 02 Mar 2010 20:04:16 +0900 (JST) Message-Id: <20100302.200416.205742851.nishida@sfc.wide.ad.jp> To: tcpm@ietf.org From: Yoshifumi Nishida In-Reply-To: <20100302100002.453A83A8B23@core3.amsl.com> References: <20100302100002.453A83A8B23@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-02.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: Tue, 02 Mar 2010 11:04:20 -0000 Hi People, I hope it is the right time for this.. I submitted the new version for draft-nishida-newreno-modification today. If someone could give me any feedback, I would be grateful very much. This draft describes the issue in Newreno. The problem I mentioned in the draft is if the following two conditions are satisfied, the tcp connection will encounter performance degradation. 1: receiver uses delayed ack 2: flightsize is 0 when tcp exits fast recovery I believe 1 is true for most of all implementations. The question is if 2 is a very corner case and can be negligible. I feel one of the reason why I hardly got any response so far is that people think 2 is negligble. So, I would like to present a simulation result here to claim that this might not be negligble. I used ns-2.34 and created 2 TCP nodes (sender and receiver) and created packet loss on the 10Mbps link between them. The tcp sender sent 100,000 packets to the receiver. The below table shows the number of events where flightsize becomes 0 after fast recovery. PLR=0.01 PLR=0.02 PLR=0.03 PLR=0.04 PLR=0.05 PLR=0.06 # of events 108 333 687 1140 1537 1916 >From this result, if PLR exceeds 0.04, the ratio of this event exceeds 1% of packet transmissin. This affects throughput drastically as shown in the below table. "newreno" is the current algorithm in RFC3782 and "proposed" is the proposed algorithm in the draft. throughput (kbps) PLR=0.01 PLR=0.02 PLR=0.03 PLR=0.04 PLR=0.05 PLR=0.06 newreno 825.57 451.96 284.25 190.13 137.99 107.05 proposed 1006.64 671.86 470.39 344.28 248.71 193.30 >From these results, I personally think this draft is worth being discussed. Again, If someone could give me any feedback, I would be grateful very much. I'm happy to discuss this at Anaheim if someone wants. Please check detailed simulation configurations and results in the draft. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Internet-Drafts@ietf.org Subject: I-D Action:draft-nishida-newreno-modification-02.txt Date: Tue, 2 Mar 2010 02:00:02 -0800 (PST) Message-ID: <20100302100002.453A83A8B23@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-02.txt > Pages : 16 > Date : 2010-03-02 > > 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-02.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 wesley.m.eddy@nasa.gov Tue Mar 2 08:06:34 2010 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 1A2983A8AAF; Tue, 2 Mar 2010 08:06:34 -0800 (PST) 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=[AWL=0.000, 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 p3fpst+sWhrm; Tue, 2 Mar 2010 08:06:32 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9AE513A84DB; Tue, 2 Mar 2010 08:06:32 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 4336B2C8485; Tue, 2 Mar 2010 10:06:33 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o22G6VYa011228; Tue, 2 Mar 2010 10:06:33 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Tue, 2 Mar 2010 10:04:57 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Lars Eggert , Fernando Gont Date: Tue, 2 Mar 2010 10:04:56 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq5t7w4SJIDeHByTzilqMOcgr270AAZp34w Message-ID: References: <201003012159.WAA15069@TR-Sys.de> <4B8C70C0.8090708@gont.com.ar> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-02_12:2010-02-06, 2010-03-02, 2010-03-02 signatures=0 Cc: "ah@tr-sys.de" , "tcpm@ietf.org WG" , The, IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 16:06:34 -0000 My reading of the consensus, as a WG co-chair, was 100% consistent with what Lars has explained. Since the -00 and -01 WG versions of the document also reflect that, I had thought the editor was on-board with that plan to make progress. Originally, in addition to support for the work, there was caution raised that the prescribed behaviors be each closely looked at. Since the pre-WG document does not identify individual recommendations nor is it reasonable to expect the full content of a 136-page document to be immediately vetted and sucked into the WG product, the path of taking pieces of it to be worked into the WG product is a logical and straight forward way to arrive at a quality product with clear support for the detailed content. That said, if the WG wants to change its mind, that is certainly an option for discussion, but it's not productive at all to get into tangents with wild accusations and suggestions that the WG be closed. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Lars Eggert >Sent: Monday, March 01, 2010 10:22 PM >To: Fernando Gont >Cc: ah@tr-sys.de; tcpm@ietf.org WG; The IESG >Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security > >Hi, > >On 2010-3-1, at 17:58, Fernando Gont wrote: >> Lars Eggert wrote: >> >>> More importantly, you claim that some group of people has "redefined" >>> the WG consensus. This is a serious accusation against the chairs and >>> me as AD. Please provide specific details or retract this accusation. >> >> Lars, >> >> I had made this comment a month ago or so, and at the time I preferred >> not to answer you "provide details" request, in the hope of looking >> forward. > >the exact phrasing in your earlier email was that I "seemed to ignore WG >consensus". Alfred now says that I "redefined" WG consensus. Both are >very serious accusations. I believe that I did not mishandle things here >(see below for details), but I'm obviously biased. I encourage others to >speak up. > >If you really believe I acted improperly, please start a recall >petition. Otherwise, please stop accusing me of misconduct and >apologize. This is the last email I'm going to send on this topic. > >> However, given that this has been raised again, I'll respond >> this time: > >Thank you. > >> Earlier this year this working group was specifically polled about >> adopting draft-gont-tcp-security as a WG item. The WG had >unprecedented >> strong consensus in this respect (with people even offering to spend >> cycles on document review), and this consensus was even noted in the >> slides the wg chairs used in the TCPM meeting at IETF 75 (see: >> http://www.ietf.org/proceedings/75/slides/tcpm-2/tcpm-2.htm). > >no disagreement so far - there was strong consensus to adopt a work item >on describing a security assessment of various TCP aspects. > >> At the meeting, you (IIRC) raised the question about whether we wanted >> to work on this document, or start with a new one (!). > >I don't think this is quit accurate. What happens when a WG takes on new >work is that they decide to take on a work item, and then they decide >which individual document (if any) can be adopted as the basis for >progressing this work item forward. > >As I said, there was strong consensus to take on the work item. When we >discussed whether the CNPI document was a good starting point, I wanted >to make it clear that we'd be taking on a very substantial piece of text >that had already been published. > >If I recall correctly, the WG did discuss for a while if there would be >any argument for basically republishing the CNPI document through the >IETF, and my take away from the discussion was that the WG felt that an >IETF document in this space should say something more or differently >than what the CNPI document had said. > >That's why we arrived at the decision to come to consensus on an new >document structure first and then merge in content from the (long) CNPI >document in a piecemeal fashion. > >> -- basically >> throwing out of the window the 2-year effort of writing the CPNI TCP >> security assessment on which draft-ietf-tcp-security is based. > >The CNPI document is published. Nothing the IETF can do invalidates the >effort that went into it. Starting with a different outline (that's what >the WG decided on) and merging in content from the CNPI document is not >"throwing out the window" all that effort. > >> IMO, that's part of obstructing, and/or "not invented here" (NIH) >syndrome. > >But neither of the two (irrespective of whether they are true or not) >are indicative of me ignoring WG consensus. > >The discussion of whether to adopt this specific draft as a basis for >the work item (and in which form) was still in full swing on the list >and during the meeting week. Sure, I spoke up during this discussion. >But that's not ignoring WG consensus. > >> FWIW, It's interesting to note that IAB's Gregory Lebovitz was there >at >> the TCPM meeting, and commented that "WGs don't need drafts to 100% >> right to become WG items". (and, btw, only two or three people at that >> meeting said that they had actually read the document.) > >It may be interesting to note, but it is unrelated to the accusation you >make. > >> After the meeting, you argued (off-list) that wg consensus (allegedly >as >> a result of IETF 75??!) was to submit a "fresh" (i.e., blank/brand- >new) >> document > >The WG consensus after IETF-75 *was* to start with a new document >structure. That's why after IETF-75, you posted a revision that >contained just the outline and we discussed it. See >http://www.ietf.org/mail-archive/web/tcpm/current/msg04813.html and >follow-ups. > >> , when we already had consensus *before* the meeting, on the >> *mailing-list* (as the IETF mandates it should be) for adopting >> draft-gont-tcp-security. > >The discussion started in http://www.ietf.org/mail- >archive/web/tcpm/current/msg04641.html was still in full swing during >IETF-75 - the chairs had not declared consensus. That happened at the >end of IETF-75: http://www.ietf.org/mail- >archive/web/tcpm/current/msg04777.html > >> You even suggested that tcpm should assemble "a >> team of editors" > >Yes, probably. As I said during the meeting, I believe that this would >be the largest work item in TCPM in terms of effort, so strong support >is required. > >> (when you should have probably made this observation >> for the non-progressing tcp-ao, rather than for this newly adopted I- >D). > >Irrelevant for the discussion at hand. > >> Last, but not least, anybody interested in the meeting I'm referring >to >> are advised to listen to the meeting recordings, rather than reading >the >> tcpm meeting minutes. > >What specifically in the audio recordings backs up your accusation that >is not also in the minutes? You're making the accusation that I'm >ignoring WG consensus, so it's on you to provide the data. > >To summarize (because below is about a different instance): I have seen >no evidence that I mishandled anything in this case. But I'm obviously >biased. I encourage others to speak up. > >> Another instance (but this one older, and in tsvwg): >> I could also mention that when tsvwg was polled years ago (you were >> co-chair of that wg at the time) about adopting >> draft-larsen-port-randomization (now draft-ietf-port-randomization) as >a >> wg item, at some point something like 5+ people were supporting the >> adoption of the document as a tsvwg item (targeting *std* track)... >but >> you mentioned that that didn't represent wg consensus. >> Then the voice of three people (yours included) changed the target >from >> Std track to BCP. (And no... I'm not arguing that std track was more >> correct than bcp. I'm just arguing that the process, and your view of >> "consensus", are not clear to me). > >If you want to make that accusation, please dig through the minutes to >back this up with facts to make a case, instead of giving an anecdotal >summary. I will point out that I acted as chair during the adoption of >an individual document as a WG work item, and it is normal procedure to >try and determine what the correct document type would be. The consensus >is what concludes this process, and it is called by the chairs (three in >this case). > >If you really believe I acted improperly, please start a recall >petition. Otherwise, please stop accusing me of misconduct and >apologize. This is the last email I'm going to send on this topic. > >Lars From wesley.m.eddy@nasa.gov Tue Mar 2 09:45:38 2010 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 9F4513A8B6D for ; Tue, 2 Mar 2010 09:45:38 -0800 (PST) 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=[AWL=0.000, 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 v6QIP81VzajF for ; Tue, 2 Mar 2010 09:45:37 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 3477F3A8BB1 for ; Tue, 2 Mar 2010 09:45:37 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 29F292D9B2E; Tue, 2 Mar 2010 11:45:38 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o22HjbAf014184; Tue, 2 Mar 2010 11:45:37 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Tue, 2 Mar 2010 11:45:37 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Alexander Zimmermann , David Borman Date: Tue, 2 Mar 2010 11:45:36 -0600 Thread-Topic: Anaheim TCPM draft agenda available? Thread-Index: Acq1Ub+oMqAXxdBXQO29PSnhX/rB/gE3Dogg Message-ID: References: <88C9959E-A011-4D01-BD42-8CB2112C71A9@nets.rwth-aachen.de> In-Reply-To: <88C9959E-A011-4D01-BD42-8CB2112C71A9@nets.rwth-aachen.de> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-02_12:2010-02-06, 2010-03-02, 2010-03-02 signatures=0 Cc: "tcpm@ietf.org WG Extensions" Subject: Re: [tcpm] Anaheim TCPM draft agenda available? 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, 02 Mar 2010 17:45:38 -0000 Yes, currently we're working on the agenda; an initial draft is below based on some things we knew people had asked about presenting, which may be tentative. So, if anyone else wants a slot, please ask David and I, and if you're on the agenda below and want to confirm your availability and that the timeslot is sufficient that would be good too: Tuesday, March 23, 2010 1300 - 1500 ----------------------------------- WG Status chairs 10 minutes TCP-LCD Alexander Zimmerman 5 minutes Middlebox Discovery Andrew Knutsen 25 minutes Reducing the Initial RTO Jerry Chu 25 minutes Increasing the Initial CWND Jerry Chu 25 minutes TCP Security Recommendations rest of session (tentative plan to have a "working meeting" and initially vet a list of individual recommendations into the document) -- Wes Eddy MTI Systems >-----Original Message----- >From: Alexander Zimmermann [mailto:alexander.zimmermann@nets.rwth- >aachen.de] >Sent: Wednesday, February 24, 2010 8:03 AM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Borman >Cc: tcpm@ietf.org WG Extensions >Subject: Anaheim TCPM draft agenda available? > >Hi Wes, David, > >is the draft agenda for the upcoming TCPM meeting available? > >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 >// From wesley.m.eddy@nasa.gov Tue Mar 2 10:23:51 2010 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 6DBC428C214 for ; Tue, 2 Mar 2010 10:23:51 -0800 (PST) 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=[AWL=0.000, 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 pIn9y1NhjlFi for ; Tue, 2 Mar 2010 10:23:49 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 8F4AA3A8339 for ; Tue, 2 Mar 2010 10:23:49 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7CC963280E6; Tue, 2 Mar 2010 12:23:50 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o22INoGS022655; Tue, 2 Mar 2010 12:23:50 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 2 Mar 2010 12:23:50 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Costin Raiciu , "tcpm@ietf.org" Date: Tue, 2 Mar 2010 12:23:48 -0600 Thread-Topic: [tcpm] Multipath TCP signaling Thread-Index: Acq1PAsO0Cilj9rqThOClhH5BBBAfQE9lIuA Message-ID: References: <168921C8-87E9-4502-9DD5-119A71F15EF6@cs.ucl.ac.uk> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-02_12:2010-02-06, 2010-03-02, 2010-03-02 signatures=0 Subject: Re: [tcpm] Multipath TCP signaling 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, 02 Mar 2010 18:23:51 -0000 This is an interesting question. My initial response would be to definitely use the options approach. I could be completely wrong, but my memory is that middleboxes weren't filtering new options very aggressively in the studies that have been done with tbit and other tools, plus (as you noted) you have to use new options anyways to signal the multipath capability. For the question of options reliability, I've seen a project in the past that essentially ran TCP within the TCP options space, by setting a few bits of the option to represent options-sequence numbers and options-ack numbers (since the data-rate of the options stream is lower, the number of bits needed is reduced from the size of these fields in the normal TCP header). I don't know if that would work well here or not, but it would be food for thought at least. -- Wes Eddy MTI Systems >-----Original Message----- >From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of >Costin Raiciu >Sent: Wednesday, February 24, 2010 5:28 AM >To: tcpm@ietf.org >Subject: [tcpm] Multipath TCP signaling > >Hi, > >In the multipath TCP working group we are trying to decide which is the >best way to signal multipath specific information between endpoints. We >are writing this message to invite contributions and thoughts from >members of the tcpm list, as we believe that whatever solution we choose >will impact other tcp signaling in the future. > >Let me briefly tell you what we are trying to do. > >Multipath works by assigning a data level sequence number to application >data, and sending this data over different "subflows" which look like >tcp over the wire. These subflows have their own sequence numbers too, >on top of the data sequence number. > >The information multipath needs to get across is: >- multipath enabled / join connection - this is only on flow/subflow >startup >- data sequence number (each segment must have this to enable the >receiver to reorder data) >- add/remove ip to connection (not often) >- security negotiation, if needed >- subflow policy, etc. > >We have analyzed the requirements of this control information (e.g. >reliable, in order) and two basic ways of signaling it: >- using TCP options - this is the traditional TCP way of signaling >control information; it is unreliable and the space is limited, it will >be a bit difficult to get it through existing middleboxes, but it plays >nice with future "multipath aware" middleboxes. >- using the payload - this would use TLV like encoding (as in tls) and >does not have space issues. However, all the control info is now >ordered, congestion controlled and reliably sent - which may not be what >we want. This will get through more middleboxes today, but it is not >nice to future middleboxes: they have to keep state to be able to parse >the control info. Also, the middleboxes cannot easily add control info >(this is contentious, I know, but should be possible). > >The detailed analysis is in the following doc: >http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf > >What do people think is the best approach? >Costin >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Tue Mar 2 10:31:51 2010 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 92F7428C0FE for ; Tue, 2 Mar 2010 10:31:51 -0800 (PST) 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 WzUoGV2QmwpW for ; Tue, 2 Mar 2010 10:31:50 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6224328C0ED for ; Tue, 2 Mar 2010 10:31:50 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o22IVmMn009700; Tue, 2 Mar 2010 10:31:48 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 109E4A182EC; Tue, 2 Mar 2010 13:31:48 -0500 (EST) To: Alexander Zimmermann , hkchu@google.com, vern@icir.org, "tcpm@ietf.org Extensions WG" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money For Nothing MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma22929-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 02 Mar 2010 13:31:48 -0500 Sender: mallman@icir.org Message-Id: <20100302183148.109E4A182EC@lawyers.icir.org> Subject: Re: [tcpm] New ID available: RFC2988bis (RTO calculation) 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: Tue, 02 Mar 2010 18:31:51 -0000 ----------ma22929-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [This is a re-send. My original note did not make it to the list. I made a tweak to my mail setup. Lets see if this works. --allman] > currently the document only suggests lowering the initial RTO. > IMHO we should also discuss if we want to lower the minimal RTO, too. I have two responses to this ... - First, I sent a technical note to the list on Feb/11 about changing the min. I am appending that to this note. - Second, it seems that we should keep these two questions independent to me. It seems to me that changing the initRTO is pretty minor and well-scoped, whereas changing the minRTO has more unknowns. So, I am not at all opposed to thinking about both changes as you suggest, but coupling them is likely to hinder progress on the initRTO (IMO). Just my 2c. allman > Is it time to reconsider a smaller minimum RTO as well? One problem with the minimum is we don't know what to set it at [*]. The finding in [AP99] is that as you reduce the min you take more spurious timeouts. The tradeoff seemed fundamental to us. But, given our methodology (trace driven simulation) we could not really tell the impact of the spurious timeouts. So, we just sought to minimize them in the spec. I know some TCP implementations are being pretty aggressive with the min these days. But, it is not at all clear to me whether this is a net win or net lose. I.e., is the win in terms of peppiness to needed retransmits still a win when it is played against the consequences of a spurious transmit (i.e., setting cwnd = 1)? Perhaps there is a sweet spot that is < 1sec whereby this tradeoff better balances and we should be using that. But, it'd take a big experiment to show that, I think. [*] Maybe there is work that I just don't know about and if so I'd like to be pointed at it. Another thing I have wondered about from time to time .... Much like Early Retransmit could we have some sort of early RTO when the cwnd size is small? When the window size is small it seems that the downside of making a bad rexmt decision is not as bad as when the cwnd is large so it might pay in terms of responsiveness to RTO sooner. Also, as the cwnd gets larger we have better loss recovery techniques that should come into play that can repair lots of loss without involving the RTO and so perhaps by being overly aggressive in the RTO we just hurt ourselves. Finally, as the cwnd gets bigger that means we are transferring more data. And, the longer a connection goes the less important the fine-grained responsiveness matters. Just a random thought ... allman ----------ma22929-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuNWZMACgkQWyrrWs4yIs5szwCeMd6LxZfBp6G9Y++dKk2bjsVG JDQAoIFmEF5w6SFbkuqlDKAKuWakdqb8 =QXA5 -----END PGP SIGNATURE----- ----------ma22929-1-- From mallman@icir.org Tue Mar 2 10:32:20 2010 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 F378A28C219 for ; Tue, 2 Mar 2010 10:32:19 -0800 (PST) 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 AUoJDzIza7kA for ; Tue, 2 Mar 2010 10:32:18 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 1CE3528C0FE for ; Tue, 2 Mar 2010 10:32:18 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o22IWI7J009807; Tue, 2 Mar 2010 10:32:19 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AAD83A18339; Tue, 2 Mar 2010 13:32:18 -0500 (EST) To: Alexander Zimmermann , "tcpm@ietf.org Extensions WG" , "vern@icir.org" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money For Nothing MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma22962-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 02 Mar 2010 13:32:18 -0500 Sender: mallman@icir.org Message-Id: <20100302183218.AAD83A18339@lawyers.icir.org> Subject: Re: [tcpm] New ID available: RFC2988bis (RTO calculation) 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: Tue, 02 Mar 2010 18:32:20 -0000 ----------ma22962-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [This is a re-send. My original note did not make it to the list. I made a tweak to my mail setup. Lets see if this works. --allman] > what a quick response :-) It happens every once in a while. Don't get used to it! :) > > - First, I sent a technical note to the list on Feb/11 about changing > > the min. > > Sure? On this list...? > Anyway, since you appended the text, I can read it. In the 'TCP tuning' thread. I didn't bother to look to see if it actually made it through. I found it in my outbox. > > - Second, it seems that we should keep these two questions independent > > to me. It seems to me that changing the initRTO is pretty minor and > > well-scoped, whereas changing the minRTO has more unknowns. So, I > > am not at all opposed to thinking about both changes as you suggest, > > but coupling them is likely to hinder progress on the initRTO > > (IMO). > > Yes, full ACK. However, I suggest that we add some text (like > your appended note below or your comments here > http://www.ietf.org/mail-archive/web/tcpm/current/msg02937.html) > to the draft, why we not lower minRTO at this time. It is a fair point that we should perhaps better motivate the 1sec choice in the document. A usual problem in IETF documents: we are better at the 'what' than the 'why'. allman ----------ma22962-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuNWbIACgkQWyrrWs4yIs7DAgCaA8V50GyfnmtzsrI8fIqOui/b Wg8Ani6XUWkJt2CP1jlWPTM3lyPKZUft =ANKI -----END PGP SIGNATURE----- ----------ma22962-1-- From mallman@icir.org Tue Mar 2 11:43:16 2010 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 1B5A028C172 for ; Tue, 2 Mar 2010 11:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.289 X-Spam-Level: X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, LOCALPART_IN_SUBJECT=2.02, 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 dKx3B5pus4Th for ; Tue, 2 Mar 2010 11:43:14 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id C83C928C16F for ; Tue, 2 Mar 2010 11:43:14 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o22JhF73019503 for ; Tue, 2 Mar 2010 11:43:15 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 4BBC1A18F97 for ; Tue, 2 Mar 2010 14:43:15 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Money For Nothing MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma27219-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 02 Mar 2010 14:43:15 -0500 Sender: mallman@icir.org Message-Id: <20100302194315.4BBC1A18F97@lawyers.icir.org> Subject: [tcpm] TCPM 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: Tue, 02 Mar 2010 19:43:16 -0000 ----------ma27219-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- I have mostly been lurking lately, but I have read a few of these process-y notes recently and have shortened my life with far too many inane TCPM threads over the years. It is clear some people are frustrated. However, I do not agree that this frustration should be pointed at the chairs or ADs (I wore one of those hats for some of the ongoing work, so I am not unbiased, but...). It seems to me there is frustration from a bunch of angles here---and that people are not considering the full scope. It seems to me there is frustration: - ...that some people are viewed as being overly pedantic. I believe this is true. - ...that some people place too much emphasis on 'running code' and not enough on technical principles. I believe this is true. - ...that some people place too much emphasis on technical principles and not enough on 'running code'. I believe this is true. - ...that a not insignificant portion of the documents brought to the working group and adopted by the working group are poorly written (regardless of the technical merit). I believe this is true. - ...that discussion is sometimes circular with the same comments being made over-and-over. I believe this is true. - ...that technical comments are not responded to with technical counter-arguments. I believe this is true. - ...that sometimes WG decisions are not as clearly stated as they could be. I believe this is true. - ...that TCP is overly hard to change. I believe this is true. - ...that TCP should not be changed unless the Internet would melt otherwise. I believe this is true. I believe all of these things can be frustrating. I can very much sympathize with frustration from all sides. (Note: I take my share of the blame for each of these.) I have a series of suggestions that I think would perhaps provide a better and more timely set of work in this WG. The first set is for the members and the second set is for the chairs: (M.1) Try to rate limit yourself. Send one message / day (say) on each draft. If the point you want to make doesn't seem big enough to blow your one message on then just forget it. Or, send it off-list. (M.2) Label your comments explicitly as "nit" or "small annoyance" or "major technical bone of contention" or some such. I.e., clue the reader in to how serious you think a document failure is. And, then, stick to your classification. There is no use having a knock-down, drag-out fight over a universally agreed small issue. (M.3) Try to not be so damned pedantic. We all have pet-peeves and things we consider "wrong", but in the grand scheme of things don't matter one whit. I cannot stress this enough: if you are arguing about a two word phrase you are **off the effin' rails**. The pedanticness causes myriad problems: from just being overall a no-op on the document to making people tune threads out to making people tune out the entire WG to making people less likely to enter a discussion because of the cost:benefit being tilted far too much towards "cost". Messages sent to the list have an impact on the overall environment and the WG's ability to do business. This impact can be greater than whatever particular point you are trying to convey. (M.4) When a technical point is made, try to answer it with a technical point. There is often an impedance mis-match on this list that leads to loops. E.g., "technical principle [X] suggests we should not do [Y]" followed by "but [Y] is done in OSes A, B and C". These two statements are just talking past each other and so both points remain unaddressed. Running code is a useful data point and can be suggestive of how something will work. But, all running code (and in particular any number of tweaks to TCP) is not a good idea. We have a long RFC on problems with TCP implementations [RFC2525]. Remember: Just because something is used doesn't make it a good idea. Remember: Having something implemented and running offers a valid data point that is not for nothing. I.e., play nicer. But, since I don't really expect you to do so I have some suggestions for the chairs: (C.1) Drum up some document editors. One of the issues is that the pens are in the hands of pedantic partisans. This does not help the WG get its work done because one of the strong principals in the discussion also holds the ability to write the final words. This means that they can prevent some words from being penned and also that it clouds their thinking about the words they do write (that they may not agree with). For each controversial document (which should be determinable from the pre-adoption discussion) find someone who (a) is not hardened on one side or the other and (b) knows how to actually write quality documents to do the bulk of the writing. That doesn't mean the technical originators don't get their authorship. It adds someone to the process who can more easily word a compromise and assert that while it didn't make everyone perfectly happy that in the absence of much WG disagreement the particular language is staying. Note: I am not suggesting someone come in to take over the technical development of the document. I am suggesting someone come in who can put together *the document* that the **WG** develops without having a particularly hardened opinion of the technology. (This more applies to the extensions and not the maintenance---the latter being much less controversial in general.) (C.2) The decision about accepting work items and using a particular document as the starting point are often conflated. These are separate decisions and obviously there has been confusion on this point in some cases. The questions should be posed independently. "Should we take on a work item to developed a TCP extension to do [foo]?" and given that the answer is "yes" then we can ask "should we use [draft-bar] as the basis or work up something new?". In conjunction with naming an independent editor this should make the process much more clear. (C.3) Put big decisions in explicit emails---not at the end of long threads. I.e., use a subject like "TCPM DECISION: draft-foobar" and then in that email you can write "passwd WGLC", "decided to target status Proposed Standard", "named Bob Smith as document editor", etc. This will help people who might have lost interest in a long and winding pedantic thread understand what happened. It will also explicitly call attention to a decision point (which of course can be challenged). (C.4) In the WG status (which is a fabulous tool and David and Wes should be thanked for starting it) particular decisions can be referenced. E.g., "Target: PS (per email: http//....)". (C.5) When there is a particular point of disagreement it could be framed in a new thread and posed to the group by the chairs. "Alice & Bob have reached an impasse. We're looking for input as to whether we should go with [foo] or [bar]." (with sketches of the approaches). This may get more voices in the process than figuring out this impasse at the end of a long and messy thread. In sum, the WG is what we make it. I believe there are some fairly easy things we can each do. But, at this point I think possibly the most important thing we could do would be to put the pens in the hands of people who are a bit outside the fray. FWIW. allman ----------ma27219-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuNalMACgkQWyrrWs4yIs4g/QCeLJHe2Fyx+sFkzY+cBppb1aUp Xw0An28GNyh59pOMn46pxuiYtg2bcGS8 =O0RM -----END PGP SIGNATURE----- ----------ma27219-1-- From fernando@gont.com.ar Tue Mar 2 11:55:40 2010 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 E6AEB28C164; Tue, 2 Mar 2010 11:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 PyMlw+Nf0j6t; Tue, 2 Mar 2010 11:55:40 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 063F93A8AFA; Tue, 2 Mar 2010 11:55:38 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0E9056B6A61; Tue, 2 Mar 2010 16:55:41 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o22JtYWo006129; Tue, 2 Mar 2010 16:55:35 -0300 Message-ID: <4B8D6D39.4020102@gont.com.ar> Date: Tue, 02 Mar 2010 16:55:37 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <201003012159.WAA15069@TR-Sys.de> <4B8C70C0.8090708@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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, 02 Mar 2010 16:55:40 -0300 (ART) Cc: "ah@tr-sys.de" , "tcpm@ietf.org WG" , The IESG Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 02 Mar 2010 19:55:41 -0000 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Originally, in addition to support for the work, there > was caution raised that the prescribed behaviors be > each closely looked at. Yes. Isn't this *always* the case for any document that is accepted? For instance, the motivation of bringing this to the IETF was, in part, to have more eyes evaluating the requirements. And as noted before, an I-D does not need to be perfect to be accepted by a wg. For instance, that's why it's a draft. > Since the pre-WG document does > not identify individual recommendations nor is it > reasonable to expect the full content of a 136-page > document to be immediately vetted and sucked into the > WG product, the path of taking pieces of it to be > worked into the WG product is a logical and straight > forward way to arrive at a quality product with clear > support for the detailed content. I personally believe that this is a reasonable approach for making progress with this document. But this is different from what Lars was arguing. Anyway... time to move on, I think... -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dab@weston.borman.com Tue Mar 2 13:03:16 2010 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 C59F43A7984 for ; Tue, 2 Mar 2010 13:03:16 -0800 (PST) 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 GadlWYINnDkD for ; Tue, 2 Mar 2010 13:03:16 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id B19E93A6920 for ; Tue, 2 Mar 2010 13:03:15 -0800 (PST) Received: from weston-59.weston.borman.com (weston-59.weston.borman.com [206.196.45.59]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o22L37q1003220; Tue, 2 Mar 2010 15:03:07 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> Date: Tue, 2 Mar 2010 15:03:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> To: "tcpm@ietf.org WG" X-Mailer: Apple Mail (2.1077) Cc: tcpm-chairs@tools.ietf.org, ayourtch@cisco.com, Fernando Gont Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Tue, 02 Mar 2010 21:03:16 -0000 WG chair hat on: ---------------- We are well past the end of the WGLC for this document. On February 19, = a new draft: draft-ietf-tcpm-urgent-data-03.txt was posted. I have reviewed the differences between the -02 and -03 = versions, and it appears to me that all of the issues that were raised = against the -02 version have been addressed in the -03 version. There = have been no additional comments on the mailing list since the -03 = version was made available. Therefore, we will be sending this document to the IESG in the next day = or two, so if you have any additional issues with the -03 draft, you = should speak up immediately. -David Borman, TCPM co-chair WG chair hat off: ----------------- I just realized that: 1) The document should have at the top: Updates: RFCs 793, 1011, 1122 2) The "1. Introduction" section should say that it updates all 3 RFCs, = not just RFC 1122. 3) The Normative References should include RFC 1011. 4) The "4. Updating RFC 1122" section should also mention all 3 RFCs, = not just RFC 1122 The other RFCs that talk about the urgent pointer, 924, 944, 961 and = 991, are all obsoleted by RFC 1011, hence only RFC 1011 needs to be = mentioned. -David Borman On Feb 5, 2010, at 1:38 PM, David Borman wrote: > Note: As recent discussions on this list have indicated, we need = members of this mailing list to be involved. Please take the time to = read through this document and send a message to the mailing list either = supporting publishing this document, or commenting on why it is not = ready to be published. This particular document is quite short and easy = to understand. -David Borman, TCPM co-chair. > ---------------------------- >=20 > This is to announce the start of the WG Last Call for: >=20 > Title : On the implementation of the TCP urgent mechanism > Author(s) : F. Gont and A. Yourtchenko > Filename : draft-ietf-tcpm-urgent-data-02.txt > Pages : 13 > Date : November 26, 2009 > Intended Status : Proposed Standard >=20 > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-02.txt >=20 > It is our understanding that all the feedback has been incorporated = into this latest version and that there are no known outstanding issues = with this document. >=20 > Please send feedback to the list. >=20 > The WGLC will end on Friday, February 19, 2010. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From johnwheffner@gmail.com Tue Mar 2 13:36:26 2010 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 50A603A8CC7 for ; Tue, 2 Mar 2010 13:36:26 -0800 (PST) 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 UomNAllulbC9 for ; Tue, 2 Mar 2010 13:36:25 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2DC293A8CBF for ; Tue, 2 Mar 2010 13:36:25 -0800 (PST) Received: by wyb40 with SMTP id 40so386126wyb.31 for ; Tue, 02 Mar 2010 13:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=N99G3wu7VhPFKztyWs+f73c6T7D/X9mujGGmvxlsqSk=; b=Feb34+i6ShmsPnLT83rZOPCiFP3/l1+xYqG+bYIrlkZ7pqWJTDlrXMdIfbIgNpGAVH txXJpDwtZzrZIbVnwGVDX1MpcwwsbhGuw7FsLfrCYy811x/S0VbL1ZUlABr1UJZ877s7 vcaaqsss3X7TCjKKOPDaMSJD8sDo9fQblHBsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=N9C/mdalXr/Fekct5YIk+LIR1yDeavabCru/8Trhw9jlqGyrKdvh+wtFLbOvN7GuRT AkcxsRER3+LQb0dSlDOEdkuiFU0NuFHikFYfd0rU8Gav33vEsF1eeP30NLB/5UPzQhek owV3yqX2vvQvE3BmW3cprXC+vt72G0IfBdJwQ= MIME-Version: 1.0 Received: by 10.216.93.66 with SMTP id k44mr280914wef.63.1267565782199; Tue, 02 Mar 2010 13:36:22 -0800 (PST) In-Reply-To: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> Date: Tue, 2 Mar 2010 16:36:22 -0500 Message-ID: <1e41a3231003021336v549699e1yfb4c329d82fd38c8@mail.gmail.com> From: John Heffner To: David Borman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org WG" , ayourtch@cisco.com, Fernando Gont Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Tue, 02 Mar 2010 21:36:26 -0000 On Tue, Mar 2, 2010 at 4:03 PM, David Borman wrote: > WG chair hat on: > ---------------- > We are well past the end of the WGLC for this document. =A0On February 19= , a new draft: > =A0 =A0 =A0 =A0draft-ietf-tcpm-urgent-data-03.txt > was posted. =A0I have reviewed the differences between the -02 and -03 ve= rsions, and it appears to me that all of the issues that were raised agains= t the -02 version have been addressed in the -03 version. =A0There have bee= n no additional comments on the mailing list since the -03 version was made= available. > > Therefore, we will be sending this document to the IESG in the next day o= r two, so if you have any additional issues with the -03 draft, you should = speak up immediately. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-David Borman, TCPM co-cha= ir > > WG chair hat off: > ----------------- > I just realized that: > 1) The document should have at the top: > =A0 =A0 =A0 =A0Updates: RFCs 793, 1011, 1122 > 2) The "1. Introduction" section should say that it updates all 3 RFCs, n= ot just RFC 1122. > 3) The Normative References should include RFC 1011. > 4) The "4. Updating RFC 1122" section should also mention all 3 RFCs, not= just RFC 1122 > > The other RFCs that talk about the urgent pointer, 924, 944, 961 and 991,= are all obsoleted by RFC 1011, hence only RFC 1011 needs to be mentioned. Nit: in the title of Section 2.1: s/inications/indications/ -John From fernando@gont.com.ar Tue Mar 2 14:14:05 2010 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 CC2DB28C27E for ; Tue, 2 Mar 2010 14:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ngJgKIZLrsON for ; Tue, 2 Mar 2010 14:14:04 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 74FD528C283 for ; Tue, 2 Mar 2010 14:13:37 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3C9846B6714; Tue, 2 Mar 2010 19:13:41 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o22MDXCI022038; Tue, 2 Mar 2010 19:13:34 -0300 Message-ID: <4B8D8AAF.50402@gont.com.ar> Date: Tue, 02 Mar 2010 19:01:19 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> In-Reply-To: X-Enigmail-Version: 0.96.0 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, 02 Mar 2010 19:13:40 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Tue, 02 Mar 2010 22:14:05 -0000 Hi, David, Thanks so much for pushing this forward! Comments inline... > WG chair hat off: ----------------- I just realized that: 1) The > document should have at the top: Updates: RFCs 793, 1011, 1122 Will ask on the xml2rfc list what's the xml code to do that. If anybody knows, please do let me know. > 2) The > "1. Introduction" section should say that it updates all 3 RFCs, not > just RFC 1122. Will do. > 3) The Normative References should include RFC 1011. Will do. > 4) The "4. Updating RFC 1122" section should also mention all 3 RFCs, > not just RFC 1122 Will do. > The other RFCs that talk about the urgent pointer, 924, 944, 961 and > 991, are all obsoleted by RFC 1011, hence only RFC 1011 needs to be > mentioned. Ok. Will go through the draft and try to replace references to the aforementioned RFCs with references to RFC 1101. If you agree, I can post a rev in the next few days, so that we ship the I-D with all these tihngs fixes (plus the nit John Heffner has just pointed out). 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 Tue Mar 2 14:14:08 2010 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 DDAFA28C28A for ; Tue, 2 Mar 2010 14:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 8fJeJGTiHNRx for ; Tue, 2 Mar 2010 14:14:07 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0C48628C29E for ; Tue, 2 Mar 2010 14:13:42 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 72D746B66E3; Tue, 2 Mar 2010 19:13:46 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o22MDd0v022052; Tue, 2 Mar 2010 19:13:40 -0300 Message-ID: <4B8D8D85.6090708@gont.com.ar> Date: Tue, 02 Mar 2010 19:13:25 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: John Heffner References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <1e41a3231003021336v549699e1yfb4c329d82fd38c8@mail.gmail.com> In-Reply-To: <1e41a3231003021336v549699e1yfb4c329d82fd38c8@mail.gmail.com> X-Enigmail-Version: 0.96.0 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, 02 Mar 2010 19:13:46 -0300 (ART) Cc: David Borman , "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Tue, 02 Mar 2010 22:14:09 -0000 John, John Heffner wrote: >> The other RFCs that talk about the urgent pointer, 924, 944, 961 >> and 991, are all obsoleted by RFC 1011, hence only RFC 1011 needs >> to be mentioned. > > Nit: in the title of Section 2.1: s/inications/indications/ Thanks! Will fix this in the next rev. 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 hkchu@google.com Tue Mar 2 14:50:58 2010 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 F07AC28C1C5 for ; Tue, 2 Mar 2010 14:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[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 PwNqK484-2y9 for ; Tue, 2 Mar 2010 14:50:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 578A53A7A68 for ; Tue, 2 Mar 2010 14:50:55 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id o22MorZi027839 for ; Tue, 2 Mar 2010 14:50:54 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1267570254; bh=6Vfro2At9mWiNW1+qiE9bCyJ6lk=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding; b=mEboC5joF7gPmAYNaMXJ8Nl0OP+IvfAcjbAly+PSdsmkHEcuG6wiZ/2UuMNiYVoKg ou6HZSD0kHD92n+NQSG5Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:cc: content-type:content-transfer-encoding:x-system-of-record; b=SuydHkLTyVg7CwgR9sbXNrw9IYXLdH/2SpybYHfew9wY8MnMjgFbxo+cimYxQUucO rEnGw6WnlmPDYmK+/z2lw== Received: from iwn36 (iwn36.prod.google.com [10.241.68.100]) by spaceape11.eur.corp.google.com with ESMTP id o22MopXZ023212 for ; Tue, 2 Mar 2010 14:50:52 -0800 Received: by iwn36 with SMTP id 36so761294iwn.28 for ; Tue, 02 Mar 2010 14:50:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.153.1 with SMTP id i1mr285753ibw.35.1267570251646; Tue, 02 Mar 2010 14:50:51 -0800 (PST) Date: Tue, 2 Mar 2010 14:50:51 -0800 Message-ID: From: Jerry Chu To: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Nandita Dukkipati Subject: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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: Tue, 02 Mar 2010 22:50:58 -0000 Our first draft proposal to raise the initial congestion window was submitt= ed a couple of days ago and is available at http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt A paper with the title "An Argument for Increasing TCP=92s Initial Congesti= on Window" detailing our large scale experiments will soon be available at http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf (The link is not there yet due to a last minute snag. Hopefully it will be fixed asap.) Comments are welcome. Jerry ---------------------------------------------------------------------------= -------------------------------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt X-RSN: 1/0/935/28943/32298 X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D32298 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Increasing TCP's Initial Window Author(s) : J. Chu, et al. Filename : draft-hkchu-tcpm-initcwnd-00.txt Pages : 16 Date : 2010-02-28 This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. Finally, it outlines a list of concerns to be addressed in future tests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dab@weston.borman.com Tue Mar 2 16:20:30 2010 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 52D5B28C0DC for ; Tue, 2 Mar 2010 16:20:30 -0800 (PST) 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 m3c8D4D8eScv for ; Tue, 2 Mar 2010 16:20:28 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 4DBDA3A8884 for ; Tue, 2 Mar 2010 16:20:26 -0800 (PST) Received: from [172.25.44.2] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o230KLq1004124; Tue, 2 Mar 2010 18:20:21 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4B8D8AAF.50402@gont.com.ar> Date: Tue, 2 Mar 2010 18:20:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 03 Mar 2010 00:20:30 -0000 Fernando, On Mar 2, 2010, at 4:01 PM, Fernando Gont wrote: > Hi, David, >=20 > Thanks so much for pushing this forward! >=20 > Comments inline... >=20 >> WG chair hat off: ----------------- I just realized that: 1) The >> document should have at the top: Updates: RFCs 793, 1011, 1122=20 >=20 > Will ask on the xml2rfc list what's the xml code to do that. If = anybody > knows, please do let me know. >=20 >=20 >> 2) The >> "1. Introduction" section should say that it updates all 3 RFCs, not >> just RFC 1122.=20 >=20 > Will do. >=20 >=20 >> 3) The Normative References should include RFC 1011.=20 >=20 > Will do. >=20 >=20 >> 4) The "4. Updating RFC 1122" section should also mention all 3 RFCs, >> not just RFC 1122 >=20 > Will do. >=20 >=20 >=20 >> The other RFCs that talk about the urgent pointer, 924, 944, 961 and >> 991, are all obsoleted by RFC 1011, hence only RFC 1011 needs to be >> mentioned. >=20 > Ok. Will go through the draft and try to replace references to the > aforementioned RFCs with references to RFC 1101. For most of the document I think it is fine to just reference RFC 1122, = since that was the last attempt to clarify the situation. As long as = the Updates:, Intro and the explicit "Updating RFC 1122" section mention = all 3, that should be sufficient from my viewpoint. > If you agree, I can post a rev in the next few days, so that we ship = the > I-D with all these tihngs fixes (plus the nit John Heffner has just > pointed out). That'd be great. So if anyone else has any final comments, get them in = now! -David Borman From fernando@gont.com.ar Tue Mar 2 20:29:27 2010 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 7DA1C3A7B31 for ; Tue, 2 Mar 2010 20:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 yZPKWyhC5-i6 for ; Tue, 2 Mar 2010 20:29:26 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6249E3A7904 for ; Tue, 2 Mar 2010 20:29:25 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 57DE56B678D; Wed, 3 Mar 2010 01:29:30 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o234TJYh019803; Wed, 3 Mar 2010 01:29:19 -0300 Message-ID: <4B8DE59E.50706@gont.com.ar> Date: Wed, 03 Mar 2010 01:29:18 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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]); Wed, 03 Mar 2010 01:29:29 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 03 Mar 2010 04:29:27 -0000 David Borman wrote: >> If you agree, I can post a rev in the next few days, so that we ship the >> I-D with all these tihngs fixes (plus the nit John Heffner has just >> pointed out). > > That'd be great. So if anyone else has any final comments, get them in now! Heads-up: I've posted my working copy of the I-D (the upcomming -04 version) at http://www.gont.com.ar/drafts/urgent-data/draft-ietf-tcpm-urgent-data-04.txt Please let me know if this one addresses all your comments (I think/hope it does!). 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 alexander.zimmermann@nets.rwth-aachen.de Tue Mar 2 23:50:39 2010 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 E1ABE3A8D22 for ; Tue, 2 Mar 2010 23:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[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 oUCH6eJ6x09R for ; Tue, 2 Mar 2010 23:50:38 -0800 (PST) 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 A72CB3A8C4D for ; Tue, 2 Mar 2010 23:50:38 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KYP00AGP4GEEK40@mta-2.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 03 Mar 2010 08:50:38 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,572,1262559600"; d="scan'208";a="47322254" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 03 Mar 2010 08:50:38 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KYP00C444GEQP10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 03 Mar 2010 08:50:38 +0100 (CET) From: Alexander Zimmermann In-reply-to: <4B8DE59E.50706@gont.com.ar> Date: Wed, 03 Mar 2010 08:50:37 +0100 Message-id: <75A2DC90-64EF-4929-BFFA-0800DFAB7902@nets.rwth-aachen.de> References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) Cc: "tcpm-chairs@tools.ietf.org" , David Borman , "tcpm@ietf.org WG" , "ayourtch@cisco.com" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 03 Mar 2010 07:50:40 -0000 Hi Fernando, here some nits (04 version): Sec 1, para 2: s/secifications/specifications Sec 1, para 2 s/the the/the Sec A.5. para 2: s/behaviour/behavior Alex Am 03.03.2010 um 05:29 schrieb Fernando Gont: > David Borman wrote: > >>> If you agree, I can post a rev in the next few days, so that we ship the >>> I-D with all these tihngs fixes (plus the nit John Heffner has just >>> pointed out). >> >> That'd be great. So if anyone else has any final comments, get them in now! > > Heads-up: I've posted my working copy of the I-D (the upcomming -04 > version) at > http://www.gont.com.ar/drafts/urgent-data/draft-ietf-tcpm-urgent-data-04.txt > > Please let me know if this one addresses all your comments (I think/hope > it does!). > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > 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 // From fernando@gont.com.ar Wed Mar 3 00:07:37 2010 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 30E3328C258 for ; Wed, 3 Mar 2010 00:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 A8Tl0oMCxD2c for ; Wed, 3 Mar 2010 00:07:35 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 98D0128C254 for ; Wed, 3 Mar 2010 00:07:34 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id ECD796B6800; Wed, 3 Mar 2010 05:07:34 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2387VKf009636; Wed, 3 Mar 2010 05:07:32 -0300 Message-ID: <4B8E18C5.3020103@gont.com.ar> Date: Wed, 03 Mar 2010 05:07:33 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexander Zimmermann References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> <75A2DC90-64EF-4929-BFFA-0800DFAB7902@nets.rwth-aachen.de> In-Reply-To: <75A2DC90-64EF-4929-BFFA-0800DFAB7902@nets.rwth-aachen.de> X-Enigmail-Version: 0.96.0 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]); Wed, 03 Mar 2010 05:07:34 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , David Borman , "tcpm@ietf.org WG" , "ayourtch@cisco.com" Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 03 Mar 2010 08:07:37 -0000 Hi, Alex, > here some nits (04 version): > > Sec 1, para 2: s/secifications/specifications > Sec 1, para 2 s/the the/the > Sec A.5. para 2: s/behaviour/behavior Fixed. Thanks! I really need to run the I-D through a spell-checker :-) 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 Wed Mar 3 00:44:07 2010 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 9E7263A7D92 for ; Wed, 3 Mar 2010 00:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[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 d7BTQxjKNa0E for ; Wed, 3 Mar 2010 00:44:06 -0800 (PST) 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 207B628C0EB for ; Wed, 3 Mar 2010 00:44:06 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii 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 <0KYP006JN6XHPN10@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Wed, 03 Mar 2010 09:44:05 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.49,573,1262559600"; d="scan'208";a="47331419" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Wed, 03 Mar 2010 09:44:06 +0100 Received: from miami.nets.rwth-aachen.de ([unknown] [137.226.12.180]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0KYP00CZV6XHQP10@relay-auth-2.ms.rz.rwth-aachen.de> for tcpm@ietf.org; Wed, 03 Mar 2010 09:44:05 +0100 (CET) From: Alexander Zimmermann In-reply-to: Date: Wed, 03 Mar 2010 09:44:04 +0100 Message-id: References: <88C9959E-A011-4D01-BD42-8CB2112C71A9@nets.rwth-aachen.de> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) Cc: "tcpm@ietf.org WG Extensions" , David Borman Subject: Re: [tcpm] Anaheim TCPM draft agenda available? 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, 03 Mar 2010 08:44:07 -0000 Hi Wes, hi David, I have the feeling that we may not have enough meeting-time to discuss all docs. From the meeting in SF I know that it is possible to take over slots form other WGs. AFAIK DCCP WG will not meet... Alex Am 02.03.2010 um 18:45 schrieb Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]: > Yes, currently we're working on the agenda; an initial > draft is below based on some things we knew people had > asked about presenting, which may be tentative. So, if > anyone else wants a slot, please ask David and I, and if > you're on the agenda below and want to confirm your > availability and that the timeslot is sufficient that > would be good too: > > Tuesday, March 23, 2010 1300 - 1500 > ----------------------------------- > > WG Status > chairs > 10 minutes > > TCP-LCD > Alexander Zimmerman > 5 minutes > > Middlebox Discovery > Andrew Knutsen > 25 minutes > > Reducing the Initial RTO > Jerry Chu > 25 minutes > > Increasing the Initial CWND > Jerry Chu > 25 minutes > > TCP Security Recommendations > rest of session > (tentative plan to have a "working meeting" and initially > vet a list of individual recommendations into the document) > > > -- > Wes Eddy > MTI Systems > > >> -----Original Message----- >> From: Alexander Zimmermann [mailto:alexander.zimmermann@nets.rwth- >> aachen.de] >> Sent: Wednesday, February 24, 2010 8:03 AM >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Borman >> Cc: tcpm@ietf.org WG Extensions >> Subject: Anaheim TCPM draft agenda available? >> >> Hi Wes, David, >> >> is the draft agenda for the upcoming TCPM meeting available? >> >> 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 >> // > // // 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 // From dab@weston.borman.com Wed Mar 3 06:13:28 2010 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 790F428C0F4 for ; Wed, 3 Mar 2010 06:13:28 -0800 (PST) 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 1apdqrSQibf2 for ; Wed, 3 Mar 2010 06:13:26 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 32C873A86BD for ; Wed, 3 Mar 2010 06:13:26 -0800 (PST) Received: from [172.25.44.2] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o23EDKq1006673; Wed, 3 Mar 2010 08:13:21 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4B8DE59E.50706@gont.com.ar> Date: Wed, 3 Mar 2010 08:13:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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, 03 Mar 2010 14:13:28 -0000 Ok, I did one more close reading of the spec, and I found a few more = nits: 2.1: ...that data that were received as "normal data" s/were/was/ 3.2: this clarification never was reflected into actual implementations s/never was/was never/ 4.: hereby we update RFC 793 s/hereby we/we hereby/ 6: such that "urgent data" are delivered inline s/are/is/ 7: e.g., depnding on the value s/depnding/depending/ A.4: That is, they will be accessible s/they/it/ A.6: cygwin environment, has shown that s/,// -David Borman On Mar 2, 2010, at 10:29 PM, Fernando Gont wrote: > David Borman wrote: >=20 >>> If you agree, I can post a rev in the next few days, so that we ship = the >>> I-D with all these tihngs fixes (plus the nit John Heffner has just >>> pointed out). >>=20 >> That'd be great. So if anyone else has any final comments, get them = in now! >=20 > Heads-up: I've posted my working copy of the I-D (the upcomming -04 > version) at > = http://www.gont.com.ar/drafts/urgent-data/draft-ietf-tcpm-urgent-data-04.t= xt >=20 > Please let me know if this one addresses all your comments (I = think/hope > it does!). >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Wed Mar 3 07:31:55 2010 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 89AA928C3EE for ; Wed, 3 Mar 2010 07:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 t9WNbLudRr2G for ; Wed, 3 Mar 2010 07:31:54 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4D4B128C102 for ; Wed, 3 Mar 2010 07:31:54 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23FV0Oo031415; Wed, 3 Mar 2010 09:31:53 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 17:31:50 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 17:31:50 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23FVmix009023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 17:31:48 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-56--587193205; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 3 Mar 2010 07:31:39 -0800 Message-Id: References: <88C9959E-A011-4D01-BD42-8CB2112C71A9@nets.rwth-aachen.de> To: Alexander Zimmermann X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 03 Mar 2010 17:31:42 +0200 (EET) X-OriginalArrivalTime: 03 Mar 2010 15:31:50.0115 (UTC) FILETIME=[A4A74330:01CABAE6] X-Nokia-AV: Clean Cc: "tcpm@ietf.org WG Extensions" , David Borman Subject: Re: [tcpm] Anaheim TCPM draft agenda available? 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, 03 Mar 2010 15:31:55 -0000 --Apple-Mail-56--587193205 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-3-3, at 0:44, Alexander Zimmermann wrote: > I have the feeling that we may not have enough meeting-time to > discuss all docs. =46rom the meeting in SF I know that it is possible > to take over slots form other WGs. AFAIK DCCP WG will not meet... DCCP will not meet, but they also did not request a slot this time. (In = SF, they did, and decided during the week not to meet.) Lars= --Apple-Mail-56--587193205 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDMwMzE1MzEzOVowIwYJKoZIhvcNAQkEMRYEFDJM025Qk0Dj+heucpKCHfVTEsw+MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDj+YwGORZwqMhS7SHQYNsTwbzXq3OzQp7wqW34jSCSABJ2oQfmGmPQMRhPpB/ex0S3f6Hq sYV++jS2TsDzmnYj179S0AhCFgC6dhD/pK23Es5g8GGVBq7/B8dLLkM/Uijpyquw15zkFAl5EVMp ayVq8JBc41+DMZvzVeCUJk2dWWY8phSLsscNNGkhPVoaR+2dZm5FCjBsvhRD4ovdZ5apTWxqnygz /glkmUEKuzDkKfATFBSQiE/zmCu6t5vBdIM5nd4XKcjis2uxAOPxOFAC6etMGLI/qc3UQaRih9HI tEgad4rj9o21kQPOU+h1BBvtpPTc4VkB58vyy6YSxR7OAAAAAAAA --Apple-Mail-56--587193205-- From fernando@gont.com.ar Wed Mar 3 18:03:57 2010 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 1707B28C4DB for ; Wed, 3 Mar 2010 18:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 YpWrWHgE8jGJ for ; Wed, 3 Mar 2010 18:03:55 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 6785928C4DC for ; Wed, 3 Mar 2010 18:03:54 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 079266B68CD; Wed, 3 Mar 2010 23:04:01 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2423sKb011771; Wed, 3 Mar 2010 23:03:54 -0300 Message-ID: <4B8F050C.9070003@gont.com.ar> Date: Wed, 03 Mar 2010 21:55:40 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <4B7F2881.7000700@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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]); Wed, 03 Mar 2010 23:04:00 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 04 Mar 2010 02:03:57 -0000 Hi, Wes, *Some* comments inline.... > There was mailing list discussion, and seemingly agreement, on Toby's > suggestion changing the title to reflect the focus on implementation > practices, but the title is not changed. Yes. Thanks for catching this one! (Do not recall what we had converged to, but will dig the archive... ) > There is a sentence that can simply be removed without any loss: "For > some reason, much of the effort of the security community on the > Internet protocols did not result in official documents (RFCs) being > issued by the IETF (Internet Engineering Task Force)." This doesn't > consider the fact that protocol specifications in the IETF and many (if > not most) other SDOs are focused on producing interoperable > specifications with implementation detail left to individual vendors to > differentiate their products. In the case of many of these TCP > vulnerabilities under discussion, many clearly fall into the realm of > implementation issues rather than protocol issues, and are thus outside > the traditional scope of IETF process. But virtually all the other ones have not been addressed in RFCs, either. For instance, RFC 1948 was probably one of the first and only RFCs on TCP security issues (Other than your informational RFC on syn flooding, Joe's RFC on in-window attacks, tcp-secure, and the icmp-attacks i-d...) -- and it was an *Informational* I-D. > I believe section 1.2 can be entirely eliminated without any loss. I > believe we will cover quite a bit more than just the documents listed in > this section anyways. As the author of the I-D, I'd say that section is probably the most unfair of all :-)O (see the "References" section, and *that* will give an idea of what I had to read to write the I-D). But I do believe it is valuable to list the specs that were formally assessed (although I'm sure some are missing in the list). What do others think about this? > In section 3, an implementation requirement seems to be laid out with a > mix of informal and standards language (it initially uses "should" > instead of MUST, SHOULD, MAY, etc, yet later uses a MUST) and it's not > included in the requirements section like the 3.1.1 recommendations are: > """ > Therefore, before doing any processing of the TCP header fields, the > following check should be performed by TCP on the segments handed by > the internet layer: > > Segment.Size >= 20 > If a segment does not pass this check, it MUST be dropped. > """ Yes, I'll fix this in the next rev (change it to the REQUIREMENTS/DISCUSSION format). > Further, I believe that if this document is to contain dozens of > recommendations, then these should be better identified and individually > numbered rather than mixed with prose. > > In 3.1.1, I think the requirements should be individually numbered > (maybe as R.1a, R.1b, etc. in this section?) so that they can be > referenced individually and used in checklists or compliance matrices. I have no problem with numbering each requirement. That said, what naming scheme are you thinking of? Flat, or what? > Regarding the requirement: > """ > If a segment is received with port 0 as > the Source Port or the Destination Port, a RST segment SHOULD be sent > in response (provided that the incomming segment does not have the > RST flag set). > """ > The rationale indicates that this is to mitigate against OS > fingerprinting, Actually, it's almost impossible to use port 0 reliably (many middle-boxes already filter it, and many end-hosts do not allow its use). So *that* is the reason for not using it. > but no discussion motivates this particular response > rather than other alternatives e.g. simply ignoring the segment, sending > an ICMP port-unreachable, etc. If there is a specific reason that this > response is the one chosen to make all implementations look the same to > a fingerprinting attempt, then we need to explain that, Agreed. The rationale for that response was "responsiveness" -- i.e., rather than letting the connection-establishment time-out, you send an RST. But please let me give this one another thought.... > Regarding the requirement: > """ > Middle-boxes such as packet filters MUST NOT assume that clients use > port numbers from only the Dynamic or Registered port ranges. > """ > It's not clear to me how this improves security. Disclaimer: I must say I wasn't sure about including this one as a "requirement" (as this req does not aim at end-systems). That said, while this does not improve the security of end-systems, it provides advice on how to set policies correctly, so that communication is not blocked mistakenly. (i.e., a middle-box must not assume that clients only use port numbers in that range as the source port). > recommendation, I think, which could easily be done in a set of lists in > an appendix if the recommendations were numbered, or could be satisfied > by using an outline organized by the things you're trying to protect. Such an appendix is already in the TODO list. It will be built as we vet the recommendations. 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 Wed Mar 3 18:25:14 2010 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 9D5FE28C4F4 for ; Wed, 3 Mar 2010 18:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 X37smuiqQgaz for ; Wed, 3 Mar 2010 18:25:13 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 7DA5228C4C2 for ; Wed, 3 Mar 2010 18:25:12 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3F9C36B6818; Wed, 3 Mar 2010 23:25:19 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o242P8J3017036; Wed, 3 Mar 2010 23:25:09 -0300 Message-ID: <4B8F1A05.90908@gont.com.ar> Date: Wed, 03 Mar 2010 23:25:09 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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]); Wed, 03 Mar 2010 23:25:16 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Thu, 04 Mar 2010 02:25:14 -0000 Hi, David, > Ok, I did one more close reading of the spec, and I found a few more nits: > > 2.1: ...that data that were received as "normal data" > s/were/was/ (disclaimer: English as second language here) Isn't "data" plural here? Checking my dictionary, while "data" is plural of "datum", it is nowadays used as a singular noun, too. If I were to s/were/was/, it looks like I should rephrase the text as 'that a data byte that was received as "normal data"...'... > 3.2: this clarification never was reflected into actual implementations > s/never was/was never/ Fixed. > 4.: hereby we update RFC 793 > s/hereby we/we hereby/ Fixed. > 6: such that "urgent data" are delivered inline > s/are/is/ Same as above. :-? > 7: e.g., depnding on the value > s/depnding/depending/ Fixed. > > A.4: That is, they will be accessible > s/they/it/ This one has to do with my use of "data" as plural (i.e., "data bytes") > A.6: cygwin environment, has shown that > s/,// Fixed. 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 root@core3.amsl.com Wed Mar 3 19:00:03 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AC9F828C4E4; Wed, 3 Mar 2010 19:00:03 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100304030003.AC9F828C4E4@core3.amsl.com> Date: Wed, 3 Mar 2010 19:00:03 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-04.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: Thu, 04 Mar 2010 03:00:03 -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 : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-04.txt Pages : 13 Date : 2010-03-03 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-04.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-urgent-data-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-03185322.I-D@ietf.org> --NextPart-- From fernando@gont.com.ar Wed Mar 3 19:17:41 2010 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 5515C3A7655 for ; Wed, 3 Mar 2010 19:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=-0.552, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 jLReP9UAcueM for ; Wed, 3 Mar 2010 19:17:40 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id CFCC528C0CF for ; Wed, 3 Mar 2010 19:17:38 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7466A6B6ACB for ; Thu, 4 Mar 2010 00:17:45 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o243HbrE013545; Thu, 4 Mar 2010 00:17:38 -0300 Message-ID: <4B8F2652.1010300@gont.com.ar> Date: Thu, 04 Mar 2010 00:17:38 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: tcpm@ietf.org References: <20100304030003.AC9F828C4E4@core3.amsl.com> In-Reply-To: <20100304030003.AC9F828C4E4@core3.amsl.com> X-Enigmail-Version: 0.96.0 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, 04 Mar 2010 00:17:44 -0300 (ART) Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-04.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: Thu, 04 Mar 2010 03:17:41 -0000 Hi, all, I've posted a rev of the urgent-data I-D, with all the suggesdted changes (modulo the data/datum one, that just wanted to double-check with David (and that there's still plenty of time to fix, if needed)). Thanks! Kind regards, Fernando Internet-Drafts@ietf.org wrote: > 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 : On the implementation of the TCP urgent mechanism > Author(s) : F. Gont, A. Yourtchenko > Filename : draft-ietf-tcpm-urgent-data-04.txt > Pages : 13 > Date : 2010-03-03 > > This document analyzes how current TCP implementations process TCP > urgent indications, and how the behavior of some widely-deployed > middle-boxes affect how urgent indications are processed by end > systems. This document updates the relevant specifications such that > they accommodate current practice in processing TCP urgent > indications, provides advice to applications that make use of the > urgent mechanism, and raises awareness about the reliability of TCP > urgent indications in the current Internet. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-04.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gc355804@ohio.edu Wed Mar 3 21:32:45 2010 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 9EDD328C224 for ; Wed, 3 Mar 2010 21:32:45 -0800 (PST) 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 AO8Zk2vtXPEV for ; Wed, 3 Mar 2010 21:32:42 -0800 (PST) Received: from mx4.oit.ohio.edu (mx4.oit.ohio.edu [132.235.250.54]) by core3.amsl.com (Postfix) with ESMTP id 8946428C21E for ; Wed, 3 Mar 2010 21:32:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGLUjkuE6wiY/2dsb2JhbACcBqh0DoR3iFqCXYIfBIMX X-IronPort-AV: E=Sophos;i="4.49,579,1262581200"; d="scan'208";a="31643636" Received: from lb-780.oit.ohio.edu (HELO webmail.ohio.edu) ([132.235.8.152]) by smtpout4.oit.ohio.edu with ESMTP; 04 Mar 2010 00:32:41 -0500 Received: from webmail03.app.private (localhost.localdomain [127.0.0.1]) by webmail.ohio.edu (8.13.1/8.13.1) with ESMTP id o245WfUo012125; Thu, 4 Mar 2010 00:32:41 -0500 Received: (from nobody@localhost) by webmail03.app.private (8.13.1/8.13.1/Submit) id o245WbF7012111; Thu, 4 Mar 2010 00:32:37 -0500 X-Authentication-Warning: webmail03.app.private: nobody set sender to gc355804@ohio.edu using -f To: Fernando Gont Date: Thu, 04 Mar 2010 00:32:37 -0500 From: gc355804@ohio.edu Message-ID: <1267680757.4b8f45f5be781@login.webmail.ohio.edu> References: <20100304030003.AC9F828C4E4@core3.amsl.com> <4B8F2652.1010300@gont.com.ar> In-Reply-To: <4B8F2652.1010300@gont.com.ar> X-Mailer: Webmail v1.1.10-1.1.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Originating-IP: 24.208.182.226 Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-04.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: Thu, 04 Mar 2010 05:32:46 -0000 Question re: section 6 of this document -- would it be better to remove some of the emphasis from SO_OOBINLINE and put it on the "urgent data" part? For example: Even though applications SHOULD NOT employ the urgent mechanism, applications which still decide to do so MUST ensure that all "urgent data" is delivered inline (e.g. set the SO_OOBINLINE socket option on platforms that support it), as intended by the IETF specifications. The above text also probably also makes the suggestion there a bit stronger, for better or worse. Best, Gilbert Clark Grad Student Quoting Fernando Gont : > Hi, all, > > I've posted a rev of the urgent-data I-D, with all the suggesdted > changes (modulo the data/datum one, that just wanted to double-check > with David (and that there's still plenty of time to fix, if > needed)). > > Thanks! > > Kind regards, > Fernando > > > > > Internet-Drafts@ietf.org wrote: > > 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 : On the implementation of the TCP urgent > mechanism > > Author(s) : F. Gont, A. Yourtchenko > > Filename : draft-ietf-tcpm-urgent-data-04.txt > > Pages : 13 > > Date : 2010-03-03 > > > > This document analyzes how current TCP implementations process TCP > > urgent indications, and how the behavior of some widely-deployed > > middle-boxes affect how urgent indications are processed by end > > systems. This document updates the relevant specifications such > that > > they accommodate current practice in processing TCP urgent > > indications, provides advice to applications that make use of the > > urgent mechanism, and raises awareness about the reliability of > TCP > > urgent indications in the current Internet. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-04.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. > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From dab@weston.borman.com Thu Mar 4 07:44:18 2010 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 02D7F28C1A3 for ; Thu, 4 Mar 2010 07:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shQVrVI29AhH for ; Thu, 4 Mar 2010 07:44:17 -0800 (PST) Received: from frantic.weston.borman.com (frantic-dmz.weston.borman.com [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id A908528C1C1 for ; Thu, 4 Mar 2010 07:44:11 -0800 (PST) Received: from [172.25.44.2] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id o24Fi2q1011644; Thu, 4 Mar 2010 09:44:03 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4B8F1A05.90908@gont.com.ar> Date: Thu, 4 Mar 2010 09:44:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <48EE1847-6702-4F62-B526-055AF977C36C@weston.borman.com> References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> <4B8F1A05.90908@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Thu, 04 Mar 2010 15:44:18 -0000 Fernando, On Mar 3, 2010, at 8:25 PM, Fernando Gont wrote: > Hi, David, >=20 >> Ok, I did one more close reading of the spec, and I found a few more = nits: >>=20 >> 2.1: ...that data that were received as "normal data" >> s/were/was/ And two lines later: before those data are consumed s/those data are/that data is/ >=20 > (disclaimer: English as second language here) >=20 > Isn't "data" plural here? >=20 > Checking my dictionary, while "data" is plural of "datum", it is > nowadays used as a singular noun, too. >=20 > If I were to s/were/was/, it looks like I should rephrase the text as > 'that a data byte that was received as "normal data"...'... The word "data" can be used with either a single or plural verb, it = depends on the context. If it is being used as the plural of multiple = discrete pieces of datum, then a plural verb is correct. But it can = also be used in a singular sense, when it is being used to refer to the = entire collection of data. While there may be multiple pieces of datum = within the collection, the collection as a whole is still singular. If there are 12 cookies for sale, individually wrapped, you would = say: There are a dozen cookies for sale. But if they are being sold in a single package, you would say: There is a dozen cookies for sale. Similarly in this case, it seems to me that it is referring to a single = collection of data, not a bunch of individual datum, and that is why I = suggested changing it to singular. Using the singular form also = reenforces the fact there is only one urgent pointer at any given time, = and all the unread data prior to that pointer is urgent data. If a new = urgent pointer is received, you don't now have two groups of urgent = data, it is all grouped together into a single set of urgent data. A simple test would be to read the sentence substituting either = "collection of data" or "pieces of data" in place of "data", and see = which seems to make better sense, and that would indicate whether the = verb should be singular or plural. I think I've adequately explained my reasoning, so now you can choose = which way to word it. I'll be fine with whatever you choose. >=20 >> 3.2: this clarification never was reflected into actual = implementations >> s/never was/was never/ >=20 > Fixed. >=20 >=20 >=20 >> 4.: hereby we update RFC 793 >> s/hereby we/we hereby/ >=20 > Fixed. >=20 >=20 >=20 >> 6: such that "urgent data" are delivered inline >> s/are/is/ >=20 > Same as above. :-? yes. >=20 >=20 >=20 >> 7: e.g., depnding on the value >> s/depnding/depending/ >=20 > Fixed. >=20 >=20 >>=20 >> A.4: That is, they will be accessible >> s/they/it/ >=20 > This one has to do with my use of "data" as plural (i.e., "data = bytes") Both sections A.1 and A.2 have similar wording, and use the singular = sense: "That is, it will be" I missed in Section A.3 where it also has "That is, they will be = accessible". It should be consistent in all 4 sections. -David Borman >=20 >=20 >=20 >> A.6: cygwin environment, has shown that >> s/,// >=20 > Fixed. >=20 > Thanks! >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 From fernando@gont.com.ar Thu Mar 4 21:37:51 2010 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 10C623A8EBD for ; Thu, 4 Mar 2010 21:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_46=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 uKKWJDSDyeDt for ; Thu, 4 Mar 2010 21:37:50 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id BCA923A8EBC for ; Thu, 4 Mar 2010 21:37:48 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C21A56B6B18; Fri, 5 Mar 2010 02:37:55 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o255bijh031570; Fri, 5 Mar 2010 02:37:47 -0300 Message-ID: <4B9098A8.4050501@gont.com.ar> Date: Fri, 05 Mar 2010 02:37:44 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Borman References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com> <4B8D8AAF.50402@gont.com.ar> <4B8DE59E.50706@gont.com.ar> <4B8F1A05.90908@gont.com.ar> <48EE1847-6702-4F62-B526-055AF977C36C@weston.borman.com> In-Reply-To: <48EE1847-6702-4F62-B526-055AF977C36C@weston.borman.com> X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 02:37:55 -0300 (ART) Cc: tcpm-chairs@tools.ietf.org, "tcpm@ietf.org WG" , ayourtch@cisco.com Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Fri, 05 Mar 2010 05:37:51 -0000 Hello, David, >> If I were to s/were/was/, it looks like I should rephrase the text >> as 'that a data byte that was received as "normal data"...'... > [...] > If there are 12 cookies for sale, individually wrapped, you would > say: There are a dozen cookies for sale. But if they are being sold > in a single package, you would say: There is a dozen cookies for > sale. Got it ;-) > I think I've adequately explained my reasoning, so now you can choose > which way to word it. I'll be fine with whatever you choose. As expected, I fixed all instances of data+plural. Thanks for the English lesson... ;-) Being a second language, at times it gets tricky.... P.S.: I've posted a rev that fixes this. It should be ready to ship. 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 root@core3.amsl.com Thu Mar 4 21:45:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 701DB3A8A0B; Thu, 4 Mar 2010 21:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100305054502.701DB3A8A0B@core3.amsl.com> Date: Thu, 4 Mar 2010 21:45:02 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-urgent-data-05.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: Fri, 05 Mar 2010 05:45:03 -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 : On the implementation of the TCP urgent mechanism Author(s) : F. Gont, A. Yourtchenko Filename : draft-ietf-tcpm-urgent-data-05.txt Pages : 13 Date : 2010-03-04 This document analyzes how current TCP implementations process TCP urgent indications, and how the behavior of some widely-deployed middle-boxes affect how urgent indications are processed by end systems. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, provides advice to applications that make use of the urgent mechanism, and raises awareness about the reliability of TCP urgent indications in the current Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-urgent-data-05.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-urgent-data-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-04214019.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Fri Mar 5 07:10:38 2010 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 AC54E3A8FB9 for ; Fri, 5 Mar 2010 07:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 vnPQcWsGy9mV for ; Fri, 5 Mar 2010 07:10:33 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 1DE4B3A8FC0 for ; Fri, 5 Mar 2010 07:10:32 -0800 (PST) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 880313284CD; Fri, 5 Mar 2010 09:10:34 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o25FAY15021358; Fri, 5 Mar 2010 09:10:34 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 5 Mar 2010 09:09:45 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont Date: Fri, 5 Mar 2010 09:09:43 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Thread-Index: Acq7PvM2ce4UTMvyT0y++Jwohr9hXwBMvZ3A Message-ID: References: <4B7F2881.7000700@gont.com.ar> <4B8F050C.9070003@gont.com.ar> In-Reply-To: <4B8F050C.9070003@gont.com.ar> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-05_12:2010-02-06, 2010-03-05, 2010-03-05 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 05 Mar 2010 15:10:38 -0000 >-----Original Message----- >From: Fernando Gont [mailto:fernando@gont.com.ar] >Sent: Wednesday, March 03, 2010 7:56 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > > ... > >I have no problem with numbering each requirement. > >That said, what naming scheme are you thinking of? Flat, or what? > It doesn't really matter to my; my only concern was that they each have a unique identifier to reference against more easily than using the full sentence. In order to not cause massive renumberings when adding or removing, one system would be to name them something like "R.0302001" for the first requirement in section 3.2 and "R.1100012" for the twelfth one in section 11 (with no subsections). There may be a more elegant way, I don't really care what the ID looks like as long as there is one :). If it's too much trouble or nobody else in the WG cares, I don't think it's absolutely necessary, I just would find it really helpful in my work. >> Regarding the requirement: >> """ >> If a segment is received with port 0 as >> the Source Port or the Destination Port, a RST segment SHOULD be >sent >> in response (provided that the incomming segment does not have the >> RST flag set). >> """ >> The rationale indicates that this is to mitigate against OS >> fingerprinting, > >Actually, it's almost impossible to use port 0 reliably (many >middle-boxes already filter it, and many end-hosts do not allow its >use). So *that* is the reason for not using it. > >> but no discussion motivates this particular response >> rather than other alternatives e.g. simply ignoring the segment, >sending >> an ICMP port-unreachable, etc. If there is a specific reason that >this >> response is the one chosen to make all implementations look the same >to >> a fingerprinting attempt, then we need to explain that, > >Agreed. The rationale for that response was "responsiveness" -- i.e., >rather than letting the connection-establishment time-out, you send an >RST. > >But please let me give this one another thought.... I agree that the port can't and shouldn't be used, but if we're starting with the assumption that it's never legitimately used, then why would we worry about making a timely response to incoming packets on that port? I think it's easier to just ignore them. It's like sending responses to spam otherwise. > > >> Regarding the requirement: >> """ >> Middle-boxes such as packet filters MUST NOT assume that clients >use >> port numbers from only the Dynamic or Registered port ranges. >> """ >> It's not clear to me how this improves security. > >Disclaimer: I must say I wasn't sure about including this one as a >"requirement" (as this req does not aim at end-systems). > >That said, while this does not improve the security of end-systems, it >provides advice on how to set policies correctly, so that communication >is not blocked mistakenly. (i.e., a middle-box must not assume that >clients only use port numbers in that range as the source port). Ok; but implementing this requirement doesn't at all improve the security of TCP implementations, so I believe it's out of scope. It seems like something that would be included in BEHAVE's work (and maybe it already is?), but I've not been active in that so I could be wrong. -- Wes Eddy MTI Systems From fernando@gont.com.ar Fri Mar 5 08:33:50 2010 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 15F163A8965 for ; Fri, 5 Mar 2010 08:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 H7s7bKhUClRG for ; Fri, 5 Mar 2010 08:33:49 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 80E383A8B31 for ; Fri, 5 Mar 2010 08:33:47 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DA65B6B6C17; Fri, 5 Mar 2010 13:33:50 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o25GXYLe012800; Fri, 5 Mar 2010 13:33:45 -0300 Message-ID: <4B913260.8060207@gont.com.ar> Date: Fri, 05 Mar 2010 13:33:36 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <4B7F2881.7000700@gont.com.ar> <4B8F050C.9070003@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 13:33:50 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security 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, 05 Mar 2010 16:33:50 -0000 Hi, Wes, > It doesn't really matter to my; my only concern was > that they each have a unique identifier to reference > against more easily than using the full sentence. That makes perfect sense. > In order to not cause massive renumberings when > adding or removing, one system would be to name them > something like "R.0302001" for the first requirement > in section 3.2 and "R.1100012" for the twelfth one in > section 11 (with no subsections). There may be a > more elegant way, I don't really care what the ID > looks like as long as there is one :). Ok, I'll use your proposal... unless somebody can quickly come up with something that is clearly better (I can't). FWIW, the behave folks use "REQ-n"... however, their documents usually have no more than a dozen requirements... and thus such a "flat" naming scheme is managable. In our case, we'll probably end-up with more than a hundred requirements, so such a "flat" scheme would not work that well here. A more hierarchical one such as the one you describe would work better. > If it's too much trouble or nobody else in the WG > cares, I don't think it's absolutely necessary, I > just would find it really helpful in my work. It's not too much trouble (I can add the "numbers" in an incremental way... as I edit the I-D)... and it is clearly useful. So I will be adding the req-numbers in the next rev. (Worst case, if people don't like it, we could eventually remove the numbers (I guess the only argument against it is that things like "R.XXXXXX" look like cryptic, but that's it :-) )). >>> a fingerprinting attempt, then we need to explain that, >> Agreed. The rationale for that response was "responsiveness" -- i.e., >> rather than letting the connection-establishment time-out, you send an >> RST. >> >> But please let me give this one another thought.... > > I agree that the port can't and shouldn't be used, > but if we're starting with the assumption that it's > never legitimately used, then why would we worry > about making a timely response to incoming packets > on that port? I think it's easier to just ignore > them. It's like sending responses to spam otherwise. Makes sense to me. (I guess at the time I decided that an RST might make sense as it would signal a "hard error" condition... but in retrospective, I agree with what you say. For instance, some systems already do this (ignore TCP segments that use port 0)). >>> Regarding the requirement: >>> """ >>> Middle-boxes such as packet filters MUST NOT assume that clients >> use >>> port numbers from only the Dynamic or Registered port ranges. >>> """ >>> It's not clear to me how this improves security. >> Disclaimer: I must say I wasn't sure about including this one as a >> "requirement" (as this req does not aim at end-systems). >> >> That said, while this does not improve the security of end-systems, it >> provides advice on how to set policies correctly, so that communication >> is not blocked mistakenly. (i.e., a middle-box must not assume that >> clients only use port numbers in that range as the source port). > > Ok; but implementing this requirement doesn't at all > improve the security of TCP implementations, so I > believe it's out of scope. Yes, I agree. As I said before, I wasn't sure whether to include it as a req. But did so so that we'd discuss it. > It seems like something > that would be included in BEHAVE's work (and maybe > it already is?), but I've not been active in that > so I could be wrong. And maybe not even behave... this has more to do with firewalls... 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 wesley.m.eddy@nasa.gov Fri Mar 5 10:56:23 2010 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 F11213A8E26 for ; Fri, 5 Mar 2010 10:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 bU3OEoboqLj1 for ; Fri, 5 Mar 2010 10:56:23 -0800 (PST) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id 11D053A8AA0 for ; Fri, 5 Mar 2010 10:56:22 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 59BB57B3B4 for ; Fri, 5 Mar 2010 12:56:25 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o25IuEQB031012 for ; Fri, 5 Mar 2010 12:56:24 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Fri, 5 Mar 2010 12:56:17 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Fri, 5 Mar 2010 12:56:16 -0600 Thread-Topic: Auth Option obsoleting MD5 Option in IANA registry Thread-Index: Acq8lYjdqQcQOPzlROeSRAV+Jg9OQA== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-05_12:2010-02-06, 2010-03-05, 2010-03-05 signatures=0 Subject: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 18:56:24 -0000 Following IANA's review of the TCP-AO draft, it was noted that some entries in the TCP options registry have notes of being obsoleted by other options: http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml One example, is Kind=3D6, which in the "Meaning" column indicates that it's obsoleted by Kind=3D8. It's proposed that since the TCP AO document obsoletes the TCP MD5 RFC, that the option assigned to TCP AO obsolete Kind=3D19, the MD5 Signature Option, and this would be noted in the IANA registry. I think this should be easily agreed to by TCPM, since AO was created to obsolete the MD5 option, but if there are any objections to this, now is a good time to make them :). -- Wes Eddy MTI Systems From fernando@gont.com.ar Fri Mar 5 11:28:00 2010 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 0D16D3A9017 for ; Fri, 5 Mar 2010 11:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 1oDv-p68rYgC for ; Fri, 5 Mar 2010 11:27:59 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id E5A833A8E3B for ; Fri, 5 Mar 2010 11:27:57 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B2B0A6B6BB3; Fri, 5 Mar 2010 16:28:02 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o25JRthC019583; Fri, 5 Mar 2010 16:27:56 -0300 Message-ID: <4B915B3C.9060504@gont.com.ar> Date: Fri, 05 Mar 2010 16:27:56 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 16:28:02 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 19:28:00 -0000 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > I think this should be easily agreed to by TCPM, > since AO was created to obsolete the MD5 option, > but if there are any objections to this, now is a > good time to make them :). Question: this does not mean that the option will be reassigned in the short term for some other purpose, right? 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 wesley.m.eddy@nasa.gov Fri Mar 5 11:32:32 2010 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 4B2793A8E3B for ; Fri, 5 Mar 2010 11:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 efEsgxim1LEx for ; Fri, 5 Mar 2010 11:32:31 -0800 (PST) Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 213943A8E32 for ; Fri, 5 Mar 2010 11:32:27 -0800 (PST) Received: from ndjsppt05.ndc.nasa.gov (ndjsppt05.ndc.nasa.gov [198.117.1.104]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id B083C2D80BF; Fri, 5 Mar 2010 13:32:28 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt05.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o25JWTZd021537; Fri, 5 Mar 2010 13:32:29 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Fri, 5 Mar 2010 13:32:29 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: Fernando Gont Date: Fri, 5 Mar 2010 13:32:27 -0600 Thread-Topic: [tcpm] Auth Option obsoleting MD5 Option in IANA registry Thread-Index: Acq8mfigfwYlQ4BwTMW2nuM/r/iFDgAADDjQ Message-ID: References: <4B915B3C.9060504@gont.com.ar> In-Reply-To: <4B915B3C.9060504@gont.com.ar> 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-05_12:2010-02-06, 2010-03-05, 2010-03-05 signatures=0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 19:32:32 -0000 >-----Original Message----- >From: Fernando Gont [mailto:fernando@gont.com.ar] >Sent: Friday, March 05, 2010 2:28 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >Cc: tcpm@ietf.org >Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry > >Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > > > I think this should be easily agreed to by TCPM, >> since AO was created to obsolete the MD5 option, >> but if there are any objections to this, now is a >> good time to make them :). > >Question: this does not mean that the option will be reassigned in the >short term for some other purpose, right? > Correct; the proposal is simply to add a note saying that TCP MD5 has been obsoleted, not to return Kind=3D19 to the pool of unassigned values. -- Wes Eddy MTI Systems From touch@ISI.EDU Fri Mar 5 11:42:06 2010 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 D039728C33A for ; Fri, 5 Mar 2010 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 OVtcRb1mCW83 for ; Fri, 5 Mar 2010 11:42:06 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 1E0BC28C339 for ; Fri, 5 Mar 2010 11:42:06 -0800 (PST) Received: from [75.213.151.47] (47.sub-75-213-151.myvzw.com [75.213.151.47]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o25JeAqp013207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Mar 2010 11:40:13 -0800 (PST) Message-ID: <4B915E19.5080708@isi.edu> Date: Fri, 05 Mar 2010 11:40:09 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <4B915B3C.9060504@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4EF2424E26D593AA6082BFCE" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 19:42:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4EF2424E26D593AA6082BFCE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >> -----Original Message----- >> From: Fernando Gont [mailto:fernando@gont.com.ar] >> Sent: Friday, March 05, 2010 2:28 PM >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry= >> >> Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >> >>> I think this should be easily agreed to by TCPM, >>> since AO was created to obsolete the MD5 option, >>> but if there are any objections to this, now is a >>> good time to make them :). >> Question: this does not mean that the option will be reassigned in the= >> short term for some other purpose, right? >> >=20 >=20 > Correct; the proposal is simply to add a note saying > that TCP MD5 has been obsoleted, not to return Kind=3D19 > to the pool of unassigned values. Right - here's an example from the list: 6 6 Echo (obsoleted by option 8) [RFC1072] 7 6 Echo Reply (obsoleted by option 8) [RFC1072] 8 10 TSOPT - Time Stamp Option [RFC1323] The current entry is: 19 18 MD5 Signature Option [RFC2385] The proposed change would probably look like the following (compressed to fit on a single line): 19 18 MD5 Signature Option (obsoleted by option NN) [RFC2385] Joe --------------enig4EF2424E26D593AA6082BFCE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuRXhkACgkQE5f5cImnZrvEUACg0sNutS5H6yvdArzghkFR79GS r3YAn2ew3rltVp3bykLZhNA1XkbkAV57 =9plT -----END PGP SIGNATURE----- --------------enig4EF2424E26D593AA6082BFCE-- From fernando@gont.com.ar Fri Mar 5 12:41:12 2010 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 04C3828C347 for ; Fri, 5 Mar 2010 12:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 VFkwTCK9RKRF for ; Fri, 5 Mar 2010 12:41:11 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1F6EE28C345 for ; Fri, 5 Mar 2010 12:41:10 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5466B6B6622; Fri, 5 Mar 2010 17:41:15 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o25Kf6PT005463; Fri, 5 Mar 2010 17:41:10 -0300 Message-ID: <4B916C63.1050009@gont.com.ar> Date: Fri, 05 Mar 2010 17:41:07 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: <4B915B3C.9060504@gont.com.ar> In-Reply-To: X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 17:41:14 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 20:41:12 -0000 Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: >>> I think this should be easily agreed to by TCPM, >>> since AO was created to obsolete the MD5 option, >>> but if there are any objections to this, now is a >>> good time to make them :). >> Question: this does not mean that the option will be reassigned in the >> short term for some other purpose, right? > > Correct; the proposal is simply to add a note saying > that TCP MD5 has been obsoleted, not to return Kind=19 > to the pool of unassigned values. Then, +1 :-) 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 david.borman@windriver.com Fri Mar 5 13:11:17 2010 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 E236D28C35E for ; Fri, 5 Mar 2010 13:11:16 -0800 (PST) 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 TzIDpXjM2xvO for ; Fri, 5 Mar 2010 13:11:14 -0800 (PST) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id ECD7D28C173 for ; Fri, 5 Mar 2010 13:11:13 -0800 (PST) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o25LBFUR019567; Fri, 5 Mar 2010 13:11:15 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Mar 2010 13:11:15 -0800 Received: from [172.25.34.6] ([172.25.34.6]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Mar 2010 13:11:14 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: Date: Fri, 5 Mar 2010 15:11:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1D9B82BE-C0EE-4389-BCF7-59E9A61974C0@windriver.com> References: To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 05 Mar 2010 21:11:15.0279 (UTC) FILETIME=[64102DF0:01CABCA8] Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 21:11:17 -0000 This makes sense to me, so I am in support of the change. -David Borman On Mar 5, 2010, at 12:56 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE = CORP] wrote: > Following IANA's review of the TCP-AO draft, it was > noted that some entries in the TCP options registry > have notes of being obsoleted by other options: > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml > One example, is Kind=3D6, which in the "Meaning" > column indicates that it's obsoleted by Kind=3D8. >=20 > It's proposed that since the TCP AO document > obsoletes the TCP MD5 RFC, that the option assigned > to TCP AO obsolete Kind=3D19, the MD5 Signature > Option, and this would be noted in the IANA registry. >=20 > I think this should be easily agreed to by TCPM, > since AO was created to obsolete the MD5 option, > but if there are any objections to this, now is a > good time to make them :). >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Fri Mar 5 13:53:34 2010 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 8003C28C374 for ; Fri, 5 Mar 2010 13:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 J88y-DOe6rtJ for ; Fri, 5 Mar 2010 13:53:33 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8936628C368 for ; Fri, 5 Mar 2010 13:53:32 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2B0076B6773; Fri, 5 Mar 2010 18:53:38 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o25LrU6m010425; Fri, 5 Mar 2010 18:53:31 -0300 Message-ID: <4B917D5B.3060804@gont.com.ar> Date: Fri, 05 Mar 2010 18:53:31 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 18:53:37 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , Joe Touch Subject: [tcpm] IANA TCP options registry 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, 05 Mar 2010 21:53:34 -0000 (note: this post has nothing to do with the recent poll on whether the TCP MD5 option should be obsoleted) Folks, The IANA TCP options registry (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable information. e.g., you need to figure out by yourself what the "Bubba" option is (or what it is used for), and missing references (e.g., for options #20 through #23 are missing). Al this was particularly painful when working on the CPNI TCP security document. I ended up using an unofficial revised registry posted by Alfred (http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html) which is, IMO, far better than the current IANA registry. What'd be the procedure to have Alfred's registry replace the current one? (i.e., have most/all of the information there make it into the "official" IANA registry). 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 touch@ISI.EDU Fri Mar 5 14:14:04 2010 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 1FA1328C38D for ; Fri, 5 Mar 2010 14:14:04 -0800 (PST) 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 zXLJXXIFFszz for ; Fri, 5 Mar 2010 14:14:02 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id BFC5428B23E for ; Fri, 5 Mar 2010 14:14:02 -0800 (PST) Received: from [75.215.248.70] (70.sub-75-215-248.myvzw.com [75.215.248.70]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o25MCFHG024842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Mar 2010 14:12:17 -0800 (PST) Message-ID: <4B9181BE.3050908@isi.edu> Date: Fri, 05 Mar 2010 14:12:14 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B917D5B.3060804@gont.com.ar> In-Reply-To: <4B917D5B.3060804@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBC6A922F05AFA2A7F03B54CA" X-MailScanner-ID: o25MCFHG024842 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 05 Mar 2010 22:14:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBC6A922F05AFA2A7F03B54CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Fernando, Fernando Gont wrote: > (note: this post has nothing to do with the recent poll on whether the > TCP MD5 option should be obsoleted) >=20 > Folks, >=20 > The IANA TCP options registry > (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable > information. e.g., you need to figure out by yourself what the "Bubba" > option is (or what it is used for), and missing references (e.g., for > options #20 through #23 are missing). Some of that information might be solicited found elsewhere, e.g., internet-history@postel.org ;-) > Al this was particularly painful when working on the CPNI TCP security > document. I ended up using an unofficial revised registry posted by > Alfred (http://www.ietf.org/mail-archive/web/tcpm/current/msg03199.html= ) > which is, IMO, far better than the current IANA registry. >=20 > What'd be the procedure to have Alfred's registry replace the current > one? (i.e., have most/all of the information there make it into the > "official" IANA registry). Ask IANA (iana@iana.org). I don't think this really requires any particular policy stuff - some of that info isn't there because it just wasn't known when the page was created. Joe --------------enigBC6A922F05AFA2A7F03B54CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuRgb4ACgkQE5f5cImnZrsqeQCglh8uObd5iPAH94dwdCBd/V2J +boAnAt/BAKKKijk0bzCQFbvm7ggdnUC =JhrS -----END PGP SIGNATURE----- --------------enigBC6A922F05AFA2A7F03B54CA-- From ananth@cisco.com Fri Mar 5 14:24:33 2010 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 D73B928C396 for ; Fri, 5 Mar 2010 14:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZhoE8QKol9aM for ; Fri, 5 Mar 2010 14:24:32 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CD00928C133 for ; Fri, 5 Mar 2010 14:24:32 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANcSkUurRN+J/2dsb2JhbACbSXOeEJhlgkOCNASDFw X-IronPort-AV: E=Sophos;i="4.49,589,1262563200"; d="scan'208";a="244584654" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 05 Mar 2010 22:24:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o25MOZil024382; Fri, 5 Mar 2010 22:24:35 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 14:24:35 -0800 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: Fri, 5 Mar 2010 14:24:35 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5809097FA7@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Auth Option obsoleting MD5 Option in IANA registry Thread-Index: Acq8lYjdqQcQOPzlROeSRAV+Jg9OQAAAVTHw References: From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , X-OriginalArrivalTime: 05 Mar 2010 22:24:35.0554 (UTC) FILETIME=[A2D4DC20:01CABCB2] Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 22:24:34 -0000 I was the one who probably raised this issue earlier and the meaning of the term "obseletes" and we had use that for a lack of a better term. TCP-MD5 will continue to exist and we will have to support it as long as it exists. That said my real question is : What is the purpose of IANA noting that this "kind" is obsolete? They cannot allocate to another option, is it pure book keeping activity? -Anantha > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Sent: Friday, March 05, 2010 10:56 AM > To: tcpm@ietf.org > Subject: [tcpm] Auth Option obsoleting MD5 Option in IANA registry >=20 > Following IANA's review of the TCP-AO draft, it was noted=20 > that some entries in the TCP options registry have notes of=20 > being obsoleted by other options: > http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml > One example, is Kind=3D6, which in the "Meaning" > column indicates that it's obsoleted by Kind=3D8. >=20 > It's proposed that since the TCP AO document obsoletes the=20 > TCP MD5 RFC, that the option assigned to TCP AO obsolete=20 > Kind=3D19, the MD5 Signature Option, and this would be noted in=20 > the IANA registry. >=20 > I think this should be easily agreed to by TCPM, since AO was=20 > created to obsolete the MD5 option, but if there are any=20 > objections to this, now is a good time to make them :). >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From touch@ISI.EDU Fri Mar 5 14:37:17 2010 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 2E21628C3BF for ; Fri, 5 Mar 2010 14:37:17 -0800 (PST) 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 TwlVoVdvkYcz for ; Fri, 5 Mar 2010 14:37:15 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C1C5828C133 for ; Fri, 5 Mar 2010 14:37:15 -0800 (PST) Received: from [75.215.248.70] (70.sub-75-215-248.myvzw.com [75.215.248.70]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o25MapD9001870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Mar 2010 14:36:53 -0800 (PST) Message-ID: <4B918783.3020002@isi.edu> Date: Fri, 05 Mar 2010 14:36:51 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <0C53DCFB700D144284A584F54711EC5809097FA7@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809097FA7@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA984A3E531478501D998F4C7" X-MailScanner-ID: o25MapD9001870 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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, 05 Mar 2010 22:37:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA984A3E531478501D998F4C7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Anantha, This is bookkeeping. It doesn't change anything - it just reflects the status of the AO doc as "obsoleting" 2385. Joe Anantha Ramaiah (ananth) wrote: >=20 > I was the one who probably raised this issue earlier and the meaning of= > the term "obseletes" and we had use that for a lack of a better term. > TCP-MD5 will continue to exist and we will have to support it as long a= s > it exists. >=20 > That said my real question is : What is the purpose of IANA noting that= > this "kind" is obsolete? They cannot allocate to another option, is it > pure book keeping activity? >=20 > -Anantha >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Sent: Friday, March 05, 2010 10:56 AM >> To: tcpm@ietf.org >> Subject: [tcpm] Auth Option obsoleting MD5 Option in IANA registry >> >> Following IANA's review of the TCP-AO draft, it was noted=20 >> that some entries in the TCP options registry have notes of=20 >> being obsoleted by other options: >> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml >> One example, is Kind=3D6, which in the "Meaning" >> column indicates that it's obsoleted by Kind=3D8. >> >> It's proposed that since the TCP AO document obsoletes the=20 >> TCP MD5 RFC, that the option assigned to TCP AO obsolete=20 >> Kind=3D19, the MD5 Signature Option, and this would be noted in=20 >> the IANA registry. >> >> I think this should be easily agreed to by TCPM, since AO was=20 >> created to obsolete the MD5 option, but if there are any=20 >> objections to this, now is a good time to make them :). >> >> -- >> Wes Eddy >> MTI Systems >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enigA984A3E531478501D998F4C7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuRh4MACgkQE5f5cImnZrszIQCgvcL4ZoXFb/522xDQ4F/mzoEC Tq8AnR8n9Lc4wuYY9PaDW9V6zjAEA18z =cNYO -----END PGP SIGNATURE----- --------------enigA984A3E531478501D998F4C7-- From fernando@gont.com.ar Fri Mar 5 14:51:35 2010 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 7D18428C3B8 for ; Fri, 5 Mar 2010 14:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 rZEG9k-ArGFB for ; Fri, 5 Mar 2010 14:51:33 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A07DE28C16E for ; Fri, 5 Mar 2010 14:51:32 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D1B086B6865; Fri, 5 Mar 2010 19:51:38 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o25MpRmD008215; Fri, 5 Mar 2010 19:51:29 -0300 Message-ID: <4B918AF0.5090605@gont.com.ar> Date: Fri, 05 Mar 2010 19:51:28 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B917D5B.3060804@gont.com.ar> <4B9181BE.3050908@isi.edu> In-Reply-To: <4B9181BE.3050908@isi.edu> X-Enigmail-Version: 0.96.0 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, 05 Mar 2010 19:51:37 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 05 Mar 2010 22:51:35 -0000 Hi, Joe, >> The IANA TCP options registry >> (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable >> information. e.g., you need to figure out by yourself what the "Bubba" >> option is (or what it is used for), and missing references (e.g., for >> options #20 through #23 are missing). > > Some of that information might be solicited found elsewhere, e.g., > internet-history@postel.org ;-) Yes, but other than that, one should be able to know if the option was ever deployed, whether it's obsolete, etc. e.g., if I wanted to design a firewall policy, I might need that information. >> What'd be the procedure to have Alfred's registry replace the current >> one? (i.e., have most/all of the information there make it into the >> "official" IANA registry). > > Ask IANA (iana@iana.org). I don't think this really requires any > particular policy stuff - some of that info isn't there because it just > wasn't known when the page was created. Ok. I've just e-mailed them. Let's see what happens. 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 huitema@microsoft.com Fri Mar 5 17:12:09 2010 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 0E6C93A7870 for ; Fri, 5 Mar 2010 17:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PqrqivvyzbKN for ; Fri, 5 Mar 2010 17:12:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 76DFC3A905B for ; Fri, 5 Mar 2010 17:12:04 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Mar 2010 17:12:07 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 5 Mar 2010 17:11:48 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.84]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 5 Mar 2010 17:11:49 -0800 From: Christian Huitema To: Fernando Gont , Joe Touch Thread-Topic: [tcpm] IANA TCP options registry Thread-Index: AQHKvK5fOZjK3jmy1kaQ625kwWKmnJHkbpEAgAAK9gD//5/3EA== Date: Sat, 6 Mar 2010 01:11:46 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA685E80A4@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <4B917D5B.3060804@gont.com.ar> <4B9181BE.3050908@isi.edu> <4B918AF0.5090605@gont.com.ar> In-Reply-To: <4B918AF0.5090605@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm-chairs@tools.ietf.org" , =?iso-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 01:12:09 -0000 The bubba and skeeter options were reserved by Stev Knowles, then working a= t FTP Software. The options are parts of an encryption system. The document= ation for that system was not made publicly available. According to Stev, t= he options were actually deployed and used, certainly until 2000, and possi= bly later.=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Fer= nando Gont Sent: Friday, March 05, 2010 2:51 PM To: Joe Touch Cc: tcpm-chairs@tools.ietf.org; Alfred H=F6nes; tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry Hi, Joe, >> The IANA TCP options registry >> (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable >> information. e.g., you need to figure out by yourself what the "Bubba" >> option is (or what it is used for), and missing references (e.g., for >> options #20 through #23 are missing). >=20 > Some of that information might be solicited found elsewhere, e.g., > internet-history@postel.org ;-) Yes, but other than that, one should be able to know if the option was ever deployed, whether it's obsolete, etc. e.g., if I wanted to design a firewall policy, I might need that information. >> What'd be the procedure to have Alfred's registry replace the current >> one? (i.e., have most/all of the information there make it into the >> "official" IANA registry). >=20 > Ask IANA (iana@iana.org). I don't think this really requires any > particular policy stuff - some of that info isn't there because it just > wasn't known when the page was created. Ok. I've just e-mailed them. Let's see what happens. Thanks! Kind regards, --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From lars.eggert@nokia.com Sat Mar 6 02:26:27 2010 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 998743A8F39 for ; Sat, 6 Mar 2010 02:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 9OZpsJMgE0zu for ; Sat, 6 Mar 2010 02:26:26 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A5D5D3A871B for ; Sat, 6 Mar 2010 02:26:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26APPOx027038; Sat, 6 Mar 2010 04:25:27 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 12:25:24 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Mar 2010 12:25:24 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o26APLNi014365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Mar 2010 12:25:22 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-4--346376913; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B917D5B.3060804@gont.com.ar> Date: Sat, 6 Mar 2010 12:25:15 +0200 Message-Id: <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> References: <4B917D5B.3060804@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Sat, 06 Mar 2010 12:25:15 +0200 (EET) X-OriginalArrivalTime: 06 Mar 2010 10:25:24.0350 (UTC) FILETIME=[551F69E0:01CABD17] X-Nokia-AV: Clean Cc: "tcpm-chairs@tools.ietf.org" , =?iso-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 10:26:27 -0000 --Apple-Mail-4--346376913 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-3-5, at 23:53, Fernando Gont wrote: > What'd be the procedure to have Alfred's registry replace the current > one? (i.e., have most/all of the information there make it into the > "official" IANA registry). I'd ask the WG to determine whether the information in Alfred's list is = correct (I have little doubt that it is) and then I'll add a management = item on an IESG telechat to instruct IANA to update their registry = accordingly. Lars= --Apple-Mail-4--346376913 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDMwNjEwMjUxNVowIwYJKoZIhvcNAQkEMRYEFNa5hsMobZv6iSHHW1v8TsTVT0D7MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAjtl8vW9yIx2TniVbrH0aD1NDisobeXEvyRjskZsBv2IXnjKZ8KwRhwVj8emWVYXYjDnbG IF4wzu1ev30fA03E2FxaDe0wBeKJ/1vhm0OxJD2vaJqtzvitfK78HcXNi3Ti5+4PswPBBYo5inSm YeYK/I2Y8LS0cSXMKJJWeACSGGY7wtzkM+r+KnHA3YiXF1UFco/BUgJHs4fI1glq8QybDQ7m3ctV XKnjYWFjgZyVnZ/w53YZDfsBMsu6H5aiUaang92mXB4Kw/TpOeNdsZLj5SCFbL4085Y3xkQfLahf ILzqyKy0fs1Nj5RnL0rzoe8y0fqHqsfyYzPfr+kSp9hwAAAAAAAA --Apple-Mail-4--346376913-- From touch@ISI.EDU Sat Mar 6 08:18:20 2010 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 AF82528C159 for ; Sat, 6 Mar 2010 08:18:18 -0800 (PST) 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 XdIigG6DqvLM for ; Sat, 6 Mar 2010 08:18:03 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id ED96E3A90F9 for ; Sat, 6 Mar 2010 08:18:00 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o26GHPv4004037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Mar 2010 08:17:27 -0800 (PST) Message-ID: <4B928015.2090500@isi.edu> Date: Sat, 06 Mar 2010 08:17:25 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> In-Reply-To: <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig477F7371D2CEF1F7881CFA3E" X-MailScanner-ID: o26GHPv4004037 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 16:18:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig477F7371D2CEF1F7881CFA3E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also: Some of the info in Alfred's registry may be useful in other places, but not necessarily in areas managed by IANA. IANA isn't chartered to provide detailed spec info, except as it affects registrations (e.g., system vs. user ports) - they provide pointers to other docs. Some would be useful in an informational summary doc (SYN only, etc). Other information on current use isn't clearly appropriate IMO for either a doc or IANA tables, such as active use information. IANA is typically limited to pointers to reference documentation and indications on standards status only. Putting up web pages with this "other" (IMO, non-IANA) info may be useful, but seems outside IANA's scope. I'm not sure who could maintain those pages, other than individuals on personal sites (which, given search engines, ought to be sufficient anyway). Joe Lars Eggert wrote: > On 2010-3-5, at 23:53, Fernando Gont wrote: >> What'd be the procedure to have Alfred's registry replace the current >> one? (i.e., have most/all of the information there make it into the >> "official" IANA registry). >=20 > I'd ask the WG to determine whether the information in Alfred's list is= correct (I have little doubt that it is) and then I'll add a management = item on an IESG telechat to instruct IANA to update their registry accord= ingly. >=20 > Lars --------------enig477F7371D2CEF1F7881CFA3E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuSgBUACgkQE5f5cImnZrtLUQCaA9RtMZ8FIzGweZ/7yP4cBLgE l1AAnivaiQhD0i9cHdybyaIwtHFpShyE =5Hmj -----END PGP SIGNATURE----- --------------enig477F7371D2CEF1F7881CFA3E-- From fernando@gont.com.ar Sat Mar 6 08:47:11 2010 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 458B828C16C for ; Sat, 6 Mar 2010 08:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 rq6locW7L2vf for ; Sat, 6 Mar 2010 08:47:10 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1B36928C14A for ; Sat, 6 Mar 2010 08:47:09 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D5F8C6B65BF; Sat, 6 Mar 2010 13:47:12 -0300 (ART) Received: from [192.168.0.125] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o26Gl45K020624; Sat, 6 Mar 2010 13:47:04 -0300 Message-ID: <4B92870A.2030608@gont.com.ar> Date: Sat, 06 Mar 2010 13:47:06 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> In-Reply-To: <4B928015.2090500@isi.edu> X-Enigmail-Version: 0.96.0 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]); Sat, 06 Mar 2010 13:47:11 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 16:47:11 -0000 Joe, > Some of the info in Alfred's registry may be useful in other places, but > not necessarily in areas managed by IANA. IANA isn't chartered to > provide detailed spec info, except as it affects registrations (e.g., > system vs. user ports) - they provide pointers to other docs. That's the point. What pointer does it have for, e.g., the Bubba option or for options #20 through #23? -- FWIW, I'd rather have a pointer to a spec rather than an e-mail address. In particular when the e-mail addresses may become obsolete, and when there's no guarantee that you'll get a response if you send e-mail to those e-mail addresses. > Some would be useful in an informational summary doc (SYN only, etc). Agreed. > Other information on current use isn't clearly appropriate IMO for > either a doc or IANA tables, such as active use information. I don't expect "usage" information with a granularity of one year or two years, but at least I'd be interested in "usage" information with a more coarse granularity (e.g., "was this ever deployed on the Internet?", "Is it fair to assume that nobody is using this anymore?") > Putting up web pages with this "other" (IMO, non-IANA) info may be > useful, but seems outside IANA's scope. I'm not sure who could maintain > those pages, other than individuals on personal sites (which, given > search engines, ought to be sufficient anyway). I disagree with this. Yes, there are search engines. But they don't tell you the accuracy of the information that they provide in their results. Secondly (and probably more importantly), why should we rely on some external agent to provide this information??? Why should this useful stuff need to be produced elsewhere? 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 Sat Mar 6 09:35:50 2010 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 27BD63A90F8 for ; Sat, 6 Mar 2010 09:35:50 -0800 (PST) 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 CaLMqoKvNmoA for ; Sat, 6 Mar 2010 09:35:48 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E5D2928C1BA for ; Sat, 6 Mar 2010 09:35:48 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o26HZ9kt017278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Mar 2010 09:35:10 -0800 (PST) Message-ID: <4B92924C.6090709@isi.edu> Date: Sat, 06 Mar 2010 09:35:08 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> In-Reply-To: <4B92870A.2030608@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2E1BE67BCFCF4625ADD883AF" X-MailScanner-ID: o26HZ9kt017278 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 17:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2E1BE67BCFCF4625ADD883AF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe, >=20 >> Some of the info in Alfred's registry may be useful in other places, b= ut >> not necessarily in areas managed by IANA. IANA isn't chartered to >> provide detailed spec info, except as it affects registrations (e.g., >> system vs. user ports) - they provide pointers to other docs. >=20 > That's the point. What pointer does it have for, e.g., the Bubba option= > or for options #20 through #23? -- FWIW, I'd rather have a pointer to a= > spec rather than an e-mail address. In particular when the e-mail > addresses may become obsolete, and when there's no guarantee that you'l= l > get a response if you send e-mail to those e-mail addresses. IANA tends to maintain as much registry information as they have, but only the specs or a general pointer is on the web page, AFAICT. That seems appropriate, as you note. If someone wants to contact the last known 'owner' (who registered it), they can contact IANA. >> Some would be useful in an informational summary doc (SYN only, etc). >=20 > Agreed. >=20 >> Other information on current use isn't clearly appropriate IMO for >> either a doc or IANA tables, such as active use information. >=20 > I don't expect "usage" information with a granularity of one year or tw= o > years, but at least I'd be interested in "usage" information with a mor= e > coarse granularity (e.g., "was this ever deployed on the Internet?", "I= s > it fair to assume that nobody is using this anymore?") The IETF would take this on by declaring something Historic, e.g. I don't think it's in IANA's charter to either make these assessments, and that seems like something that, while useful, isn't "IANA". >> Putting up web pages with this "other" (IMO, non-IANA) info may be >> useful, but seems outside IANA's scope. I'm not sure who could maintai= n >> those pages, other than individuals on personal sites (which, given >> search engines, ought to be sufficient anyway). >=20 > I disagree with this. Yes, there are search engines. But they don't tel= l > you the accuracy of the information that they provide in their results.= No disagreement there, but individual pages can often have as useful information as those by organizations ;-) > Secondly (and probably more importantly), why should we rely on some > external agent to provide this information??? Why should this useful > stuff need to be produced elsewhere? I agree this info is useful in general. It doesn't seem appropriate for IANA to either collect or maintain that info. I'm not even sure the IETF would do this, except in the process of standards elevation/demotion. I'm not saying it's not useful, but I just don't know who should "own" or "endorse" this - the Internet doesn't have a compliance or deployment monitoring function AFAICT. Joe --------------enig2E1BE67BCFCF4625ADD883AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuSkk0ACgkQE5f5cImnZrtmjQCg6abnTBYzlKTwe9FKjP13ch62 jWsAniVDPKbzGY0Nm2G/wBTxEc9z5DDS =7fmw -----END PGP SIGNATURE----- --------------enig2E1BE67BCFCF4625ADD883AF-- From fernando@gont.com.ar Sat Mar 6 10:15:00 2010 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 52CA63A90FC for ; Sat, 6 Mar 2010 10:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 oOzHC2Da4QBU for ; Sat, 6 Mar 2010 10:14:59 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 09EB23A8D68 for ; Sat, 6 Mar 2010 10:14:57 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9B4CE6B6634; Sat, 6 Mar 2010 15:15:02 -0300 (ART) Received: from [192.168.0.125] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o26IEtDM030638; Sat, 6 Mar 2010 15:14:56 -0300 Message-ID: <4B929BA1.7060902@gont.com.ar> Date: Sat, 06 Mar 2010 15:14:57 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> In-Reply-To: <4B92924C.6090709@isi.edu> X-Enigmail-Version: 0.96.0 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]); Sat, 06 Mar 2010 15:15:01 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 18:15:00 -0000 Joe Touch wrote: > IANA tends to maintain as much registry information as they have, but > only the specs or a general pointer is on the web page, AFAICT. That > seems appropriate, as you note. If someone wants to contact the last > known 'owner' (who registered it), they can contact IANA. Exactly. That's why, e.g. in the case of the options 20-23, it would be better to provide a pointer to the spec rather than an e-mail address (in particular when the spec is publicly available, for free). >>> Other information on current use isn't clearly appropriate IMO for >>> either a doc or IANA tables, such as active use information. >> I don't expect "usage" information with a granularity of one year or two >> years, but at least I'd be interested in "usage" information with a more >> coarse granularity (e.g., "was this ever deployed on the Internet?", "Is >> it fair to assume that nobody is using this anymore?") > > The IETF would take this on by declaring something Historic, You mean an RFC declaring those options as "Historic"? > e.g. I > don't think it's in IANA's charter to either make these assessments, and > that seems like something that, while useful, isn't "IANA". I may agree with that. However, the discussion here is two-fold: * IANA registry not providing good pointers (IMO this should be fixed by IANA, as described above) * IANA not providing hints about the usage of many options. From your comment, it seems this should be addressed by a Std. Track RFC? >>> Putting up web pages with this "other" (IMO, non-IANA) info may be >>> useful, but seems outside IANA's scope. I'm not sure who could maintain >>> those pages, other than individuals on personal sites (which, given >>> search engines, ought to be sufficient anyway). >> I disagree with this. Yes, there are search engines. But they don't tell >> you the accuracy of the information that they provide in their results. > > No disagreement there, but individual pages can often have as useful > information as those by organizations ;-) For sure. But it's not a good sign if the most useful info is always elsewhere ;-) >> Secondly (and probably more importantly), why should we rely on some >> external agent to provide this information??? Why should this useful >> stuff need to be produced elsewhere? > > I agree this info is useful in general. It doesn't seem appropriate for > IANA to either collect or maintain that info. I'm not even sure the IETF > would do this, except in the process of standards elevation/demotion. I guess that at least with Informational RFCs, it could/should do it. > I'm not saying it's not useful, but I just don't know who should "own" > or "endorse" this - the Internet doesn't have a compliance or deployment > monitoring function AFAICT. It doesn't look good to have all this options assigned that nobody (*) knows what they have been used for (if they have ever been used on the public Internet). (*) Clearly, some people probably know about them (as indicated by the recent post by Christian Huitema). But this information should be easily and publicly available. 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 Sat Mar 6 10:27:17 2010 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 C6BF03A8FFB for ; Sat, 6 Mar 2010 10:27:17 -0800 (PST) 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 zYQ2uj9k4ZWg for ; Sat, 6 Mar 2010 10:27:16 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id C53BA3A8DAC for ; Sat, 6 Mar 2010 10:27:16 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o26IQWGJ024663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Mar 2010 10:26:33 -0800 (PST) Message-ID: <4B929E58.6000007@isi.edu> Date: Sat, 06 Mar 2010 10:26:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> <4B929BA1.7060902@gont.com.ar> In-Reply-To: <4B929BA1.7060902@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9286A11D2D9DDD1E4834A660" X-MailScanner-ID: o26IQWGJ024663 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 18:27:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9286A11D2D9DDD1E4834A660 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >> IANA tends to maintain as much registry information as they have, but >> only the specs or a general pointer is on the web page, AFAICT. That >> seems appropriate, as you note. If someone wants to contact the last >> known 'owner' (who registered it), they can contact IANA. >=20 > Exactly. That's why, e.g. in the case of the options 20-23, it would be= > better to provide a pointer to the spec rather than an e-mail address > (in particular when the spec is publicly available, for free). We agree. >>>> Other information on current use isn't clearly appropriate IMO for >>>> either a doc or IANA tables, such as active use information. >>> I don't expect "usage" information with a granularity of one year or = two >>> years, but at least I'd be interested in "usage" information with a m= ore >>> coarse granularity (e.g., "was this ever deployed on the Internet?", = "Is >>> it fair to assume that nobody is using this anymore?") >> The IETF would take this on by declaring something Historic,=20 >=20 > You mean an RFC declaring those options as "Historic"? For options without RFCs, yes. For options with RFCs, we follow whatever IETF process there is (I don't recall if we need to have a new doc to declare something historic or we just make the decision and update the label - whatever the process is, we follow it). >> e.g. I >> don't think it's in IANA's charter to either make these assessments, a= nd >> that seems like something that, while useful, isn't "IANA". >=20 > I may agree with that. However, the discussion here is two-fold: >=20 > * IANA registry not providing good pointers (IMO this should be fixed b= y > IANA, as described above) Agreed. I think we can just discuss that on the list as Lars suggested, with further discussion on internet-history@postel.org as needed, and provide that info to IANA. I think IANA would appreciate that. > * IANA not providing hints about the usage of many options. From your > comment, it seems this should be addressed by a Std. Track RFC? Current usage - i.e., what's deployed, etc. - is a poll that I wouldn't see useful in either an RFC (of any kind). I also don't see that as something IANA either wants to or should maintain. IANA indicates the standards status of docs - which is driven by usage - but shouldn't be involved in maintaining current usage info. =2E.. >>> Secondly (and probably more importantly), why should we rely on some >>> external agent to provide this information??? Why should this useful >>> stuff need to be produced elsewhere? >> I agree this info is useful in general. It doesn't seem appropriate fo= r >> IANA to either collect or maintain that info. I'm not even sure the IE= TF >> would do this, except in the process of standards elevation/demotion. >=20 > I guess that at least with Informational RFCs, it could/should do it. I don't see that as even an Informational issue. It's far too ephemeral. There's no reason that in 5 or 10 years anyone will care what usage today is. Yes, a poll is useful. I have no idea who would "own" that process, or where that info would be maintained. I don't think this is an IETF issue *except* when it drives a decision to change status (to historic, e.g.). At that point, the decision is what documents the usage. >> I'm not saying it's not useful, but I just don't know who should "own"= >> or "endorse" this - the Internet doesn't have a compliance or deployme= nt >> monitoring function AFAICT. >=20 > It doesn't look good to have all this options assigned that nobody (*) > knows what they have been used for (if they have ever been used on the > public Internet). I agree that IANA can have better info that can indicate what the option is, and that's easy AFAICT (gather the info, review it in TCPM and on internet-history to get as much input as possible, and ask IANA to update - I think they'd be glad to). Whether they've ever been used in the public Internet is a different issue. We can indicate 'experimental', 'historic', etc. But even experimental or historic protocols have been used in the public Internet. I don't see an *IANA* role in using the info of 'public use' - only of the status. Use information is, AFAICT, outside the scope of both the IETF and IANA except as it changes status. Again, I agree that info is useful, but don't know where it has a home EXCEPT as part of driving status, which happens only when we make decisions, not as an ongoing monitoring process. Joe --------------enig9286A11D2D9DDD1E4834A660 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuSnlgACgkQE5f5cImnZrsvYwCdGVToXChKz/mBuZqTeW8ShYYD MwoAnRyHXa6nXy2EIJAJTHjz3TbIF9tt =Gya6 -----END PGP SIGNATURE----- --------------enig9286A11D2D9DDD1E4834A660-- From fernando@gont.com.ar Sat Mar 6 11:56:40 2010 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 5237E3A8E21 for ; Sat, 6 Mar 2010 11:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 XWtX1jEHWppv for ; Sat, 6 Mar 2010 11:56:39 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id EA71D3A8BEE for ; Sat, 6 Mar 2010 11:56:37 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7848A6B661F; Sat, 6 Mar 2010 16:56:43 -0300 (ART) Received: from [192.168.0.125] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o26JuZho008165; Sat, 6 Mar 2010 16:56:36 -0300 Message-ID: <4B92B375.5060505@gont.com.ar> Date: Sat, 06 Mar 2010 16:56:37 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> <4B929BA1.7060902@gont.com.ar> <4B929E58.6000007@isi.edu> In-Reply-To: <4B929E58.6000007@isi.edu> X-Enigmail-Version: 0.96.0 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]); Sat, 06 Mar 2010 16:56:42 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 19:56:40 -0000 Hello, Joe, >>>>> Other information on current use isn't clearly appropriate IMO for >>>>> either a doc or IANA tables, such as active use information. >>>> I don't expect "usage" information with a granularity of one year or two >>>> years, but at least I'd be interested in "usage" information with a more >>>> coarse granularity (e.g., "was this ever deployed on the Internet?", "Is >>>> it fair to assume that nobody is using this anymore?") >>> The IETF would take this on by declaring something Historic, >> You mean an RFC declaring those options as "Historic"? > > For options without RFCs, yes. For options with RFCs, we follow whatever > IETF process there is (I don't recall if we need to have a new doc to > declare something historic or we just make the decision and update the > label - whatever the process is, we follow it). *Some* things (with RFCs) have been declared Historic with RFCs (e.g., NATs). But I don't know if that's a requirement, or what would be the case for TCP options. Lars? >>> e.g. I >>> don't think it's in IANA's charter to either make these assessments, and >>> that seems like something that, while useful, isn't "IANA". >> I may agree with that. However, the discussion here is two-fold: >> >> * IANA registry not providing good pointers (IMO this should be fixed by >> IANA, as described above) > > Agreed. I think we can just discuss that on the list as Lars suggested, > with further discussion on internet-history@postel.org as needed, and > provide that info to IANA. I think IANA would appreciate that. I will try to do that. >> * IANA not providing hints about the usage of many options. From your >> comment, it seems this should be addressed by a Std. Track RFC? > > Current usage - i.e., what's deployed, etc. - is a poll that I wouldn't > see useful in either an RFC (of any kind). I also don't see that as > something IANA either wants to or should maintain. In this particular case, I guess it could be an Informational I-D, that could be updated every X years. (for some value of X) >>>> Secondly (and probably more importantly), why should we rely on some >>>> external agent to provide this information??? Why should this useful >>>> stuff need to be produced elsewhere? >>> I agree this info is useful in general. It doesn't seem appropriate for >>> IANA to either collect or maintain that info. I'm not even sure the IETF >>> would do this, except in the process of standards elevation/demotion. >> I guess that at least with Informational RFCs, it could/should do it. > > I don't see that as even an Informational issue. It's far too ephemeral. > There's no reason that in 5 or 10 years anyone will care what usage > today is. Well, at least it's usage information with a coarse granularity. Not good, but still better than nothing. > Yes, a poll is useful. I have no idea who would "own" that process, or > where that info would be maintained. Hence my suggestion of an Informational RFC that could be revised now and then. > I don't think this is an IETF issue > *except* when it drives a decision to change status (to historic, e.g.). > At that point, the decision is what documents the usage. I agree to some extent. But OTOH, lack of information may result in some options being deemed as unused/historic, and then e.g. filtered. >>> I'm not saying it's not useful, but I just don't know who should "own" >>> or "endorse" this - the Internet doesn't have a compliance or deployment >>> monitoring function AFAICT. >> It doesn't look good to have all this options assigned that nobody (*) >> knows what they have been used for (if they have ever been used on the >> public Internet). > > I agree that IANA can have better info that can indicate what the option > is, and that's easy AFAICT (gather the info, review it in TCPM and on Would they really include a description if there's not document describing the use of such options? 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 Sat Mar 6 12:10:47 2010 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 A483928C154 for ; Sat, 6 Mar 2010 12:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6LMHaELFfXI for ; Sat, 6 Mar 2010 12:10:46 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 4E1FC28C131 for ; Sat, 6 Mar 2010 12:10:46 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o26K9RJf009735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Mar 2010 12:09:28 -0800 (PST) Message-ID: <4B92B677.80508@isi.edu> Date: Sat, 06 Mar 2010 12:09:27 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> <4B929BA1.7060902@gont.com.ar> <4B929E58.6000007@isi.edu> <4B92B375.5060505@gont.com.ar> In-Reply-To: <4B92B375.5060505@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF3282FD4A71C61522CCBDB8E" X-MailScanner-ID: o26K9RJf009735 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 20:10:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF3282FD4A71C61522CCBDB8E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. >> Yes, a poll is useful. I have no idea who would "own" that process, or= >> where that info would be maintained.=20 >=20 > Hence my suggestion of an Informational RFC that could be revised now > and then. I think that writing RFCs - informational or not - that are known to be useless in a short timeframe isn't productive. The IETF is not an operations monitoring organization. However, informational docs are a path to that. We should NOT have this be a WG effort- at any level - unless it's in conjunction with a status change, I= MO. >> I don't think this is an IETF issue >> *except* when it drives a decision to change status (to historic, e.g.= ). >> At that point, the decision is what documents the usage. >=20 > I agree to some extent. But OTOH, lack of information may result in som= e > options being deemed as unused/historic, and then e.g. filtered. This info can feed into the IETF when needed, of course. But I don't see where, how, or why the IETF should perform background monitoring per se. >>>> I'm not saying it's not useful, but I just don't know who should "ow= n" >>>> or "endorse" this - the Internet doesn't have a compliance or deploy= ment >>>> monitoring function AFAICT. >>> It doesn't look good to have all this options assigned that nobody (*= ) >>> knows what they have been used for (if they have ever been used on th= e >>> public Internet). >> I agree that IANA can have better info that can indicate what the opti= on >> is, and that's easy AFAICT (gather the info, review it in TCPM and on >=20 > Would they really include a description if there's not document > describing the use of such options? A few words at best. If not, perhaps it'd be useful to try to describe these options in an informational doc they can cite. If not, it's OK to list them as experimental with no known documentation - we shouldn't allocate them that way anymore, but what's done is done. Joe --------------enigF3282FD4A71C61522CCBDB8E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuStncACgkQE5f5cImnZrssFgCdF7EpxGBuiqzS95F/nD5b2pCe 5pIAnA/X4196b8Kd8Szxyz8a4GotQyhq =xV30 -----END PGP SIGNATURE----- --------------enigF3282FD4A71C61522CCBDB8E-- From fernando@gont.com.ar Sat Mar 6 12:27:23 2010 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 0C55D28C0F0 for ; Sat, 6 Mar 2010 12:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 3WmiCYwK1dQS for ; Sat, 6 Mar 2010 12:27:21 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5B35F28C1E4 for ; Sat, 6 Mar 2010 12:27:20 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 67C066B661F; Sat, 6 Mar 2010 17:27:26 -0300 (ART) Received: from [192.168.0.125] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o26KRHnO020487; Sat, 6 Mar 2010 17:27:17 -0300 Message-ID: <4B92BAA7.90705@gont.com.ar> Date: Sat, 06 Mar 2010 17:27:19 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B917D5B.3060804@gont.com.ar> <932500B7-1DE3-4C82-8880-154C7D97291B@nokia.com> <4B928015.2090500@isi.edu> <4B92870A.2030608@gont.com.ar> <4B92924C.6090709@isi.edu> <4B929BA1.7060902@gont.com.ar> <4B929E58.6000007@isi.edu> <4B92B375.5060505@gont.com.ar> <4B92B677.80508@isi.edu> In-Reply-To: <4B92B677.80508@isi.edu> X-Enigmail-Version: 0.96.0 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]); Sat, 06 Mar 2010 17:27:25 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?ISO-8859-1?Q?Alfred_H=F6nes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry 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, 06 Mar 2010 20:27:23 -0000 Joe Touch wrote: >>> Yes, a poll is useful. I have no idea who would "own" that process, or >>> where that info would be maintained. >> Hence my suggestion of an Informational RFC that could be revised now >> and then. > > I think that writing RFCs - informational or not - that are known to be > useless in a short timeframe isn't productive. Agreed. However, I don't think this would be the case. Actually, it's probably a waste of time of those listed in the IANA registry and those needing the aforementioned information to rehash the same questions/answers over and over again. > The IETF is not an operations monitoring organization. However, > informational docs are a path to that. We should NOT have this be a WG > effort- at any level - unless it's in conjunction with a status change, IMO. I don't necessarily share that view. But given the current state of affairs, such a doc would most likely drive a status change. >>>>> I'm not saying it's not useful, but I just don't know who should "own" >>>>> or "endorse" this - the Internet doesn't have a compliance or deployment >>>>> monitoring function AFAICT. >>>> It doesn't look good to have all this options assigned that nobody (*) >>>> knows what they have been used for (if they have ever been used on the >>>> public Internet). >>> I agree that IANA can have better info that can indicate what the option >>> is, and that's easy AFAICT (gather the info, review it in TCPM and on >> Would they really include a description if there's not document >> describing the use of such options? > > A few words at best. If not, perhaps it'd be useful to try to describe > these options in an informational doc they can cite. That's the type of doc I was thinking of. 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 A.Hoenes@TR-Sys.de Sun Mar 7 15:22:50 2010 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 989AE3A67A5 for ; Sun, 7 Mar 2010 15:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.475 X-Spam-Level: ** X-Spam-Status: No, score=2.475 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_20=-0.74, 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 UBJjXtLOG+WN for ; Sun, 7 Mar 2010 15:22:47 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 928C53A6358 for ; Sun, 7 Mar 2010 15:21:15 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA249333876; Mon, 8 Mar 2010 00:17:56 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id AAA29042; Mon, 8 Mar 2010 00:16:40 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003072316.AAA29042@TR-Sys.de> To: huitema@microsoft.com, tcpm@ietf.org Date: Mon, 8 Mar 2010 00:16:39 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] IANA TCP options registry ... 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, 07 Mar 2010 23:22:51 -0000 [ resending after error correction ... ] Christian, thanks for the interesting information at the end of your message: > The bubba and skeeter options were reserved by Stev Knowles, then > working at FTP Software. The options are parts of an encryption system. > The documentation for that system was not made publicly available. > According to Stev, the options were actually deployed and used, > certainly until 2000, and possibly later. The latter comes a bit to surprise. When I sent out my questionaires on TCP options in 2006, I tried hard to follow all traces of bouncing IANA 'people' references and emailed many folks. The most concrete information I could get wrt Skeeter & Bubba was a 3rd-party statement that Stev Knowles did most likely not want to be reminded of that misfortune, and, although my inquiry had been forwarded to him, it was unsure whether he would want to respond... ... and so it happened in January 2007. The only internet-history posting I had found those days (and which Google still finds as the only one) was (by one "co-conspirator"): This does not match very well your alleged report of deployment. An interesting document supporting the impression of failure is the Dissertation of Simson L. Garfinkel (MIT, May 2005), available at . Section 6.1 there gives some insight. " ... The project was abandoned for two reasons. First, an engineer at FTP thought that it would be wasteful to have computers calculate large prime numbers for every TCP connection (none of those working on the project had any training in cryptography ... ). Second, people in the company who understood security critizised the solution because it was susceptible to the man-in-the-middle attack. Today the Bubba and Skeeter TCP options with the cryptic reference to "[Knowles]" in the Internet's list of Assigned Numbers RFCs (e.g., RFC 1700 [RP94]) are the only remnants of the project. " For more, please see . The factual lack of disclosure of information on the design, until today, seems to support the assumption of failure and non-deployment. According to my paper notes (would need to go to backups for more ...), I had mentioned the difficulty to get information on Skeeter/Bubba, and the pointer to this dissertation, in my original message in January 2007, but nobody followed up. The basic work in 2006/2007 had been done, among other goals, to get an overview of whether the idea to include _partial_ TCP option coverage into the proposed successors to the TCP MD5 option made any sense at all. It turned out that all TCP options for which I could get information were strictly end-to-end (as expected) and needed integrity protection. When I eventually found the time to compile all results and posted the "annotated_tcp-parameters.20070216" paper to TCPM, again no feedback was received. Since I now see interest in maintaining more reliable information, about TCP options, the related documentation, and their relevance in the current Internet, I will endeavor to write up the information in an I-D (it will need a few updates). But due to current private&business time restrictions, please be patient. Any more information would be welcome, in particular on Option #24. That was the other 'hard stuff' those days. For Option #26, I had received enough information from the registrant, and I hope to not forestall Steve in stating that the entry in the registry is kept for the historical record of an academic experiment. For Option #18 (Trialer Checksum), it would also be interesting to get more information on its fate. Some WGs maintain web pages about the related IETF protocols. One possibility would be to maintain a page on the IETF tools servers linked to the TCPM WG wiki and/or the WG charter page. draft-ogud-iana-maintenance-words should be considered as a base for adding 'status' information to other IANA registries as well. > > -----Original Message----- > From: tcpm-bounces@ietf.org On Behalf Of Fernando Gont > To: Joe Touch > Cc: tcpm-chairs@tools.ietf.org; Alfred HÎnes; tcpm@ietf.org > Sent: Friday, March 05, 2010 2:51 PM > Subject: Re: [tcpm] IANA TCP options registry > > Hi, Joe, > >>> The IANA TCP options registry >>> (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable >>> information. e.g., you need to figure out by yourself what the "Bubba" >>> option is (or what it is used for), and missing references (e.g., for >>> options #20 through #23 are missing). >> >> Some of that information might be solicited found elsewhere, e.g., >> internet-history@postel.org ;-) > > Yes, but other than that, one should be able to know if the option was > ever deployed, whether it's obsolete, etc. > > e.g., if I wanted to design a firewall policy, I might need that > information. > > >>> What'd be the procedure to have Alfred's registry replace the current >>> one? (i.e., have most/all of the information there make it into the >>> "official" IANA registry). >> >> Ask IANA (iana@iana.org). I don't think this really requires any >> particular policy stuff - some of that info isn't there because it just >> wasn't known when the page was created. > > Ok. I've just e-mailed them. Let's see what happens. Early in 2007, IANA received a request to update references. In 2008, I received a (kinda broadcast) message that they had lost record of many requests, and the recipients should please submit their requests again. That wasn't very encouraging, and after already having spent a lot of time before (in vain) for getting other registries fixed that contain(ed) material obviously contradicting the referenced RFCs, I didn't. :-) > > Thanks! > > Kind regards, > -- > Fernando Gont Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ P.S.: I'd appreciate if the DNS servers in Redmont would stop to blackhole DNS queries from the random source port numbers (!=53) that our NAT/Firewall access router inserts in (query) packets originating on our local recursive DNS resolver, so that messages could be delivered using normal, DNS-based mail routing. From huitema@microsoft.com Sun Mar 7 17:54:09 2010 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 422413A67F5 for ; Sun, 7 Mar 2010 17:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] 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 B38QJ+DmBp8K for ; Sun, 7 Mar 2010 17:54:07 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C8A553A67E1 for ; Sun, 7 Mar 2010 17:54:07 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 7 Mar 2010 17:54:11 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Sun, 7 Mar 2010 17:54:12 -0800 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.84]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Sun, 7 Mar 2010 17:54:10 -0800 From: Christian Huitema To: "ah@TR-Sys.de" , "tcpm@ietf.org" Thread-Topic: [tcpm] IANA TCP options registry ... Thread-Index: AQHKvk9dWYP69lWE2k+elrNb1QbXp5HnRq+Q Date: Mon, 8 Mar 2010 01:54:08 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA685E89E8@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> References: <201003072316.AAA29042@TR-Sys.de> In-Reply-To: <201003072316.AAA29042@TR-Sys.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] IANA TCP options registry ... 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, 08 Mar 2010 01:54:09 -0000 Note that the idea behind these two options is actually quite interesting. = The design appeared to be, do a Diffie-Hellman exchange as part of TCP sync= hronization, and then use the key to protect the TCP data. There is a possi= bility of man-in-the-middle attack, but that can be mitigated by end-to-end= authentication, especially if the end-to-end authentication is seeded with= the TCP session key. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of ah@= TR-Sys.de Sent: Sunday, March 07, 2010 3:17 PM To: Christian Huitema; tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... [ resending after error correction ... ] Christian, thanks for the interesting information at the end of your message: > The bubba and skeeter options were reserved by Stev Knowles, then > working at FTP Software. The options are parts of an encryption system. > The documentation for that system was not made publicly available. > According to Stev, the options were actually deployed and used, > certainly until 2000, and possibly later. The latter comes a bit to surprise. When I sent out my questionaires on TCP options in 2006, I tried hard to follow all traces of bouncing IANA 'people' references and emailed many folks. The most concrete information I could get wrt Skeeter & Bubba was a 3rd-party statement that Stev Knowles did most likely not want to be reminded of that misfortune, and, although my inquiry had been forwarded to him, it was unsure whether he would want to respond... ... and so it happened in January 2007. The only internet-history posting I had found those days (and which Google still finds as the only one) was (by one "co-conspirator"): This does not match very well your alleged report of deployment. An interesting document supporting the impression of failure is the Dissertation of Simson L. Garfinkel (MIT, May 2005), available at . Section 6.1 there gives some insight. " ... The project was abandoned for two reasons. First, an engineer at FTP thought that it would be wasteful to have computers calculate large prime numbers for every TCP connection (none of those working on the project had any training in cryptography ... ). Second, people in the company who understood security critizised the solution because it was susceptible to the man-in-the-middle attack. Today the Bubba and Skeeter TCP options with the cryptic reference to "[Knowles]" in the Internet's list of Assigned Numbers RFCs (e.g., RFC 1700 [RP94]) are the only remnants of the project. " For more, please see . The factual lack of disclosure of information on the design, until today, seems to support the assumption of failure and non-deployment. According to my paper notes (would need to go to backups for more ...), I had mentioned the difficulty to get information on Skeeter/Bubba, and the pointer to this dissertation, in my original message in January 2007, but nobody followed up. The basic work in 2006/2007 had been done, among other goals, to get an overview of whether the idea to include _partial_ TCP option coverage into the proposed successors to the TCP MD5 option made any sense at all. It turned out that all TCP options for which I could get information were strictly end-to-end (as expected) and needed integrity protection. When I eventually found the time to compile all results and posted the "annotated_tcp-parameters.20070216" paper to TCPM, again no feedback was received. Since I now see interest in maintaining more reliable information, about TCP options, the related documentation, and their relevance in the current Internet, I will endeavor to write up the information in an I-D (it will need a few updates). But due to current private&business time restrictions, please be patient. Any more information would be welcome, in particular on Option #24. That was the other 'hard stuff' those days. For Option #26, I had received enough information from the registrant, and I hope to not forestall Steve in stating that the entry in the registry is kept for the historical record of an academic experiment. For Option #18 (Trialer Checksum), it would also be interesting to get more information on its fate. Some WGs maintain web pages about the related IETF protocols. One possibility would be to maintain a page on the IETF tools servers linked to the TCPM WG wiki and/or the WG charter page. draft-ogud-iana-maintenance-words should be considered as a base for adding 'status' information to other IANA registries as well. > > -----Original Message----- > From: tcpm-bounces@ietf.org On Behalf Of Fernando Gont > To: Joe Touch > Cc: tcpm-chairs@tools.ietf.org; Alfred H=CEnes; tcpm@ietf.org > Sent: Friday, March 05, 2010 2:51 PM > Subject: Re: [tcpm] IANA TCP options registry > > Hi, Joe, > >>> The IANA TCP options registry >>> (http://www.iana.org/assignments/tcp-parameters/) lacks of valuable >>> information. e.g., you need to figure out by yourself what the "Bubba" >>> option is (or what it is used for), and missing references (e.g., for >>> options #20 through #23 are missing). >> >> Some of that information might be solicited found elsewhere, e.g., >> internet-history@postel.org ;-) > > Yes, but other than that, one should be able to know if the option was > ever deployed, whether it's obsolete, etc. > > e.g., if I wanted to design a firewall policy, I might need that > information. > > >>> What'd be the procedure to have Alfred's registry replace the current >>> one? (i.e., have most/all of the information there make it into the >>> "official" IANA registry). >> >> Ask IANA (iana@iana.org). I don't think this really requires any >> particular policy stuff - some of that info isn't there because it just >> wasn't known when the page was created. > > Ok. I've just e-mailed them. Let's see what happens. Early in 2007, IANA received a request to update references. In 2008, I received a (kinda broadcast) message that they had lost record of many requests, and the recipients should please submit their requests again. That wasn't very encouraging, and after already having spent a lot of time before (in vain) for getting other registries fixed that contain(ed) material obviously contradicting the referenced RFCs, I didn't. :-) > > Thanks! > > Kind regards, > -- > Fernando Gont Kind regards, Alfred H=CEnes. --=20 +------------------------+--------------------------------------------+ | 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 | +------------------------+--------------------------------------------+ P.S.: I'd appreciate if the DNS servers in Redmont would stop to blackhole DNS queries from the random source port numbers (!=3D53) that our NAT/Firewall access router inserts in (query) packets originating on our local recursive DNS resolver, so that messages could be delivered using normal, DNS-based mail routing. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From root@core3.amsl.com Mon Mar 8 07:30:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 389B73A69B4; Mon, 8 Mar 2010 07:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308153002.389B73A69B4@core3.amsl.com> Date: Mon, 8 Mar 2010 07:30:01 -0800 (PST) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-sack-recovery-entry-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, 08 Mar 2010 15:30:02 -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 : Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation Author(s) : I. Jarvinen, M. Kojo Filename : draft-ietf-tcpm-sack-recovery-entry-01.txt Pages : 18 Date : 2010-03-08 This document describes a TCP sender algorithm to trigger loss recovery based on the TCP Selective Acknowledgement (SACK) information gathered on a SACK scoreboard instead of simply counting the number of arriving duplicate acknowledgements (ACKs) 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-sack-recovery-entry-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-sack-recovery-entry-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08072515.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Mon Mar 8 10:35:27 2010 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 EEBDF3A6AE3 for ; Mon, 8 Mar 2010 10:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 4SYbE-Dpk15z for ; Mon, 8 Mar 2010 10:35:27 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 38EF13A6AAF for ; Mon, 8 Mar 2010 10:35:27 -0800 (PST) Received: from [75.213.84.180] (180.sub-75-213-84.myvzw.com [75.213.84.180]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o28IYScj015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Mar 2010 10:34:31 -0800 (PST) Message-ID: <4B954334.2050908@isi.edu> Date: Mon, 08 Mar 2010 10:34:28 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alfred ? References: <201003072316.AAA29042@TR-Sys.de> In-Reply-To: <201003072316.AAA29042@TR-Sys.de> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA63E21230CB20FBC56DAC83B" X-MailScanner-ID: o28IYScj015824 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: huitema@microsoft.com, tcpm@ietf.org Subject: Re: [tcpm] IANA TCP options registry ... 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, 08 Mar 2010 18:35:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA63E21230CB20FBC56DAC83B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alfred, Alfred ? wrote: =2E.. > draft-ogud-iana-maintenance-words should be considered as a base > for adding 'status' information to other IANA registries as well. This document confuses IANA with a compliance organization. IANA maintains registries, and provides information on the status of those registrations where used to maintain the registry. A compliance site may be useful, but I don't think it's in IANA's charter. *Some* of the words in this doc may be useful, but need to come out of some assessment of a standard - it's not possible to look at individual components of a standard and make these decisions. The two questions that result are: - who makes the assessments in the doc? - where is that info maintained? We have had docs that occasionally provide roadmaps in a general sense, but this is much deeper into what a compliance organization would recommend for implementations, and seems out of scope for even the IETF, AFAICT.=09 Joe --------------enigA63E21230CB20FBC56DAC83B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuVQzQACgkQE5f5cImnZruvJwCgwgXZghLWmFD4h/vRhNz/LDdx hBsAnAuPjH3iJg/HxXHytO/MsJ+nXCEB =KF3x -----END PGP SIGNATURE----- --------------enigA63E21230CB20FBC56DAC83B-- From wesley.m.eddy@nasa.gov Mon Mar 8 11:49:34 2010 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 651A03A6ABB for ; Mon, 8 Mar 2010 11:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 Irftlm1AwJpg for ; Mon, 8 Mar 2010 11:49:33 -0800 (PST) Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 4AAE33A6BB0 for ; Mon, 8 Mar 2010 11:49:29 -0800 (PST) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id 3B9302D8645 for ; Mon, 8 Mar 2010 13:49:33 -0600 (CST) Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o28JnXcv029646 for ; Mon, 8 Mar 2010 13:49:33 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 8 Mar 2010 13:49:32 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Mon, 8 Mar 2010 13:49:31 -0600 Thread-Topic: poll for adoption of draft-ananth-persist-02 Thread-Index: Acq++HhKPa/WNfamRcGprqSmMXJeBg== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-08_10:2010-02-06, 2010-03-08, 2010-03-08 signatures=0 Subject: [tcpm] poll for adoption of draft-ananth-persist-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, 08 Mar 2010 19:49:34 -0000 The authors have updated draft-ananth-persist, and asked us to poll the TCPM WG to have this particular document adopted with an Informational target. http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt This has been discussed to some extent on the mailing list and at the Dublin meeting. The authors have responded to comments received thus far and updated the document as it grew from the outcome of prior feedback on the draft-mahesh-persist-timeout document. Please respond if you either: (1) Support making this document a WG document with the target for Informational. (2) Oppose making this document a WG document. Of course, other comments are also welcome :). It's relatively short, so if people could respond in the next 2 weeks, this would allow us to determine consensus during the week of the IETF meeting. -- Wes Eddy MTI Systems From wesley.m.eddy@nasa.gov Mon Mar 8 11:49:35 2010 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 12AD63A6BAC for ; Mon, 8 Mar 2010 11:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 W3U7KwuH8U4Q for ; Mon, 8 Mar 2010 11:49:34 -0800 (PST) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id 7585F3A6BC0 for ; Mon, 8 Mar 2010 11:49:30 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id A7FDEA8812 for ; Mon, 8 Mar 2010 13:49:34 -0600 (CST) Received: from ndjshub04.ndc.nasa.gov (ndjshub04-pub.ndc.nasa.gov [198.117.1.34]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o28JnYUg001816 for ; Mon, 8 Mar 2010 13:49:34 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Mon, 8 Mar 2010 13:49:33 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Mon, 8 Mar 2010 13:49:32 -0600 Thread-Topic: poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: Acq++HkxzqlYiFb8RpWTnjXxmEEnYQ== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-08_10:2010-02-06, 2010-03-08, 2010-03-08 signatures=0 Subject: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 08 Mar 2010 19:49:35 -0000 Hello, Fernando has made an update to his draft on the generation of TCP timestamps, and asked us to poll the TCPM WG to have this particular document adopted as a WG draft for BCP. http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-03 This was briefly discussed at IETF 73 in Minneapolis, and the decision was delayed until more people had read it. Please respond if you either: (1) Support making this document a WG document with the target for BCP. (2) Oppose making this document a WG document. Of course, other comments are also welcome :). It's relatively short, so if people could respond in the next 2 weeks, this would allow us to determine consensus during the week of the IETF meeting. -- Wes Eddy MTI Systems From hkchu@google.com Mon Mar 8 16:35:07 2010 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 5AFB73A6B67 for ; Mon, 8 Mar 2010 16:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 47+h4XzRnIMf for ; Mon, 8 Mar 2010 16:35:06 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1ACBE3A6A8F for ; Mon, 8 Mar 2010 16:35:02 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o290Z5S3023587 for ; Tue, 9 Mar 2010 00:35:05 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1268094905; bh=q1i8FaO3iZYtkY9jr8LmfAf8fPE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=d9TA9WqVrGE3yS0+oJf/a02yKZT5DCa0kekAAuhdBiJe4WjoCEkvJRsiuzGpOOCbC XYgI7YkB4HQ2rLCj4GtWQ== 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: content-type:x-system-of-record; b=mFANcbyjNGqknEH9RVUgmsJAkriSSFv4TXoLwQlK2mOVGyLtWRUJ+tErlH/3GpYls e/vb/KIDVS+LeeA5/at6w== Received: from iwn27 (iwn27.prod.google.com [10.241.68.91]) by wpaz13.hot.corp.google.com with ESMTP id o290Z3cj022245 for ; Mon, 8 Mar 2010 16:35:04 -0800 Received: by iwn27 with SMTP id 27so4065354iwn.5 for ; Mon, 08 Mar 2010 16:35:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.159.207 with SMTP id k15mr254375ibx.75.1268094903638; Mon, 08 Mar 2010 16:35:03 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Mar 2010 16:35:03 -0800 Message-ID: From: Jerry Chu To: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Content-Type: multipart/alternative; boundary=005045016abd45dfb30481535a12 X-System-Of-Record: true Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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: Tue, 09 Mar 2010 00:35:07 -0000 --005045016abd45dfb30481535a12 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The link to the paper below has been fixed. Sorry for the delay. Jerry On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu wrote: > Our first draft proposal to raise the initial congestion window was > submitted > a couple of days ago and is available at > > http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt > > A paper with the title "An Argument for Increasing TCP=92s Initial Conges= tion > Window" detailing our large scale experiments will soon be available at > > http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf > (The link is not there yet due to a last minute snag. Hopefully it > will be fixed asap.) > > Comments are welcome. > > Jerry > > > -------------------------------------------------------------------------= ---------------------------------- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt > X-RSN: 1/0/935/28943/32298 > X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D32298 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Increasing TCP's Initial Window > Author(s) : J. Chu, et al. > Filename : draft-hkchu-tcpm-initcwnd-00.txt > Pages : 16 > Date : 2010-02-28 > > This document proposes an increase in the permitted TCP initial > window (IW) from between 2 and 4 segments, as specified in RFC 3390, > to 10 segments. It discusses the motivation behind the increase, the > advantages and disadvantages of the higher initial window, and > presents results from several large scale experiments showing that > the higher initial window improves the overall performance of many > web services without risking congestion collapse. Finally, it > outlines a list of concerns to be addressed in future tests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > --005045016abd45dfb30481535a12 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The link to the paper below has been fixed. Sorry for the delay.

Jer= ry

On Tue, Mar 2, 2010 at 2:50 PM, Jerry = Chu <hkchu@google.= com> wrote:
Our first draft p= roposal to raise the initial congestion window was submitted
a couple of days ago and is available at

http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt

A paper with the title "An Argument for Increasing TCP=92s Initial Con= gestion
Window" detailing our large scale experiments will soon be available a= t

http://code.google.com/speed/articles/tcp_initcwnd_paper.pd= f
(The link is not there yet due to a last minute snag. Hopefully it
will be fixed asap.)

Comments are welcome.

Jerry

---------------------------------------------------------------------------= --------------------------------
From: Internet-Drafts@ietf.org<= /a>
To: i-d-announce@ietf.org
Reply-to: Internet-Drafts@ietf.= org
Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
X-RSN: 1/0/935/28943/32298
X-HREF: http://www.ietf.org/ibin/c5i?mid= =3D6&rid=3D49&k1=3D935&k2=3D32298

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

Title : Increasing TCP's Initial Window
Author(s) : J. Chu, et al.
Filename : draft-hkchu-tcpm-initcwnd-00.txt
Pages : 16
Date : 2010-02-28

This document proposes an increase in the permitted TCP initial
window (IW) from between 2 and 4 segments, as specified in RFC 3390,
to 10 segments. It discusses the motivation behind the increase, the
advantages and disadvantages of the higher initial window, and
presents results from several large scale experiments showing that
the higher initial window improves the overall performance of many
web services without risking congestion collapse. Finally, it
outlines a list of concerns to be addressed in future tests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hkchu-tcp= m-initcwnd-00.txt

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

--005045016abd45dfb30481535a12-- From c.raiciu@cs.ucl.ac.uk Tue Mar 9 03:34:43 2010 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 92DFF3A6824 for ; Tue, 9 Mar 2010 03:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 x0Dx0f-hdbsr for ; Tue, 9 Mar 2010 03:34:42 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by core3.amsl.com (Postfix) with ESMTP id 8C0963A68E3 for ; Tue, 9 Mar 2010 03:34:42 -0800 (PST) Received: from blackie2.cs.ucl.ac.uk ([128.16.68.58]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1Nowjg-000A9n-5X; Tue, 09 Mar 2010 10:32:24 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Costin Raiciu In-Reply-To: Date: Tue, 9 Mar 2010 11:34:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jerry Chu X-Mailer: Apple Mail (2.1077) Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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: Tue, 09 Mar 2010 11:34:43 -0000 Hi, I've skimmed your paper hoping to see big improvements in loading times=20= However, the reductions in download times you find are below 10% - and = this is the best case only a subset of traffic is increasing the initial = cwnd. =20 The experiments in 4.2 show that using Maps in the slowDC scenario can = negatively affect the download time too for some users, by roughly the = same amount. When all traffic uses the initial cwnd of 10 I expect to = see=20 smaller improvements or even increases in download times for all web = traffic. Thus, the 10% average improvement does not seem very compelling to me. = Have you tested upload speeds? As DSL uploads are 128-256Kbps, I expect = using an initial cwnd of 10 packets will result in increased loading = times for web uploads, for instance, in the best case. As DSL lines have = buffers roughly of that length, causing burst of 10 packets will = negatively affect all other ongoing connections. So it seems to me this may be a good idea to standardize for servers, = and not for regular hosts. And even for servers, it is hard to = understand the effects when everybody uses this large init_cwnd. Cheers, Costin On 9 Mar 2010, at 00:35, Jerry Chu wrote: > The link to the paper below has been fixed. Sorry for the delay. >=20 > Jerry >=20 > On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu wrote: > Our first draft proposal to raise the initial congestion window was = submitted > a couple of days ago and is available at >=20 > http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt >=20 > A paper with the title "An Argument for Increasing TCP=92s Initial = Congestion > Window" detailing our large scale experiments will soon be available = at >=20 > http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf > (The link is not there yet due to a last minute snag. Hopefully it > will be fixed asap.) >=20 > Comments are welcome. >=20 > Jerry >=20 > = --------------------------------------------------------------------------= --------------------------------- > From: Internet-Drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt > X-RSN: 1/0/935/28943/32298 > X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D3229= 8 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Increasing TCP's Initial Window > Author(s) : J. Chu, et al. > Filename : draft-hkchu-tcpm-initcwnd-00.txt > Pages : 16 > Date : 2010-02-28 >=20 > This document proposes an increase in the permitted TCP initial > window (IW) from between 2 and 4 segments, as specified in RFC 3390, > to 10 segments. It discusses the motivation behind the increase, the > advantages and disadvantages of the higher initial window, and > presents results from several large scale experiments showing that > the higher initial window improves the overall performance of many > web services without risking congestion collapse. Finally, it > outlines a list of concerns to be addressed in future tests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Tue Mar 9 09:16:03 2010 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 1B2E83A684B for ; Tue, 9 Mar 2010 09:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 XSbml0swzrvt for ; Tue, 9 Mar 2010 09:16:02 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 774C43A68F6 for ; Tue, 9 Mar 2010 09:15:58 -0800 (PST) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o29HG233019779; Tue, 9 Mar 2010 09:16:02 -0800 (PST) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 48A92AB1CF5; Tue, 9 Mar 2010 12:16:02 -0500 (EST) To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: It's Money That Matters MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma33362-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 09 Mar 2010 12:16:02 -0500 Sender: mallman@icir.org Message-Id: <20100309171602.48A92AB1CF5@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Auth Option obsoleting MD5 Option in IANA registry 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: Tue, 09 Mar 2010 17:16:03 -0000 ----------ma33362-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > It's proposed that since the TCP AO document > obsoletes the TCP MD5 RFC, that the option assigned > to TCP AO obsolete Kind=19, the MD5 Signature > Option, and this would be noted in the IANA registry. > > I think this should be easily agreed to by TCPM, > since AO was created to obsolete the MD5 option, > but if there are any objections to this, now is a > good time to make them :). Seems like a reasonable plan to me. allman ----------ma33362-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuWglIACgkQWyrrWs4yIs7XCgCfVVr78lKuVyLXCAAM8waLvCZP gY4AnieR47DOY1HRnFnoPQpYkC4kzA1c =cKXx -----END PGP SIGNATURE----- ----------ma33362-1-- From hkchu@google.com Tue Mar 9 11:25:31 2010 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 E0C7D3A69D8 for ; Tue, 9 Mar 2010 11:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VGS+I05iJHpL for ; Tue, 9 Mar 2010 11:25:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DDF963A69B3 for ; Tue, 9 Mar 2010 11:25:29 -0800 (PST) Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id o29JPVjr017503 for ; Tue, 9 Mar 2010 11:25:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1268162733; bh=GY8rb6hxT5ZyChci1e7Ilt4Y9ho=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wJGtgfBGVmnsuA5tpSq0UeWcrdCY/lT18N5hwrl5DeIt/wOF2sLT3DOduhN4aVXvO Iahkiq+9yhYrBPtChyDFw== 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:x-system-of-record; b=eto9L7Jhh+/W5FCNIgA4yM35h50Jp2IV9PAnKdZnExgjpaOcCd/dB/mLn938vWD0e eg7ZYaz8loWT4mRS09dGg== Received: from iwn30 (iwn30.prod.google.com [10.241.68.94]) by kpbe11.cbf.corp.google.com with ESMTP id o29JPUrt012136 for ; Tue, 9 Mar 2010 13:25:30 -0600 Received: by iwn30 with SMTP id 30so6581887iwn.32 for ; Tue, 09 Mar 2010 11:25:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.183.133 with SMTP id cg5mr123157ibb.12.1268162730003; Tue, 09 Mar 2010 11:25:30 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Mar 2010 11:25:29 -0800 Message-ID: From: Jerry Chu To: c.raiciu@cs.ucl.ac.uk Content-Type: multipart/alternative; boundary=0016362852120a558704816325ac X-System-Of-Record: true Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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: Tue, 09 Mar 2010 19:25:32 -0000 --0016362852120a558704816325ac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu wrote= : > Hi, > > I've skimmed your paper hoping to see big improvements in loading times > > However, the reductions in download times you find are below 10% - and th= is > is the best case only a subset of traffic is increasing the initial cwnd. > I don't know about you, but imagine a simple change that can deliver a 10% improvement (in average) over ALL web traffic regardless of the response sizes (some ar= e much less than 10 segments), access speed,..., etc. That is A LOT to me! But of course we'll need to carefully study and understand the possible negative impact too. > The experiments in 4.2 show that using Maps in the slowDC scenario can > negatively affect the download time too for some users, by roughly the sa= me > amount. Yes there will always be someone, somewhere, who will be negatively impacte= d by any change to TCP. Ultimately t's a benefit vs cost tradeoff. The negative impact as shown in Table 8 is limited to only 4% of the traffic in SlowDC, which is expected t= o be one of the worst performing DCs. Is it fair to write off the win from the rest of 96% of traffic? > When all traffic uses the initial cwnd of 10 I expect to see > smaller improvements or even increases in download times for all web > traffic. > Not sure why you expected so. Note that we strived to turn on IW=3D10 on th= e whole DC scale in order to measure the worse impact (when a user gets upto IW=3D10 bursts from all Google servers). > Thus, the 10% average improvement does not seem very compelling to me. Again the 10% is only the AVERAGE, which in the case of web search includes a long backend process time. The micro-level RTT saving is much larger as shown in the table in section 5 of the I-D. Also don't forget to pay attention to the rest of the data in the paper (besides the gross average of 10% improvement). When we sliced and diced the data, many are showing > 20% latency improvments (Figure 5, 6, Table 6...) > Have you tested upload speeds? As DSL uploads are 128-256Kbps, I expect > using an initial cwnd of 10 packets will result in increased loading time= s > for web uploads, for instance, in the best case. As DSL lines have buffer= s > roughly of that length, causing burst of 10 packets will negatively affec= t > all other ongoing connections. > Not sure where you get the "10 pkts" data from. My home cable modem (yes it's faster than DSL) seems to have many seconds of uplink buffer space). But large buffer creates a whole set of different problems and is being address by LEDBAT (?), 10 pkt bursts seem to be the least of the problems. > So it seems to me this may be a good idea to standardize for servers, and > not for regular hosts. And even for servers, it is hard to understand the > effects when everybody uses this large init_cwnd. > Agreed about the last point. Will need help from folks on this list to charter a plan forward. Thanks, Jerry > > Cheers, > Costin > > On 9 Mar 2010, at 00:35, Jerry Chu wrote: > > > The link to the paper below has been fixed. Sorry for the delay. > > > > Jerry > > > > On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu wrote: > > Our first draft proposal to raise the initial congestion window was > submitted > > a couple of days ago and is available at > > > > http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt > > > > A paper with the title "An Argument for Increasing TCP=92s Initial > Congestion > > Window" detailing our large scale experiments will soon be available at > > > > http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf > > (The link is not there yet due to a last minute snag. Hopefully it > > will be fixed asap.) > > > > Comments are welcome. > > > > Jerry > > > > > -------------------------------------------------------------------------= ---------------------------------- > > From: Internet-Drafts@ietf.org > > To: i-d-announce@ietf.org > > Reply-to: Internet-Drafts@ietf.org > > Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt > > X-RSN: 1/0/935/28943/32298 > > X-HREF: http://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&k1=3D935&k2=3D322= 98 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : Increasing TCP's Initial Window > > Author(s) : J. Chu, et al. > > Filename : draft-hkchu-tcpm-initcwnd-00.txt > > Pages : 16 > > Date : 2010-02-28 > > > > This document proposes an increase in the permitted TCP initial > > window (IW) from between 2 and 4 segments, as specified in RFC 3390, > > to 10 segments. It discusses the motivation behind the increase, the > > advantages and disadvantages of the higher initial window, and > > presents results from several large scale experiments showing that > > the higher initial window improves the overall performance of many > > web services without risking congestion collapse. Finally, it > > outlines a list of concerns to be addressed in future tests. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hkchu-tcpm-initcwnd-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > --0016362852120a558704816325ac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Mar 9, 2010 at 3:34 AM, Costin Raiciu <c.raiciu@cs.ucl.ac.uk> wrot= e:
Hi,

I've skimmed your paper hoping to see big improvements in loading =A0ti= mes

However, the reductions in download times you find are below 10% - and this= is the best case only a subset of traffic is increasing the initial cwnd.<= br>
=A0
I don't know about you, but imagine = a simple change that can deliver a 10% improvement
(in average) over ALL web traffic regardless of the response sizes (some ar= e much less than
10 segments), access speed,..., etc. That is A LOT to m= e!

But of course we'll need to carefully study and understand th= e possible negative impact too.
=A0
The experiments in 4.2 show that using Maps in the slowDC scenario can nega= tively affect the download time too for some users, by roughly the same amo= unt.

Yes there will always be someone, somewhere, who = will be negatively impacted by any
change to TCP. Ultimately t's a benefit vs cost tradeoff. The negative = impact as shown in
Table 8 is limited to only 4% of the traffic in SlowD= C, which is expected to be one of the
worst performing DCs. Is it fair t= o write off the win from the rest of 96% of traffic?
=A0
When all= traffic uses the initial cwnd of 10 I expect to see
smaller improvements or even increases in download times for all web traffi= c.

Not sure why you expected so. Note that we stri= ved to turn on IW=3D10 on the whole DC scale
in order to measure the wor= se impact (when a user gets upto IW=3D10 bursts from all Google
servers).


Thus, the 10% average improvement does not seem very compelling to me.

Again the 10% is only the AVERAGE, which in the case of we= b search includes a long
backend process time. The micro-level RTT savin= g is much larger as shown in the table in
section 5 of the I-D.

Also don't forget to pay attention to the = rest of the data in the paper (besides the gross
average of 10% improvem= ent). When we sliced and diced the data, many are showing > 20%
laten= cy improvments (Figure 5, 6, Table 6...)
=A0
Hav= e you tested upload speeds? As DSL uploads are 128-256Kbps, I expect using = an initial cwnd of 10 packets will result in increased loading times for we= b uploads, for instance, in the best case. As DSL lines have buffers roughl= y of that length, causing burst of 10 packets will negatively affect all ot= her ongoing connections.

Not sure where you get the "10 pkts" data f= rom. My home cable modem (yes it's faster than
DSL) seems to have ma= ny seconds of uplink buffer space). But large buffer creates a whole
set of different problems and is being address by LEDBAT (?), 10 pkt bursts= seem to be the
least of the problems.


So it seems to me this may be a good idea to standardize for servers, and n= ot for regular hosts. And even for servers, it is hard to understand the ef= fects when everybody uses this large init_cwnd.

Agreed about the last point. Will need help from folks on this list to char= ter a plan forward.

Thanks,

Jerry
=A0

Cheers,
Costin

On 9 Mar 2010, at 00:35, Jerry Chu wrote:

> The link to the paper below has been fixed. Sorry for the delay.
>
> Jerry
>
> On Tue, Mar 2, 2010 at 2:50 PM, Jerry Chu <hkchu@google.com> wrote:
> Our first draft proposal to raise the initial congestion window was su= bmitted
> a couple of days ago and is available at
>
> http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt=
>
> A paper with the title "An Argument for Increasing TCP=92s Initia= l Congestion
> Window" detailing our large scale experiments will soon be availa= ble at
>
> http://code.google.com/speed/articles/tcp_initcwnd_pap= er.pdf
> (The link is not there yet due to a last minute snag. Hopefully it
> will be fixed asap.)
>
> Comments are welcome.
>
> Jerry
>
> ----------------------------------------------------------------------= -------------------------------------
> From: Internet-Drafts@ietf= .org
> To: i-d-announce@ietf.org=
> Reply-to: Internet-Drafts@= ietf.org
> Subject: I-D Action:draft-hkchu-tcpm-initcwnd-00.txt
> X-RSN: 1/0/935/28943/32298
> X-HREF: http://www.ietf.org/ibin/c5i?= mid=3D6&rid=3D49&k1=3D935&k2=3D32298
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
> Title : Increasing TCP's Initial Window
> Author(s) : J. Chu, et al.
> Filename : draft-hkchu-tcpm-initcwnd-00.txt
> Pages : 16
> Date : 2010-02-28
>
> This document proposes an increase in the permitted TCP initial
> window (IW) from between 2 and 4 segments, as specified in RFC 3390, > to 10 segments. It discusses the motivation behind the increase, the > advantages and disadvantages of the higher initial window, and
> presents results from several large scale experiments showing that
> the higher initial window improves the overall performance of many
> web services without risking congestion collapse. Finally, it
> outlines a list of concerns to be addressed in future tests.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hkch= u-tcpm-initcwnd-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--0016362852120a558704816325ac-- From perfgeek@mac.com Tue Mar 9 19:36:15 2010 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 DC5393A6AC9 for ; Tue, 9 Mar 2010 19:36:15 -0800 (PST) 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 LNO461d232Q3 for ; Tue, 9 Mar 2010 19:36:14 -0800 (PST) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by core3.amsl.com (Postfix) with ESMTP id B4AAE3A67E1 for ; Tue, 9 Mar 2010 19:36:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ100H3ORBNHE30@asmtp021.mac.com> for tcpm@ietf.org; Tue, 09 Mar 2010 19:35:49 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003090287 Message-id: <4A655CBC-A0C4-48AF-B1D9-FB991051A08C@mac.com> From: rick jones To: Jerry Chu In-reply-to: Date: Tue, 09 Mar 2010 19:35:47 -0800 References: X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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, 10 Mar 2010 03:36:16 -0000 On Mar 9, 2010, at 11:25 AM, Jerry Chu wrote: > I don't know about you, but imagine a simple change that can deliver > a 10% improvement > (in average) over ALL web traffic regardless of the response sizes > (some are much less than > 10 segments), access speed,..., etc. That is A LOT to me! Indeed, 10% average improvement is impressive. Is there a way to tease-out what the "typical" cwnd becomes in both the base and exp cases? Say from those services with larger responses? Does it become 8*MSS? 12*MSS etc? That would help show how "close to the edge" 10 segments might be yes? WRT the retransmissions (table 7 in the paper), is it safe to ass-u-me that the increase in retransmissions means a corresponding increase in "Internet" bandwidth consumed to deliver the given quantity of data? rick jones there is no rest for the wicked, yet the virtuous have no pillows wisdom teeth are impacted, people and things are affected by the effects of events :) From hkchu@google.com Tue Mar 9 22:07:18 2010 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 3B4D53A6BE2 for ; Tue, 9 Mar 2010 22:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9Vh1y-V4aApf for ; Tue, 9 Mar 2010 22:07:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 315763A6BD5 for ; Tue, 9 Mar 2010 22:07:17 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id o2A67Krb027105 for ; Tue, 9 Mar 2010 22:07:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1268201240; bh=BQCoX5+CRdSS/1eVXlielGDtLf4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=DTSMpiswOl18yJKHBAhZaWPwgIglRj3S8x+KCx1xE777ugqwkUP87Goy9bRQ+TmCJ o9+bmzDpuhNfRcRjZ/72Q== 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=HWiuNLedWH9IF0oy5z7x8ATVOxcTbSiNTHJhLHFk/H114QHak4ve3tOna7cVRJRuh dKZ3JUvtdqloptvVqCe8A== Received: from iwn29 (iwn29.prod.google.com [10.241.68.93]) by spaceape7.eur.corp.google.com with ESMTP id o2A67Igo027499 for ; Tue, 9 Mar 2010 22:07:19 -0800 Received: by iwn29 with SMTP id 29so4125160iwn.10 for ; Tue, 09 Mar 2010 22:07:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.173.129 with SMTP id p1mr436724ibz.85.1268201238219; Tue, 09 Mar 2010 22:07:18 -0800 (PST) In-Reply-To: <4A655CBC-A0C4-48AF-B1D9-FB991051A08C@mac.com> References: <4A655CBC-A0C4-48AF-B1D9-FB991051A08C@mac.com> Date: Tue, 9 Mar 2010 22:07:17 -0800 Message-ID: From: Jerry Chu To: rick jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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, 10 Mar 2010 06:07:18 -0000 On Tue, Mar 9, 2010 at 7:35 PM, rick jones wrote: > > On Mar 9, 2010, at 11:25 AM, Jerry Chu wrote: >> >> I don't know about you, but imagine a simple change that can deliver a 1= 0% >> improvement >> (in average) over ALL web traffic regardless of the response sizes (some >> are much less than >> 10 segments), access speed,..., etc. That is A LOT to me! > > Indeed, 10% average improvement is impressive. > > Is there a way to tease-out what the "typical" cwnd becomes in both the b= ase > and exp cases? =A0Say from those services with larger responses? Does it > become 8*MSS? =A012*MSS etc? =A0That would help show how "close to the ed= ge" 10 > segments might be yes? Yes it's certainly doable but one problem with most of the services is that there are fewer larger responses, interleaved with many smaller responses, and the va= st majority of HTTP connections don't persist long enough to allow cwnd/ssthre= sh to converge in a more meaningful way. In order to perform a more detailed analysis on some network properties, we= are thinking about instrumenting a bulk data service like Youtube to avoid the = above mentioned problem, as described in section 11.2 of the I-D. The idea is to monitor some key TCP parameters at various stage of a connection (and Linux kernel already conveniently provide "TCP_INFO" socket option). But before we proce= ed we like to first hear suggestions from the lists. This is because any large scale experiment can be very time/resource consuming. In this case we'll likely h= ave to set up a different logging system for Youtube, may even have to build and deploy a different kernel with the right instrumentation (TCP_INFO may not provide= all the info we'll need) to many thousand machines..., etc. > > WRT the retransmissions (table 7 in the paper), is it safe to ass-u-me th= at > the increase in retransmissions means a corresponding increase in "Intern= et" > bandwidth consumed to deliver the given quantity of data? I don't see why not. (Am I missing something?) Thanks, Jerry > > rick jones > there is no rest for the wicked, yet the virtuous have no pillows > wisdom teeth are impacted, people and things are affected by the effects = of > events :) > From perfgeek@mac.com Wed Mar 10 08:02:10 2010 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 A00093A6B51 for ; Wed, 10 Mar 2010 08:02:10 -0800 (PST) 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 8vV5SmgAu+yb for ; Wed, 10 Mar 2010 08:02:09 -0800 (PST) Received: from asmtpout013.mac.com (asmtpout013.mac.com [17.148.16.88]) by core3.amsl.com (Postfix) with ESMTP id C317D3A6B3B for ; Wed, 10 Mar 2010 08:02:09 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.101] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by asmtp013.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KZ2008WKPVLA180@asmtp013.mac.com> for tcpm@ietf.org; Wed, 10 Mar 2010 08:02:10 -0800 (PST) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003100129 Message-id: <60D1C7D7-6456-440A-BF2B-33C0D75ED7BE@mac.com> From: rick jones To: Jerry Chu In-reply-to: Date: Wed, 10 Mar 2010 08:02:08 -0800 References: <4A655CBC-A0C4-48AF-B1D9-FB991051A08C@mac.com> X-Mailer: Apple Mail (2.936) Cc: tcpm@ietf.org, iccrg@cs.ucl.ac.uk Subject: Re: [tcpm] I-D Action:draft-hkchu-tcpm-initcwnd-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, 10 Mar 2010 16:02:10 -0000 On Mar 9, 2010, at 10:07 PM, Jerry Chu wrote: > On Tue, Mar 9, 2010 at 7:35 PM, rick jones wrote: >> Is there a way to tease-out what the "typical" cwnd becomes in both >> the base >> and exp cases? Say from those services with larger responses? Does >> it >> become 8*MSS? 12*MSS etc? That would help show how "close to the >> edge" 10 >> segments might be yes? > > Yes it's certainly doable but one problem with most of the services is > that there are fewer larger responses, interleaved with many smaller > responses, and the vast > majority of HTTP connections don't persist long enough to allow cwnd/ > ssthresh to > converge in a more meaningful way. > > In order to perform a more detailed analysis on some network > properties, we are > thinking about instrumenting a bulk data service like Youtube to > avoid the above > mentioned problem, as described in section 11.2 of the I-D. The idea > is to monitor some key TCP parameters at various stage of a > connection (and Linux kernel > already conveniently provide "TCP_INFO" socket option). But before > we proceed > we like to first hear suggestions from the lists. This is because any > large scale experiment can be very time/resource consuming. In this > case we'll likely have > to set up a different logging system for Youtube, may even have to > build and deploy a different kernel with the right instrumentation > (TCP_INFO may not provide all > the info we'll need) to many thousand machines..., etc. I probably would simply start with logging the cwnd, ssthresh, retransmission count and bytes transferred at the end of a connection. Without having any firm basis to support it, I suspect that cwnd at the end of the connection is "good enough" and one doesn't need max cwnd. >> WRT the retransmissions (table 7 in the paper), is it safe to ass-u- >> me that >> the increase in retransmissions means a corresponding increase in >> "Internet" >> bandwidth consumed to deliver the given quantity of data? > > I don't see why not. (Am I missing something?) Probably not - I was simply wondering if I might have been - it does call for chaining an assumption or two about the distribution of the size of the retransmitted segments versus the whole along with the acceptance that 99 times out of 10 the losses are in the last mile. rick jones Wisdom teeth are impacted, people are affected by the effects of events From ietfdbh@comcast.net Wed Mar 10 23:39:14 2010 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 02EDC3A6B2E for ; Wed, 10 Mar 2010 23:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_46=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 Gl1Z0jWRHaIT for ; Wed, 10 Mar 2010 23:39:13 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 113B53A6B2D for ; Wed, 10 Mar 2010 23:39:12 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id rjcn1d0030xGWP852jfKJU; Thu, 11 Mar 2010 07:39:19 +0000 Received: from Harrington73653 ([24.61.220.197]) by omta12.westchester.pa.mail.comcast.net with comcast id rjfJ1d0044G8Frs3YjfKRb; Thu, 11 Mar 2010 07:39:19 +0000 From: "David Harrington" To: References: <5981EBEA-5F7B-422A-A094-5D2548F705EB@windriver.com><4B8D8AAF.50402@gont.com.ar><4B8DE59E.50706@gont.com.ar><4B8F1A05.90908@gont.com.ar><48EE1847-6702-4F62-B526-055AF977C36C@weston.borman.com> <4B9098A8.4050501@gont.com.ar> Date: Thu, 11 Mar 2010 02:39:17 -0500 Message-ID: <004a01cac0ed$f4f24260$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acq8JgOufwzkoS93RtiEHpa6aJcxEAExz+Zw In-Reply-To: <4B9098A8.4050501@gont.com.ar> Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.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: Thu, 11 Mar 2010 07:39:14 -0000 Hi, as an individual contributor ... It probably won't matter which you choose as long as you are consistent. And that consistency needs to be within the document and across WG documents. The RFC editor will usually demand consistency, whichever choice is made. dbh David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Friday, March 05, 2010 12:38 AM > To: David Borman > Cc: tcpm-chairs@tools.ietf.org; tcpm@ietf.org WG; ayourtch@cisco.com > Subject: Re: [tcpm] WGLC: draft-ietf-tcpm-urgent-data-02.txt > > Hello, David, > > >> If I were to s/were/was/, it looks like I should rephrase the text > >> as 'that a data byte that was received as "normal data"...'... > > > [...] > > If there are 12 cookies for sale, individually wrapped, you would > > say: There are a dozen cookies for sale. But if they are being sold > > in a single package, you would say: There is a dozen cookies for > > sale. > > Got it ;-) > > > > I think I've adequately explained my reasoning, so now you > can choose > > which way to word it. I'll be fine with whatever you choose. > > As expected, I fixed all instances of data+plural. > > Thanks for the English lesson... ;-) Being a second language, at times > it gets tricky.... > > P.S.: I've posted a rev that fixes this. It should be ready to ship. > > 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 > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From kojo@cs.helsinki.fi Thu Mar 11 08:10:07 2010 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 988463A6986 for ; Thu, 11 Mar 2010 08:10:07 -0800 (PST) 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 HEgTHR5ZGI4n for ; Thu, 11 Mar 2010 08:10:06 -0800 (PST) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE213A6B85 for ; Thu, 11 Mar 2010 08:09:25 -0800 (PST) Received: from tx3-4.cs.helsinki.fi (tx3-4.cs.helsinki.fi [128.214.9.172]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 11 Mar 2010 18:09:29 +0200 id 00093E9A.4B9915B9.00006B75 Received: by tx3-4.cs.helsinki.fi (Postfix, from userid 3011) id 1FA5C24A01; Thu, 11 Mar 2010 18:09:37 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by tx3-4.cs.helsinki.fi (Postfix) with ESMTP id 0B5C02412F; Thu, 11 Mar 2010 18:09:36 +0200 (EET) Date: Thu, 11 Mar 2010 18:09:36 +0200 (EET) From: Markku Kojo To: tcpm@ietf.org In-Reply-To: <20100308153002.389B73A69B4@core3.amsl.com> Message-ID: References: <20100308153002.389B73A69B4@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-sack-recovery-entry-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: Thu, 11 Mar 2010 16:10:07 -0000 Hi, all, we would appreciate any feedback on the new version of the draft. We as the authors believe that the document is technically ready, so it would probably be time to take the next steps. As a part of this we have discussed with the RFC 3517 authors and are planning to merge this document together with RFC 3517. This would allow us to concentrate a bit the split TCP documentation. Any views on this plan are also welcome. /Markku On Mon, 8 Mar 2010, Internet-Drafts@ietf.org wrote: > 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 : Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation > Author(s) : I. Jarvinen, M. Kojo > Filename : draft-ietf-tcpm-sack-recovery-entry-01.txt > Pages : 18 > Date : 2010-03-08 > > This document describes a TCP sender algorithm to trigger loss > recovery based on the TCP Selective Acknowledgement (SACK) > information gathered on a SACK scoreboard instead of simply counting > the number of arriving duplicate acknowledgements (ACKs) 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-sack-recovery-entry-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 Fri Mar 12 02:38:47 2010 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 2482B3A6890 for ; Fri, 12 Mar 2010 02:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[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 w9X0PAFXcweA for ; Fri, 12 Mar 2010 02:38:45 -0800 (PST) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 373253A65A6 for ; Fri, 12 Mar 2010 02:38:44 -0800 (PST) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id A8AD557BAE; Fri, 12 Mar 2010 11:38:49 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Fri, 12 Mar 2010 11:38:29 +0100 From: Alexander Zimmermann To: Markku Kojo Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-sack-recovery-entry-01.txt Thread-Index: AQHKvtRjJOBlaf/YA0SXWI/zC38EupHs3BAAgAE154A= Date: Fri, 12 Mar 2010 10:38:47 +0000 Message-ID: <79867E45-9FC0-430F-9316-BBC006959AD1@nets.rwth-aachen.de> References: <20100308153002.389B73A69B4@core3.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <387269dd-0166-4783-a668-1f1699662cb1> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-sack-recovery-entry-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: Fri, 12 Mar 2010 10:38:47 -0000 Am 11.03.2010 um 17:09 schrieb Markku Kojo: > Hi, all, >=20 > we would appreciate any feedback on the new version of the draft.=20 >=20 > We as the authors believe that the document is technically ready, so it=20 > would probably be time to take the next steps. As a part of this we have= =20 > discussed with the RFC 3517 authors and are planning to merge this=20 > document together with RFC 3517. Nice! > This would allow us to concentrate > a bit the split TCP documentation. Yes. I second that. > Any views on this plan are also=20 > welcome.=20 >=20 > /Markku >=20 >=20 > On Mon, 8 Mar 2010, Internet-Drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the TCP Maintenance and Minor Extensions Wo= rking Group of the IETF. >>=20 >>=20 >> Title : Using TCP Selective Acknowledgement (SACK) Informatio= n to Determine Duplicate Acknowledgements for Loss Recovery Initiation >> Author(s) : I. Jarvinen, M. Kojo >> Filename : draft-ietf-tcpm-sack-recovery-entry-01.txt >> Pages : 18 >> Date : 2010-03-08 >>=20 >> This document describes a TCP sender algorithm to trigger loss >> recovery based on the TCP Selective Acknowledgement (SACK) >> information gathered on a SACK scoreboard instead of simply counting >> the number of arriving duplicate acknowledgements (ACKs) 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. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-sack-recovery-entry-= 01.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Fri Mar 12 11:04:33 2010 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 EF08C3A68C5 for ; Fri, 12 Mar 2010 11:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 qcBFY7xWnSAT for ; Fri, 12 Mar 2010 11:04:32 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id F24813A68B4 for ; Fri, 12 Mar 2010 11:04:31 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 95D116B6A86; Fri, 12 Mar 2010 16:04:39 -0300 (ART) Received: from [192.168.2.184] (182.76.92-79.rev.gaoland.net [79.92.76.182] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2CJ4TYk009649; Fri, 12 Mar 2010 16:04:33 -0300 Message-ID: <4B99CA9C.9070807@gont.com.ar> Date: Fri, 12 Mar 2010 02:01:16 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.96.0 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, 12 Mar 2010 16:04:39 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security (more time to comment!) 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, 12 Mar 2010 19:04:33 -0000 Folks, Some of you had expressed interest in providing feedback on the aforementioned I-D. However, so far only a one person (Wes) has sent feedback. Given that more comments are needed, and that the last few weeks have probably been particularly busy (IETF I-D submission cut-off's), we have extended the period of time to send comments on draft-ietf-tcpm-tcp-security-01.txt (http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt). I'm requesting feedback on all the sections through Section 3.1.2.3. -- this includes the introduction sections, the basic check on the TCP segment size (Section 3) and the discussion of port numbers (Section 3.1 with all its subsections). Please review these sections and submit comments by Monday March 22nd, 2010, so that we can move on to the next sections in a timely manner. 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 mallman@icir.org Mon Mar 15 13:59:28 2010 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 2EF023A6895 for ; Mon, 15 Mar 2010 13:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.158 X-Spam-Level: X-Spam-Status: No, score=-5.158 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, 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 AUZrk559TZ6z for ; Mon, 15 Mar 2010 13:59:24 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 706613A67EA for ; Mon, 15 Mar 2010 13:59:24 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVR2004710; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 0B9A1B2049A; Mon, 15 Mar 2010 11:22:30 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4B69B030.3000508@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20661-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:22:30 -0400 Sender: mallman@icir.org Message-Id: <20100315152230.0B9A1B2049A@lawyers.icir.org> Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 20:59:28 -0000 ----------ma20661-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [These are re-sends from long ago... they never made it to the list. But, that seems to have been worked out, now. --allman] > Making TCP smarter is fine; doing so at the expense of robustness is > not. I'll agree with this and push back at the same time. I agree that robustness is important and should be protected. However, I have increasingly come to view things like initial RTOs and initial cwnds, and etc. as not buying us much robustness. What buys us robustness is the reaction---any reaction---to indications there might be problems. These gross notions are more important than any small parameter change it seems to me. allman ----------ma20661-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueULUACgkQWyrrWs4yIs52pQCcCAugUrUZ6yK4MqhuYx3A+rlG nc0AoJcQuO2uBfRNGbFwnGP7pwAzw+qc =VMRX -----END PGP SIGNATURE----- ----------ma20661-1-- From mallman@icir.org Mon Mar 15 14:09:09 2010 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 43B5D3A6965 for ; Mon, 15 Mar 2010 14:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_40=-0.185, DATE_IN_PAST_03_06=0.044, 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 xUYFIQAw4Var for ; Mon, 15 Mar 2010 14:09:08 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 998793A6BE8 for ; Mon, 15 Mar 2010 14:09:04 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVO1004720 for ; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 59ECAB20596 for ; Mon, 15 Mar 2010 11:31:17 -0400 (EDT) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma21189-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:31:17 -0400 Sender: mallman@icir.org Message-Id: <20100315153117.59ECAB20596@lawyers.icir.org> Subject: [tcpm] initial RTO change ? 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, 15 Mar 2010 21:09:09 -0000 ----------ma21189-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline As alluded to previously, we (== Vern Paxson, Jerry Chu and I) recently put out an I-D for a possible 2988bis that represents only a small change from RFC2988. It is draft-paxson-tcpm-rfc2988bis-00.txt. The proposed change is to reduce the initial RTO from 3 seconds to 1 second. A few notes: - If there is loss detected before an RTT sample is obtained (i.e., using the 1sec RTO) then the RTO is backed off per usual. But, in addition, the data transmission starts by using the old 3sec value to be conservative and to not let an RTO in the 3WHS impact data transfer. (An RTO in the 3WHS does force the sender to use an initial cwnd of 1 segment, so there is some potential impact for being more aggressive.) - It seems the real danger here is in strobing one or two extra SYNs into the network---not a big deal in our judgment. - The changes are quite modest. We added an appendix that explains the thinking, but the in-line changes are small and given below. We'd appreciate feedback on whether the WG thinks this is a good idea or not. Many thanks! allman @@ -92,17 +92,24 @@ Abstract (2.1) Until a round-trip time (RTT) measurement has been made for a segment sent between the sender and receiver, the sender SHOULD - set RTO <- 3 seconds (per RFC 1122 [Bra89]), though the - "backing off" on repeated retransmission discussed in (5.5) - still applies. - - Note that some implementations may use a "heartbeat" timer - that in fact yield a value between 2.5 seconds and 3 - seconds. Accordingly, a lower bound of 2.5 seconds is also - acceptable, providing that the timer will never expire - faster than 2.5 seconds. Implementations using a heartbeat - timer with a granularity of G SHOULD not set the timer below - 2.5 + G seconds. + set RTO <- 1 second, though the "backing off" on repeated + retransmission discussed in (5.5) still applies. + + Note that the previous version of this document used an + initial RTO of 3 seconds [RFC2988]. A TCP implementation MAY + still use this value (or any other value > 1 second). This + change in the lower bound on the initial RTO is discussed in + further detail in Appendix A. (2.2) When the first RTT measurement R is made, the host MUST set @@ -222,6 +229,14 @@ Abstract seconds (for the value of RTO after the doubling operation outlined in 5.5). + (5.7) If the timer expires awaiting the ACK of a SYN segment and the + TCP implementation is using an RTO less than 3 seconds, the RTO + MUST be re-initialized to 3 seconds when data transmission + begins (i.e., after the three-way handshake completes). + + This represents a change from the previous version of this + document [RFC2988] and is discussed in Appendix A. + Note that after retransmitting, once a new RTT measurement is obtained (which can only happen when new data has been sent and acknowledged), the computations outlined in section 2 are performed, ----------ma21189-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueUsUACgkQWyrrWs4yIs4xUQCfebMwHgAt2ATK6MgJxnFe5efW RakAnAyHXuZoUQF08+4UQDJTjBkbGVva =8k0/ -----END PGP SIGNATURE----- ----------ma21189-1-- From mallman@icir.org Mon Mar 15 14:16:44 2010 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 F3CB13A6824 for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 6s-QIRlLBJVV for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 2DDD43A6407 for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVQ3004712; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 33B98B204BA; Mon, 15 Mar 2010 11:22:44 -0400 (EDT) To: John Heffner From: Mark Allman In-Reply-To: <1e41a3231002031251v53f03f78x2ba6a12c4f12a22@mail.gmail.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20675-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:22:44 -0400 Sender: mallman@icir.org Message-Id: <20100315152244.33B98B204BA@lawyers.icir.org> Cc: "tcpm@ietf.org WG" Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 21:16:44 -0000 ----------ma20675-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [These are re-sends from long ago... they never made it to the list. But, that seems to have been worked out, now. --allman] > I think you need a negotiation for > opt-in rather than opt-out. If you want to negotiate an initial window then define a riff on Quick-Start that doesn't require help from the routers. But, that feels like too much here ... - If the receiver is the problem then even overwhelming it with a larger initial burst doesn't hurt the shared network much. - On the order of 10 packets it seems hard to believe that we're really going to overwhelm any even moderately recent end system. - If it isn't the end system we're worried about then the receiver is acting as a proxy for something in the middle. And, so ... + How good will the receiver be able to achieve this? + If it is really a problem then you probably want something like Quick-Start to actually engage the path in the decision. I helped write Quick-Start so don't get me wrong here.... perhaps there is a need to get into all this mechanism if you want to send Really Fast. But, it seems that we should be able to have some initial value that can be used without consent that will not cause issues high quite high probability. And, 'network inflation' would likely mean that number should increase over time. allman ----------ma20675-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueUMMACgkQWyrrWs4yIs5vbwCdFFNQjrfAFXBmT0ofgFz2oyM9 DikAn2vNV/bbvKsZhjm4thVfsVkWY+y9 =Xt9+ -----END PGP SIGNATURE----- ----------ma20675-1-- From mallman@icir.org Mon Mar 15 14:16:44 2010 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 BD48A3A6824 for ; Mon, 15 Mar 2010 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 8aBvpYSYIAM4 for ; Mon, 15 Mar 2010 14:16:44 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 473383A67B0 for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVGc004729; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 95361B204C9; Mon, 15 Mar 2010 11:22:48 -0400 (EDT) To: "Biswas, Anumita" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20680-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:22:48 -0400 Sender: mallman@icir.org Message-Id: <20100315152248.95361B204C9@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 21:16:44 -0000 ----------ma20680-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [These are re-sends from long ago... they never made it to the list. But, that seems to have been worked out, now. --allman] > I have seen cases where switches topple over initial receive window > sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the > recommended IW value of 4 segments for 1500MSS can cause more loss in > networks with higher segment drop rates. But, that is an old number. We have to be careful with anecdotes here. I.e., just because we know of some thing-a-ma-bob that will have problems with RFC5681 initial windows does not mean we shouldn't increase the initial window. We should not engineer for the ratty edge cases. allman ----------ma20680-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueUMgACgkQWyrrWs4yIs7WPQCeJag7gCccgkoMx/mo+UFCQjSX B6AAn2p2ymAVcjC1bmMTdqjdBdzJfH+N =W6Tf -----END PGP SIGNATURE----- ----------ma20680-1-- From mallman@icir.org Mon Mar 15 14:16:45 2010 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 E65543A69A9 for ; Mon, 15 Mar 2010 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.387 X-Spam-Level: X-Spam-Status: No, score=-5.387 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044, 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 Veie+V4ZL-J0 for ; Mon, 15 Mar 2010 14:16:44 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 566CD3A680C for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxVcI004734; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id A91BFB204A9; Mon, 15 Mar 2010 11:22:37 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4B74358B.90804@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20669-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:22:37 -0400 Sender: mallman@icir.org Message-Id: <20100315152237.A91BFB204A9@lawyers.icir.org> Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 21:16:46 -0000 ----------ma20669-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [These are re-sends from long ago... they never made it to the list. But, that seems to have been worked out, now. --allman] > We do need to be careful that whatever we do doesn't overwhelm these > assumptions and change the game, however. Agreed. > Regarding init cwnds, I'd like to see a reasonable level of analysis > of the impact. Yep. I wasn't trying to say we'd just make a WAG. Certainly we'd want to see an assessment. That said, personally, I have a lower bar for letting this sort of thing through than perhaps I have had in the past. (I think the initial window argument about most transfers being small is compelling. But, I wrote a paper (**not IETF proposal**) with some colleagues a couple of years ago [*,**] that wondered about just getting rid of slow start. There are some meager simulations, but also some simple arguments as to why this might not be an awful approach.) > It's not enough to drive discussions with "we have to RIGHT NOW!" to > satisfy a (often underinformed) perception of need. Absolutely. allman [*] Dan Liu, Mark Allman, Shudong Jin, Limin Wang. Congestion Control Without a Startup Phase. Protocols for Fast, Long Distance Networks (PFLDnet) Workshop, February 2007. http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf [**] The related story is that this paper was the start of my undo-ing as TCPM co-chair as Lars' comment after seeing the paper at PFLDnet was something like "can we really have such a whack job chairing TCPM?". [***] [***] OK, OK. While I recall Lars making this comment, I have no evidence that it was my downfall at all. Especially since I voluntarily resigned. Um, I think I did, anyway. :) ----------ma20669-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueUL0ACgkQWyrrWs4yIs53HACfUbG1f+5h0MyxsOjAZBR6TgI0 nzMAmwVoG8bcpEBn0gQ/cxR2U9OG/ATB =2/ri -----END PGP SIGNATURE----- ----------ma20669-1-- From mallman@icir.org Mon Mar 15 14:16:46 2010 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 C50C73A6B8D for ; Mon, 15 Mar 2010 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 Ru62qNTDEKfr for ; Mon, 15 Mar 2010 14:16:45 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6F06B3A6821 for ; Mon, 15 Mar 2010 14:16:43 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2FKxV16004735; Mon, 15 Mar 2010 13:59:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D471DB20488; Mon, 15 Mar 2010 11:22:18 -0400 (EDT) To: "Biswas, Anumita" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: In the City MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma20650-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 15 Mar 2010 11:22:18 -0400 Sender: mallman@icir.org Message-Id: <20100315152218.D471DB20488@lawyers.icir.org> Cc: tcpm@ietf.org, Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 21:16:46 -0000 ----------ma20650-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [These are re-sends from long ago... they never made it to the list. But, that seems to have been worked out, now. --allman] > " (2.4) Whenever RTO is computed, if it is less than 1 second then the > RTO SHOULD be rounded up to 1 second. > > Traditionally, TCP implementations use coarse grain clocks to > measure the RTT and trigger the RTO, which imposes a large > minimum value on the RTO. Research suggests that a large > minimum RTO is needed to keep TCP conservative and avoid > spurious retransmissions [AP99]. Therefore, this > specification requires a large minimum RTO as a conservative > approach, while at the same time acknowledging that at some > future point, research may show that a smaller minimum RTO is > acceptable or superior." > > Is it time to reconsider a smaller minimum RTO as well? One problem with the minimum is we don't know what to set it at [*]. The finding in [AP99] is that as you reduce the min you take more spurious timeouts. The tradeoff seemed fundamental to us. But, given our methodology (trace driven simulation) we could not really tell the impact of the spurious timeouts. So, we just sought to minimize them in the spec. I know some TCP implementations are being pretty aggressive with the min these days. But, it is not at all clear to me whether this is a net win or net lose. I.e., is the win in terms of peppiness to needed retransmits still a win when it is played against the consequences of a spurious transmit (i.e., setting cwnd = 1)? Perhaps there is a sweet spot that is < 1sec whereby this tradeoff better balances and we should be using that. But, it'd take a big experiment to show that, I think. [*] Maybe there is work that I just don't know about and if so I'd like to be pointed at it. Another thing I have wondered about from time to time .... Much like Early Retransmit could we have some sort of early RTO when the cwnd size is small? When the window size is small it seems that the downside of making a bad rexmt decision is not as bad as when the cwnd is large so it might pay in terms of responsiveness to RTO sooner. Also, as the cwnd gets larger we have better loss recovery techniques that should come into play that can repair lots of loss without involving the RTO and so perhaps by being overly aggressive in the RTO we just hurt ourselves. Finally, as the cwnd gets bigger that means we are transferring more data. And, the longer a connection goes the less important the fine-grained responsiveness matters. Just a random thought ... allman ----------ma20650-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkueUKoACgkQWyrrWs4yIs7YJgCcCxkKFXqQ5w7gw7ZgnUYYGgP4 tQoAmgMKo5riKfT4qiYskwP+WrFM6kFZ =wdrv -----END PGP SIGNATURE----- ----------ma20650-1-- From touch@ISI.EDU Mon Mar 15 14:27:18 2010 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 002E13A6818 for ; Mon, 15 Mar 2010 14:27:18 -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 kUmKkEZ1LzJF for ; Mon, 15 Mar 2010 14:27:16 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id CA1753A680C for ; Mon, 15 Mar 2010 14:27:16 -0700 (PDT) Received: from [128.9.176.76] (c3-vpn5.isi.edu [128.9.176.76] (may be forged)) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2FLPcwu011139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Mar 2010 14:25:40 -0700 (PDT) Message-ID: <4B9EA5D0.8030100@isi.edu> Date: Mon, 15 Mar 2010 14:25:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20100315152230.0B9A1B2049A@lawyers.icir.org> In-Reply-To: <20100315152230.0B9A1B2049A@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5FA90B13A851CCE23BD1DC48" X-MailScanner-ID: o2FLPcwu011139 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Kacheong Poon , Michael Welzl Subject: Re: [tcpm] TCP tuning 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, 15 Mar 2010 21:27:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5FA90B13A851CCE23BD1DC48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > [These are re-sends from long ago... they never made it to the list. > But, that seems to have been worked out, now. --allman] >=20 >> Making TCP smarter is fine; doing so at the expense of robustness is >> not.=20 >=20 > I'll agree with this and push back at the same time. I agree that > robustness is important and should be protected. However, I have > increasingly come to view things like initial RTOs and initial cwnds, > and etc. as not buying us much robustness. What buys us robustness is > the reaction---any reaction---to indications there might be problems. > These gross notions are more important than any small parameter change > it seems to me. That may be true for initializations of parameters that have ongoing tuning, but not all parameters have that property. Further, the group behavior of changing these parameters is of concern too. The following paper is a good example of "it won't hurt because we tune", but it *can* hurt: http://www.computer.org/portal/web/csdl/doi/10.1109/ICNP.1997.643715 Joe --------------enig5FA90B13A851CCE23BD1DC48 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuepdAACgkQE5f5cImnZrs5wACgqrjGePx+ROzIeUAW0MDI71sH 5tIAoNRS6wM6ogBf2xHAgVkYvdNPwkkn =QCtY -----END PGP SIGNATURE----- --------------enig5FA90B13A851CCE23BD1DC48-- From mallman@icir.org Tue Mar 16 06:55:04 2010 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 330563A6929 for ; Tue, 16 Mar 2010 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 U7iwNyVJn70W for ; Tue, 16 Mar 2010 06:55:03 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3DAD23A6863 for ; Tue, 16 Mar 2010 06:55:03 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2GDsDe9009898; Tue, 16 Mar 2010 06:54:13 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 660B0B3015E; Tue, 16 Mar 2010 09:54:13 -0400 (EDT) To: RFC Errata System From: Mark Allman In-Reply-To: <20100316030948.167F0E0740@rfc-editor.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Pretty Noose MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma36226-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 16 Mar 2010 09:54:13 -0400 Sender: mallman@icir.org Message-Id: <20100316135413.660B0B3015E@lawyers.icir.org> Cc: tcpm@ietf.org, david.borman@windriver.com, vern@icir.org, eblanton@cs.purdue.edu, weddy@grc.nasa.gov, Herbie.Robinson@stratus.com Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (2074) 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: Tue, 16 Mar 2010 13:55:04 -0000 ----------ma36226-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > The following errata report has been submitted for RFC5681, > "TCP Congestion Control". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=2074 > > -------------------------------------- > Type: Editorial > Reported by: Herbie Robinson > > Section: 3.1 > > Original Text > ------------- > A detailed rationale and discussion of the IW setting is provided in > [RFC3390]. > > > Corrected Text > -------------- > A detailed rationale and discussion of the IW setting is provided > in [RFC3390]. The IW value for the case when (SMSS > 1095 bytes) > and (SMSS <= 2190 bytes) is changed from RFC3390. The new > definition will keep early values of cwnd at a multiple of SMSS and > avoid transmitting partial segments. > > > Notes > ----- > Hopefully, I surmised the reason for the change correctly. You did not surmise correctly. There is a very slight discrepancy between the two documents when the SMSS == 2190 bytes. RFC3390 says to use an initial window of 2*SMSS, whereas RFC5681 says to use an initial window of 3*SMSS. This is nothing but a bug---a <= where there should have been a < and a > where there should have been a >=. So, the corrected text is not right. We could say something like: A detailed rationale and discussion of the IW setting is provided in [RFC3390]. (Note: When SMSS is 2190 bytes the table in RFC 5681 says to use an IW of 3*SMSS, while RFC 3390 says to use an IW of 2*SMSS. This is an off-by-one error in RFC 5681 and the intended IW is 2*SMSS, per RFC 3390.) Or, we could just forget it as a harmless bug. allman ----------ma36226-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkufjYQACgkQWyrrWs4yIs4bdACfZjCmzP/IWQSPkZtIlrNj6VFY RlsAoIxWLPbBk+j/6hvbc4xCwhIM+Kj3 =QMYV -----END PGP SIGNATURE----- ----------ma36226-1-- From wwwrun@rfc-editor.org Mon Mar 15 20:09:41 2010 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 4F6E93A68EC for ; Mon, 15 Mar 2010 20:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-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 9hrZq6SZb0Ly for ; Mon, 15 Mar 2010 20:09:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 47D453A686E for ; Mon, 15 Mar 2010 20:09:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 167F0E0740; Mon, 15 Mar 2010 20:09:48 -0700 (PDT) To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu, magnus.westerlund@ericsson.com, lars.eggert@nokia.com, weddy@grc.nasa.gov, david.borman@windriver.com From: RFC Errata System Message-Id: <20100316030948.167F0E0740@rfc-editor.org> Date: Mon, 15 Mar 2010 20:09:48 -0700 (PDT) X-Mailman-Approved-At: Thu, 18 Mar 2010 08:53:56 -0700 Cc: rfc-editor@rfc-editor.org, tcpm@ietf.org, Herbie.Robinson@stratus.com Subject: [tcpm] [Editorial Errata Reported] RFC5681 (2074) 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, 16 Mar 2010 03:09:41 -0000 The following errata report has been submitted for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=2074 -------------------------------------- Type: Editorial Reported by: Herbie Robinson Section: 3.1 Original Text ------------- A detailed rationale and discussion of the IW setting is provided in [RFC3390]. Corrected Text -------------- A detailed rationale and discussion of the IW setting is provided in [RFC3390]. The IW value for the case when (SMSS > 1095 bytes) and (SMSS <= 2190 bytes) is changed from RFC3390. The new definition will keep early values of cwnd at a multiple of SMSS and avoid transmitting partial segments. Notes ----- Hopefully, I surmised the reason for the change correctly. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From wesley.m.eddy@nasa.gov Thu Mar 18 13:09:13 2010 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 64AF63A67AB for ; Thu, 18 Mar 2010 13:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.676 X-Spam-Level: X-Spam-Status: No, score=-4.676 tagged_above=-999 required=5 tests=[AWL=-1.807, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 3QTJ9MxSBd8p for ; Thu, 18 Mar 2010 13:09:11 -0700 (PDT) Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 92E883A67B2 for ; Thu, 18 Mar 2010 13:09:06 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 7DDDD2607C2 for ; Thu, 18 Mar 2010 15:09:18 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o2IK85qm018654 for ; Thu, 18 Mar 2010 15:09:17 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Thu, 18 Mar 2010 15:08:47 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Thu, 18 Mar 2010 15:08:46 -0500 Thread-Topic: WG status update Thread-Index: AcrG1tC3Xjt+W8WBRw+rnqtKerJx8w== 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.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-03-18_13:2010-02-06, 2010-03-18, 2010-03-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: Thu, 18 Mar 2010 20:09:13 -0000 Hello TCPM, going into the Anaheim meeting, here's a brief snapshot of the WG status as we know it. ***Please note that there are two drafts under poll for becoming WG items, and very few responses have been received on these. Any feedback will be useful.*** WG Items Nearing RFC Publication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Early-Retransmit http://www.ietf.org/id/draft-ietf-tcpm-early-rexmt-04.txt Milestone Target: Experimental in July 2009 Status: In RFC Editor's queue Action: None in TCPM ICMP Attacks http://www.ietf.org/id/draft-ietf-tcpm-icmp-attacks-11.txt Milestone Target: Informational in July 2009 Status: finished IETF LC, with IESG Action: None in TCPM TCP Authentication Option http://www.ietf.org/id/draft-ietf-tcpm-tcp-auth-opt-10.txt Milestone Target: Proposed Standard in April 2009 Status: sent to IESG Action: None in TCPM; authors resolving IESG issues TCP Authentication Option Crypto http://www.ietf.org/id/draft-ietf-tcpm-tcp-ao-crypto-01.txt Milestone Target: Proposed Standard with AO spec Status: sent to IESG Action: None in TCPM; authors resolving IESG issues WG Items in WGLC or being revised after WGLC =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Urgent Pointer http://www.ietf.org/id/draft-ietf-tcpm-urgent-data-05.txt Milestone Target: Proposed Standard in January 2010 Status: updated after WGLC Action: chairs (David) writing PROTO for sending to IESG MSS Option http://www.ietf.org/id/draft-ietf-tcpm-tcpmss-02.txt Milestone Target: Proposed Standard in July 2009 Status: WGLC started 8/19, ended 9/8 (extended) Action: being updated based on several of the comments (action with D. Borm= an) needs another WGLC after being revised Active WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1323bis http://www.ietf.org/id/draft-ietf-tcpm-1323bis-01.txt Milestone Target: Proposed Standard in July 2009 Status: Needs revision Action: Revise & WGLC (action with D. Borman) TCP Security http://www.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt Milestone Target: BCP in August 2010 Status: outline discussion dying off? content needs work Action: 00-draft / outline has been under active discussion; but not attain= ed very clear consensus WG has begun working on recommendations while still looking for a possible compromise on outline (action with Fernando Gont) Long Connectivity Disruptions http://www.ietf.org/id/draft-ietf-tcpm-tcp-lcd-00.txt (need to submit WG version) Milestone Target: Experimental in October 2010 Status: sumbitted as initial WG document; authors think no real issues are = left Action: need WG to read/discuss; may be close to ready for last call SACK Entry http://www.ietf.org/id/draft-ietf-tcpm-sack-recovery-entry-01.txt Milestone Target: Proposed Standard in October 2010 Action: need WG to read/discuss discussion underway of working on this as update to 3517 Documents Under a Poll to Become WG Items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Clarification of sender behavior in persist condition. http://tools.ietf.org/id/draft-ananth-tcpm-persist-01.txt Status: discussed on mailing list and in face-to-face meetings WG poll opened on March 8 Action: Need responses from WG if this is to be supported Timestamps http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-01.txt Status: discussed on mailing list and at Minneapolis meeting WG poll opened on March 8 Action: Need responses from WG if this is to be supported Other Proposals Not Yet Decided On =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D NewReno Modification http://www.ietf.org/internet-drafts/draft-nishida-newreno-modification-01.t= xt Action: need WG to read/discuss presentation given, document updated, but WG list not yet polled fo= r adoption AO NAT http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-nat-00.txt Action: WG review/discuss issues raised by Eric Rescorla; to be considered as a potential update to the AO spec AFTER the base AO spec is published AO Rekeying http://tools.ietf.org/id/draft-duan-tcpm-tcp-ao-rekeying-00.txt Action: WG to discuss (Anaheim & mailing list) Increasing TCP's Initial Window http://tools.ietf.org/html/draft-hkchu-tcpm-initcwnd-00 Action: WG to discuss (Anaheim & mailing list) Computing TCP's Retransmission Timer http://tools.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt Action: WG to discuss (Anaheim & mailing list) Older & Expired Documents Discussed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D discussions on Rate-Halving http://tools.ietf.org/id/draft-mathis-tcp-ratehalving-00.txt Action: mailing list discussion about the history of this, and whether it needs to be revived Faster Application Handshakes with SYN/ACK Payloads expired draft-agl-tcpm-sadata-01 Status: expired; not specifically polled for adoption in WG Documents Not Adopted by WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D TCP Option for Transparent Middlebox Discovery http://www.ietf.org/id/draft-knutsen-tcpm-middlebox-discovery-03.txt Status: discussed on mailing list and updated in response poll for working group adoption opened on 12/9, responses desired by 12/23 decision not to adopt by WG; IESG may allow publication and option number assignment at their discretion, but TCPM does not have consensus to do this work Other WG Activities =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Errata Review for legacy TCP RFCs: RFC0793 (1496) 3.9 Technical Legacy Yin Shuming 2008-08-27 RFC0793 (1561) 3.2 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1562) 3.3 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1563) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1564) 3.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1565) 3.8 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1566) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1567) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1568) 3.9 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1569) 2.4 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1570) 2.7 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1571) 3.1 Technical Legacy Constantin Hagemeier 2008-10-11 RFC0793 (1572) 3.4 Technical Legacy Constantin Hagemeier 2008-10-11 -- Wes Eddy MTI Systems From nwnetworks@dial.pipex.com Sat Mar 20 14:35:52 2010 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 996593A6885 for ; Sat, 20 Mar 2010 14:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.731 X-Spam-Level: * X-Spam-Status: No, score=1.731 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_62=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 WUBKa4q8zPmi for ; Sat, 20 Mar 2010 14:35:51 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 63CF53A6407 for ; Sat, 20 Mar 2010 14:35:51 -0700 (PDT) X-Trace: 192833024/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.183/None/nwnetworks@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.183 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosHACbcpEs+vGm3/2dsb2JhbACBeIERhEmJEotNqwuQEw2BH4JnagQ X-IronPort-AV: E=Sophos;i="4.51,279,1267401600"; d="scan'208";a="192833024" X-IP-Direction: IN Received: from 1cust183.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.183]) by smtp.pipex.tiscali.co.uk with SMTP; 20 Mar 2010 21:36:04 +0000 Message-ID: <002601cac86c$bfa894c0$0601a8c0@allison> From: "Tom Petch" To: "tcpm" Date: Sat, 20 Mar 2010 21:26:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [tcpm] WG survey X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 21:35:52 -0000 From: "Laganier, Julien" To: Sent: Wednesday, March 03, 2010 7:20 PM Subject: [btns] FW: request for help in developing a tool that may be helpful to WG chairs > -----Original Message----- > From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of Scott O. Bradner > Sent: Wednesday, March 03, 2010 7:36 AM > To: wgchairs@ietf.org > Subject: request for help in developing a tool that may be helpful to WG chairs > > IETF working group chairs; > > We are developing an open-source tool for monitoring the status and > progress of conflicts in on-line working groups (WG). The tool works by > analyzing the WG mailing list. When developed, this tool should be > helpful to WG chairs trying to understand the status of WG discussions > (how close to consensus is the WG, what is the distribution of > participation, etc). > > As part of the development process we have been using a prototype tool > to analyze IETF WG mailing list archives to determine the amount of > conflict and how effective this conflict is being (has been) resolved. > As the first step, we need to understand the relationship between the > conflicts in a working group and the structure of the communication > network in that group. While having conflicts is not necessarily a bad > thing for a working group effort, some conflicts can escalate into > disasters. We are interested in finding the communication patterns > related to the evolution of group conflicts. Results from this study > will provide the base for the development of the tool that helps working > group chairs to decide when to intervene with an internal conflict > before it becomes irreversibly negative as well as being a tool that may > help determine where there is consensus on a particular topic. > > We would like your help in understanding the level of conflicts within > your working groups and how the conflicts affect productivity and group > members’ perception on the working group. It will be greatly appreciated > if you could ask your WG members to anonymously fill a short survey at > > https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQUVR4b zBGMEE6MA I received this e-mail on another list and thought that some might see a use for it in relation to the TCPM WG. I am assured by WG Chairs that the intention is for all lists to get it and respond to it. I have only seen it elsewhere and assume that, since I use the same mail address for several lists, the IETF Mail system is suppressing "duplicate" e-mails. Like all surveys, the more representative it is of differing views, the more useful it is so I encourage the other 404 of you to participate. I have filled it in but have not found it easy; its model of a WG's work is different to mine. It wants to know about the first task of a WG, what it is - process related, protocol development etc -, when it started, when it finished, how many intermediate documents there were, how many documents it produced before going to how many people were involved, inside and outside of the IETF, whether they were good to work with, whether or not you would want to work with them again and so on. I turned back to the TCPM charter from February 2004 to reassure myself that some of what it asks does not make sense. There appears to be no background information or guidance apart from the e-mail I forward, nor any way to add comments to the effect that this question is dumb. Knowing that you regard the TCPM list as sweetness and light is as valuable as knowing that you do not so I would encourage you to fill it in. Tom Petch (an assiduous follower of but only an occasional contributor to this list) > Best Regards, > > Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin > From ekr@rtfm.com Sat Mar 20 17:28:42 2010 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 26F963A6832 for ; Sat, 20 Mar 2010 17:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.852 X-Spam-Level: * X-Spam-Status: No, score=1.852 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] 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 M6tVP38ut+CV for ; Sat, 20 Mar 2010 17:28:41 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 179043A6767 for ; Sat, 20 Mar 2010 17:28:41 -0700 (PDT) Received: by gwaa11 with SMTP id a11so920837gwa.31 for ; Sat, 20 Mar 2010 17:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.40.17 with SMTP id n17mr2528204agn.3.1269131332692; Sat, 20 Mar 2010 17:28:52 -0700 (PDT) Date: Sat, 20 Mar 2010 17:28:52 -0700 Message-ID: From: Eric Rescorla To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [tcpm] Review of draft-duan-tcpm-tcp-ao-rekeying-00 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, 21 Mar 2010 00:28:42 -0000 $Id: draft-duan-tcpm-tcp-ao-rekeying-00-rev.txt 112 2010-03-21 00:28:12Z ekr $ In TCP-AO a receiver can signal that it is ready to receive authenticated packets using a new key, but it cannot signal that it wishes to send with a new key. This draft describes a mechanism to provide that signaling. It's unclear to me what benefit this draft provides. The basic principle behind TCP-AO is that key changes are coordinated between the sides: a new key cannot be used until it is known by both endpoints. At the time when that key is established, the establishment process (likely a phone call or email) can indicate that the new key is preferred, in which case both sides will start advertising the ability to receive it as soon as it is installed. Thus, this mechanism is unnecessary. The authors argue that: the RNextKeyID MKT when the RNextKeyID MKT is ready. It works well for changing the incoming key. However, if a sender finds its MKT which is used to authenticate outgoing segments has been attacked and should change into a new one, it can do nothing but has to wait for the receiver sending a segment which carries a different RNextKeyID. In this case, the communication becomes dangerous probably because the sender always authenticates outgoing segment by an attacked key before the receiver changes the incoming key. This paper proposes a method which the sender can trigger the other part to change the RNextKeyID when the sender finds the former outgoing key is not safe any longer. I don't find this convincing. If you know your key has been compromised you need to immediately notify your peers, who will want to promptly disable it. I don't see that any new protocol mechanisms are needed. Incidentally, the use of 0xff as a signal in the RNextKeyID field clearly violates S 4.2 of TCP-AO: o RNextKeyID: An unsigned 1-byte field indicating the MKT that the sender is ready use to receive authenticated segments, i.e., the desired 'receive next' keyID. It supports efficient key change coordination, to be discussed further in Section 8.1. Note that the RNextKeyID has no cryptographic properties - it need not be random, nor are there any reserved values. -Ekr From A.Hoenes@TR-Sys.de Sun Mar 21 14:55:59 2010 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 144E43A677D for ; Sun, 21 Mar 2010 14:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.844 X-Spam-Level: *** X-Spam-Status: No, score=3.844 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, 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 VEhMBcdFTf7B for ; Sun, 21 Mar 2010 14:55:58 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 441433A6824 for ; Sun, 21 Mar 2010 14:55:46 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA038008535; Sun, 21 Mar 2010 22:55:35 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA01238; Sun, 21 Mar 2010 22:55:34 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003212155.WAA01238@TR-Sys.de> To: tcpm@ietf.org Date: Sun, 21 Mar 2010 22:55:34 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 21 Mar 2010 21:55:59 -0000 Folks, I support adopting this short draft as a distinct work item for TCPM. Its brevity and the fact that major details already have been discussed in 2008, should allow a rapid progression. There are specific use cases of TCP that become more and more critical for the infrastructure of TCP/IP based internetworks; in particular DNS servers will become more and more dependable on robust TCP implementations that are able to handle a large load of rather short-lived connections. The improved TCP timestamp initialization procedure in draft-gont-tcpm-tcp-timestamps promises to become a useful component in advanced TCP implementations, as experience with open-source implementations already has shown. Therefore, IMO this recommendation is worth a standalone IETF document. I already did a detailed review of the -00 draft version and followed up to the -01. Somehow, I missed the -02, and it looks now like some of my comments on the -01 also have been missed. Thus, I now already have sent to the author a follow-up editorial review of the -03 covering my observations (mostly for sect. 1 and 2; some simply parallels to other documents in progress). If the WG adopts the draft, these details could well be fixed in the first WG version of the draft. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 nishida@sfc.wide.ad.jp Sun Mar 21 23:49:54 2010 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 76E4528C0E6 for ; Sun, 21 Mar 2010 23:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.557 X-Spam-Level: *** X-Spam-Status: No, score=3.557 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Ld86DWknFxgF for ; Sun, 21 Mar 2010 23:49:53 -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 00AA428C103 for ; Sun, 21 Mar 2010 23:48:19 -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 769974DE20; Mon, 22 Mar 2010 15:48:33 +0900 (JST) Date: Mon, 22 Mar 2010 15:48:33 +0900 (JST) Message-Id: <20100322.154833.183041911.nishida@sfc.wide.ad.jp> To: tcpm@ietf.org From: Yoshifumi Nishida In-Reply-To: References: <168921C8-87E9-4502-9DD5-119A71F15EF6@cs.ucl.ac.uk> 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 Cc: philip.eardley@bt.com Subject: Re: [tcpm] Multipath TCP signaling 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, 22 Mar 2010 06:49:54 -0000 Dear all, As Costin wrote in his mail, in multipath TCP working group, we are discussing signaling method for multipath TCP. On Tuesday, we're going to talk about this topic and see if we can reach consensue. We really appreciate if tcp experts give valuable feedbacks on this. Please come to California C at 15:20. It's right after tcpm meeting! Thanks, -- Phil and Yoshifumi From: Costin Raiciu Subject: [tcpm] Multipath TCP signaling Date: Wed, 24 Feb 2010 11:27:41 +0100 Message-ID: > Hi, > > In the multipath TCP working group we are trying to decide which is the best way to signal multipath specific information between endpoints. We are writing this message to invite contributions and thoughts from members of the tcpm list, as we believe that whatever solution we choose will impact other tcp signaling in the future. > > Let me briefly tell you what we are trying to do. > > Multipath works by assigning a data level sequence number to application data, and sending this data over different "subflows" which look like tcp over the wire. These subflows have their own sequence numbers too, on top of the data sequence number. > > The information multipath needs to get across is: > - multipath enabled / join connection - this is only on flow/subflow startup > - data sequence number (each segment must have this to enable the receiver to reorder data) > - add/remove ip to connection (not often) > - security negotiation, if needed > - subflow policy, etc. > > We have analyzed the requirements of this control information (e.g. reliable, in order) and two basic ways of signaling it: > - using TCP options - this is the traditional TCP way of signaling control information; it is unreliable and the space is limited, it will be a bit difficult to get it through existing middleboxes, but it plays nice with future "multipath aware" middleboxes. > - using the payload - this would use TLV like encoding (as in tls) and does not have space issues. However, all the control info is now ordered, congestion controlled and reliably sent - which may not be what we want. This will get through more middleboxes today, but it is not nice to future middleboxes: they have to keep state to be able to parse the control info. Also, the middleboxes cannot easily add control info (this is contentious, I know, but should be possible). > > The detailed analysis is in the following doc: http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf > > What do people think is the best approach? > Costin > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From hal.wigoda@gmail.com Mon Mar 22 00:52:14 2010 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 846E53A6A2F for ; Mon, 22 Mar 2010 00:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 EN6lv7B9pVBV for ; Mon, 22 Mar 2010 00:52:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7623C3A6A21 for ; Mon, 22 Mar 2010 00:52:13 -0700 (PDT) Received: by gyh4 with SMTP id 4so2690576gyh.31 for ; Mon, 22 Mar 2010 00:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-type:message-id:content-transfer-encoding:cc :from:subject:date:to:x-mailer; bh=gmWcfYht7SX9tH6SeFNlvqOYpu21gDE4uzINQlmrVQc=; b=p68kWKB85GgdUIfGJhSMPTXbXZsne0gE+6DsTUr5neDuQzcjDtv6bPAdwUR0pKy548 ybDcFdGfsnnbQ6GEz9/pW6RWkOl3R7eNCe7kaXvQ7U+gr0p6rU8/jtgcsuU0Iq5OgV5I uolCuhw97t5PqyPjPeDSmeheFfcJOqMvttd+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:from:subject:date:to:x-mailer; b=Kf3StMI8Aw3NLxWvBo419mxQjPVwiNXP9vb2u3ZKPT1xQKVl+n8utd1hfPScO4KTr4 OiVn7qo7dq9YH7nZ6a+fVFeLbGwZDpU8ILVfZ76yQyjaJxcD1B4vZ6oaFzbxFssMnFZj T9yna4Yor4TvF9Ux8VKkKqMH3BoXYEiIVFvq8= Received: by 10.150.119.17 with SMTP id r17mr2836524ybc.9.1269244347455; Mon, 22 Mar 2010 00:52:27 -0700 (PDT) Received: from [10.0.1.2] (adsl-76-197-240-144.dsl.chcgil.sbcglobal.net [76.197.240.144]) by mx.google.com with ESMTPS id 22sm3011578iwn.0.2010.03.22.00.52.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Mar 2010 00:52:25 -0700 (PDT) References: <168921C8-87E9-4502-9DD5-119A71F15EF6@cs.ucl.ac.uk> <20100322.154833.183041911.nishida@sfc.wide.ad.jp> In-Reply-To: <20100322.154833.183041911.nishida@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: <1DD325FE-05A0-4BEB-88B0-B8BC0E2EE2E0@gmail.com> Content-Transfer-Encoding: quoted-printable From: Hal Wigoda Date: Mon, 22 Mar 2010 02:52:18 -0500 To: Yoshifumi Nishida X-Mailer: Apple Mail (2.1077) Cc: philip.eardley@bt.com, tcpm@ietf.org Subject: Re: [tcpm] Multipath TCP signaling 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, 22 Mar 2010 07:52:14 -0000 Will this have any effect on covert chanels? hal wigoda chicago student, depaul university On Mar 22, 2010, at 1:48 AM, Yoshifumi Nishida wrote: >=20 > Dear all, >=20 > As Costin wrote in his mail, in multipath TCP working group, we are = discussing > signaling method for multipath TCP. On Tuesday, we're going to talk = about this > topic and see if we can reach consensue. We really appreciate if tcp = experts > give valuable feedbacks on this. > Please come to California C at 15:20. It's right after tcpm meeting! >=20 > Thanks, > -- > Phil and Yoshifumi >=20 > From: Costin Raiciu > Subject: [tcpm] Multipath TCP signaling > Date: Wed, 24 Feb 2010 11:27:41 +0100 > Message-ID: >=20 >> Hi, >>=20 >> In the multipath TCP working group we are trying to decide which is = the best way to signal multipath specific information between endpoints. = We are writing this message to invite contributions and thoughts from = members of the tcpm list, as we believe that whatever solution we choose = will impact other tcp signaling in the future. >>=20 >> Let me briefly tell you what we are trying to do.=20 >>=20 >> Multipath works by assigning a data level sequence number to = application data, and sending this data over different "subflows" which = look like tcp over the wire. These subflows have their own sequence = numbers too, on top of the data sequence number.=20 >>=20 >> The information multipath needs to get across is: >> - multipath enabled / join connection - this is only on flow/subflow = startup >> - data sequence number (each segment must have this to enable the = receiver to reorder data) >> - add/remove ip to connection (not often) >> - security negotiation, if needed >> - subflow policy, etc. >>=20 >> We have analyzed the requirements of this control information (e.g. = reliable, in order) and two basic ways of signaling it: >> - using TCP options - this is the traditional TCP way of signaling = control information; it is unreliable and the space is limited, it will = be a bit difficult to get it through existing middleboxes, but it plays = nice with future "multipath aware" middleboxes. >> - using the payload - this would use TLV like encoding (as in tls) = and does not have space issues. However, all the control info is now = ordered, congestion controlled and reliably sent - which may not be what = we want. This will get through more middleboxes today, but it is not = nice to future middleboxes: they have to keep state to be able to parse = the control info. Also, the middleboxes cannot easily add control info = (this is contentious, I know, but should be possible). >>=20 >> The detailed analysis is in the following doc: = http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf >>=20 >> What do people think is the best approach? >> Costin >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Mon Mar 22 11:05:53 2010 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 63E723A699F for ; Mon, 22 Mar 2010 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-1.594, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 8kw-QAKdJzGj for ; Mon, 22 Mar 2010 11:05:52 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 0B18B3A6822 for ; Mon, 22 Mar 2010 11:05:52 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2MI67px006413; Mon, 22 Mar 2010 11:06:08 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AC1BFB8FD48; Mon, 22 Mar 2010 14:06:07 -0400 (EDT) To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glory Days MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma45455-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 22 Mar 2010 14:06:07 -0400 Sender: mallman@icir.org Message-Id: <20100322180607.AC1BFB8FD48@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 22 Mar 2010 18:05:53 -0000 ----------ma45455-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-03 > > Please respond if you either: > > (1) Support making this document a WG document with the > target for BCP. > > (2) Oppose making this document a WG document. > > Of course, other comments are also welcome :). Well... Um... Something Else. Thoughts: - First, its fine technology. I find the security implications to be pretty dubious (an attacker guessing a TS and then leveraging that seems a Pretty Damned Remote Possibility). But, the connection identifier re-use business is nice enough. So, I think we should take on this work in some fashion (which is not exactly what (1) indicates in taking "this document [...] for BCP"). - But, to me, the right thing to do here is to roll these changes into the work item this WG already has going: 1323bis. Clearly how to generate timestamps (section 2 of the Gont I-D) is within bounds for that document. In addition, section 3 of the Gont document can readily be viewed as another application of timestamps (a la RTTM & PAWS). - So, I don't know why we'd spin off a second document when we are already updating the main document in this space. TCP is fragmented enough and so when we can fit things together we should. Further, its one less document this WG will have to food fight over. - Why straight to BCP? I don't really have any technological issues here I want to flog, but it strikes me as pretty weird to move a mechanism like this right to BCP. Even if I don't have a lot of technical heartburn, we seemingly have a 'standards track' for a reason. My two cents ... allman ----------ma45455-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkunsY8ACgkQWyrrWs4yIs4bmACdFnGmk7foHhvKTRu7ZvAhOvIN CTsAoIiFJ02OU06fRhkdruEln1DuZu4W =wiE2 -----END PGP SIGNATURE----- ----------ma45455-1-- From ananth@cisco.com Mon Mar 22 11:24:53 2010 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 F28643A682E for ; Mon, 22 Mar 2010 11:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.034 X-Spam-Level: X-Spam-Status: No, score=-10.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 HEITTF9embl3 for ; Mon, 22 Mar 2010 11:24:52 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 11E0A3A67E3 for ; Mon, 22 Mar 2010 11:24:52 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANpSp0urR7Ht/2dsb2JhbACbJHOkLJgthH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,289,1267401600"; d="scan'208";a="103968198" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Mar 2010 18:25:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2MIP9jQ016461; Mon, 22 Mar 2010 18:25:09 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 11:25:10 -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: Mon, 22 Mar 2010 11:25:09 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC58092849D3@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <20100322180607.AC1BFB8FD48@lawyers.icir.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: AcrJ6l4+eAqiGQ/bQlSUWtCR+IgbyAAAXsuA References: <20100322180607.AC1BFB8FD48@lawyers.icir.org> From: "Anantha Ramaiah (ananth)" To: , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-OriginalArrivalTime: 22 Mar 2010 18:25:10.0004 (UTC) FILETIME=[0151A340:01CAC9ED] Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 22 Mar 2010 18:24:53 -0000 Mark brings up a good point, IMO. My thinking here is that ISN generation RFC (1948) is an informational RFC and did really update RFC 793. (may be RFC 793 is very holy and you can't really have a bis for that? ;-) Following the same analogy, this draft can be a standalone draft which recommends that something can be done as it is structured currently. OTOH, the same text can be folded as part of the RFC1323bis as well. Looks like it is boiling down to be a procedural question here ? Just my few cents, -Anantha=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Mark Allman > Sent: Monday, March 22, 2010 11:06 AM > To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > Cc: tcpm@ietf.org > Subject: Re: [tcpm] poll for adoption of=20 > draft-gont-tcpm-tcp-timestamps-03 >=20 >=20 > > http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-03 > >=20 > > Please respond if you either: > >=20 > > (1) Support making this document a WG document with the > > target for BCP. > >=20 > > (2) Oppose making this document a WG document. > >=20 > > Of course, other comments are also welcome :). >=20 > Well... Um... Something Else. >=20 > Thoughts: >=20 > - First, its fine technology. I find the security=20 > implications to be > pretty dubious (an attacker guessing a TS and then leveraging that > seems a Pretty Damned Remote Possibility). But, the connection > identifier re-use business is nice enough. >=20 > So, I think we should take on this work in some fashion (which is > not exactly what (1) indicates in taking "this document [...] for > BCP"). >=20 > - But, to me, the right thing to do here is to roll these=20 > changes into > the work item this WG already has going: 1323bis. Clearly how to > generate timestamps (section 2 of the Gont I-D) is within=20 > bounds for > that document. In addition, section 3 of the Gont document can > readily be viewed as another application of timestamps (a la RTTM > & PAWS). =20 >=20 > - So, I don't know why we'd spin off a second document when we are > already updating the main document in this space. TCP is=20 > fragmented > enough and so when we can fit things together we should. Further, > its one less document this WG will have to food fight over. >=20 > - Why straight to BCP? I don't really have any technological issues > here I want to flog, but it strikes me as pretty weird to move > a mechanism like this right to BCP. Even if I don't have a lot of > technical heartburn, we seemingly have a 'standards track' for a > reason.=20 >=20 > My two cents ... >=20 > allman >=20 >=20 >=20 >=20 From mallman@icir.org Mon Mar 22 12:11:27 2010 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 661953A6B61 for ; Mon, 22 Mar 2010 12:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 YkqnDKW2NsrY for ; Mon, 22 Mar 2010 12:11:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 941D43A69EB for ; Mon, 22 Mar 2010 12:11:01 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2MJBIuw017232; Mon, 22 Mar 2010 12:11:18 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1F267B91393; Mon, 22 Mar 2010 15:11:18 -0400 (EDT) To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glory Days MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma49365-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 22 Mar 2010 15:11:18 -0400 Sender: mallman@icir.org Message-Id: <20100322191118.1F267B91393@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 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, 22 Mar 2010 19:11:27 -0000 ----------ma49365-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt > > Please respond if you either: > > (1) Support making this document a WG document with the > target for Informational. > > (2) Oppose making this document a WG document. > > Of course, other comments are also welcome :). I think (1) is fine. I don't really think this document is needed, but I also don't think it hurts anything as a clarification. It could also be a bit more clear and succinct. A few comments below, but in general "eh, whatever". allman Section 1: - I find this ... It is important to remember that ACK (acknowledgement) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. confusing. I understand the first sentence, but I cannot parse the second. I can guess what it is trying to say, but it needs fixed. Section 3: - The sender does not necessarily dump "all" data into the send queue. It depends on how big the send buffer is and how much data needs to be sent. Section 5: - This: It also suggests that TCP MUST not abort any connection until either explicitly requested by the application to do so. makes no sense. Is that "MUST not" or "MUST NOT". Usually there are two options after an "either", but I see only one. I would normally think this is a spurious "either", but here am somehow thinking there is an option that was forgotten. Meta: - Isn't the overall point of this document to clarify things to say that (1) a TCP cannot tear down a connection itself, (2) the application can abort a connection and (3) the OS can abort a connection? If I am remembering this right then this could and should be called out **much** better in the document. ----------ma49365-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkunwNUACgkQWyrrWs4yIs4OOwCfRc0wP/dvY9Nh28cqR3kIGCMT y0UAoIW644blOTrsEBnXBDKqaJA05e5m =IiP1 -----END PGP SIGNATURE----- ----------ma49365-1-- From A.Hoenes@TR-Sys.de Mon Mar 22 12:16:17 2010 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 2907F3A6784 for ; Mon, 22 Mar 2010 12:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.98 X-Spam-Level: *** X-Spam-Status: No, score=3.98 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, 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 Ho5pZSJoaRaV for ; Mon, 22 Mar 2010 12:16:16 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C4C813A67A3 for ; Mon, 22 Mar 2010 12:16:14 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA045695356; Mon, 22 Mar 2010 20:15:56 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA02621; Mon, 22 Mar 2010 20:15:55 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003221915.UAA02621@TR-Sys.de> To: tcpm@ietf.org, mallman@icir.org Date: Mon, 22 Mar 2010 20:15:55 +0100 (MEZ) 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] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 22 Mar 2010 19:16:17 -0000 Mark Allman wrote: > ... > > - But, to me, the right thing to do here is to roll these changes > into the work item this WG already has going: 1323bis. [...] Going? Gone ?? It's listed on : Expired: draft-ietf-tcpm-1323bis -01 2009-03-04 Expired [ And, btw, -00 was published 2008-01-29, so extrapolating linearly, I still hope for a -02 soon. But the confidence level of statistics based on a sample of size 2 is rather small. :-) ] A significant part of my review comments from early in 2009 have been addressed in the -01 draft version, but other, non-trivial, parts have been deferred to the next update. I cannot recall discussion of this draft on the list since a very long time. So it looks like the choice for the WG might be having a short document that can be shipped by the end of this year (or even much faster), or with a -1323bis in 5 years or so. (Or would you prefer doing both?) IIRC, Fernando's timestamp draft has been phrased as a BCP because feedback from the WG (MPLS IETF?) indicated it would not be acceptable to the WG with normative language, on the Standards Track. I personally would not oppose to Standards Track, but I'm not the WG. 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 MBashyam@OcarinaNetworks.com Mon Mar 22 12:21:25 2010 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 7B20F3A6950 for ; Mon, 22 Mar 2010 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] 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 CaRb8RpTlu2d for ; Mon, 22 Mar 2010 12:21:24 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id F36C93A69EA for ; Mon, 22 Mar 2010 12:21:05 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Mon, 22 Mar 2010 12:23:08 -0700 From: Murali Bashyam To: "mallman@icir.org" , "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Date: Mon, 22 Mar 2010 12:23:03 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrJ88Uwmslo20H3QTGFuADyfcAK/gAAG34Q Message-ID: References: <20100322191118.1F267B91393@lawyers.icir.org> In-Reply-To: <20100322191118.1F267B91393@lawyers.icir.org> 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" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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, 22 Mar 2010 19:21:25 -0000 As an FYI, I wanted to point out the purpose of this document at a high lev= el. It is to clarify that it is OK for connections to be aborted in the ZWP= state (which entity is not the subject here), currently the language of RF= C 1122 has caused confusion about this and has been interpreted by implemen= ters to mean an "indefinite wait" and is amply substantiated by the fact th= at none of the widely deployed implementations (BSD, linux and windows) hav= e got this aspect right, i.e they exhibit marked differences in their handl= ing of this condition.=20 -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mar= k Allman Sent: Monday, March 22, 2010 12:11 PM To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 > http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt >=20 > Please respond if you either: >=20 > (1) Support making this document a WG document with the > target for Informational. >=20 > (2) Oppose making this document a WG document. >=20 > Of course, other comments are also welcome :). I think (1) is fine. I don't really think this document is needed, but I a= lso don't think it hurts anything as a clarification. It could also be a b= it more clear and succinct. A few comments below, but in general "eh, what= ever". allman Section 1: - I find this ... It is important to remember that ACK (acknowledgement) segments that contain no data are not reliably transmitted by TCP. Therefore zero window probing SHOULD be supported to prevent a connection from hanging forever if ACK segments that re-opens the window is lost. confusing. I understand the first sentence, but I cannot parse the second. I can guess what it is trying to say, but it needs fixed. Section 3: - The sender does not necessarily dump "all" data into the send queue. It depends on how big the send buffer is and how much data needs to be sent. Section 5: - This: It also suggests that TCP MUST not abort any connection until either explicitly requested by the application to do so. =20 makes no sense. =20 Is that "MUST not" or "MUST NOT". Usually there are two options after an "either", but I see only one. I would normally think this is a spurious "either", but here am somehow thinking there is an option that was forgotten. Meta: - Isn't the overall point of this document to clarify things to say that (1) a TCP cannot tear down a connection itself, (2) the application can abort a connection and (3) the OS can abort a connection? If I am remembering this right then this could and should be called out **much** better in the document. From Donald.Smith@qwest.com Mon Mar 22 12:28:21 2010 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 8F2A93A67A3 for ; Mon, 22 Mar 2010 12:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 d+OPC9X5sGFG for ; Mon, 22 Mar 2010 12:28:19 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id 0435E3A6901 for ; Mon, 22 Mar 2010 12:28:18 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o2MJSV7t015815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Mar 2010 14:28:32 -0500 (CDT) Received: from qtdenexhtm20.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o2MJSPab005339; Mon, 22 Mar 2010 14:28:26 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm20.AD.QINTRA.COM ([151.119.91.229]) with mapi; Mon, 22 Mar 2010 13:28:25 -0600 From: "Smith, Donald" To: "'Fernando Gont'" , "'tcpm@ietf.org'" Date: Mon, 22 Mar 2010 13:28:24 -0600 Thread-Topic: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security (more time to comment!) Thread-Index: AcrCFuCSR1bMYcEKTY62iTz5ulgoGwH1f9eA Message-ID: References: <4B99CA9C.9070807@gont.com.ar> In-Reply-To: <4B99CA9C.9070807@gont.com.ar> 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-chairs@tools.ietf.org'" Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security (more time to comment!) 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, 22 Mar 2010 19:28:21 -0000 First sorry for the late reply. My comments are mostly areas I would reword to clarify the meaning since th= ere wasn't a lot of technical content in this version of the draft. I am providing the diff output to provide the original, some context and my= suggested changes/questions. smitdo@co950g02smitdo /cygdrive/c/cygwin $ diff -b -c1 draft-ietf-tcpm-tcp-security-01.txt tcp-secure-rfc.txt *** draft-ietf-tcpm-tcp-security-01.txt Mon Mar 22 13:02:52 2010 --- tcp-secure-rfc.txt Mon Mar 22 13:09:59 2010 *** 231,243 **** The TCP/IP protocol suite was conceived in an environment that was ! quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early ! adoption in production environments, to the point that, to some ! extent, the current world's economy depends on them. While many textbooks and articles have created the myth that the ! Internet protocols were designed for warfare environments, the top ! level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET [Clark, 1988]. As a result, many ! protocol specifications focus only on the operational aspects of the ! protocols they specify, and overlook their security implications. --- 231,245 ---- The TCP/IP protocol suite was conceived in an environment that was ! a "friendly" openly sharing enviroment primairly composed of education= and ! research sites. Which is quite different from the hostile environment the= y ! currently operate in. However, the effectiveness of the protocols led to their early ! adoption in commercial production environments, to the point that, ! portions of the current world's economy depends upon them. While many textbooks and articles have created the myth that the ! Internet protocols were designed for warfare environments, the primary ! goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET [Clark, 1988]. As a result, many ! protocol specifications primarily focus on the operational aspects of = the ! protocols they specify, overlooking their security implications. *************** *** 246,250 **** adopted by the ARPANET more than two decades ago. During the last ! twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in ! some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols --- 248,252 ---- adopted by the ARPANET more than two decades ago. During the last ! twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in ! the protocol implementations, affecting only a limited set of systems, while others were based in flaws in the protocols *************** *** 258,264 **** Security Incident Response Teams) and vendors, which helped to raise ! awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread ! among a large number of documents, which are sometimes difficult to ! identify. --- 260,267 ---- Security Incident Response Teams) and vendors, which helped to raise ! awareness about the threats and mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread ! through out a large number of documentsMaking a holistic view of ! vulnerabilities in this suite of protocols difficult to achieve especiall= y ! for implementation teams. *************** *** 266,269 **** Internet protocols did not result in official documents (RFCs) being ! issued by the IETF (Internet Engineering Task Force). This basically ! led to a situation in which "known" security problems have not always been addressed by all vendors. In addition, in many cases vendors --- 269,272 ---- Internet protocols did not result in official documents (RFCs) being ! issued by the IETF (Internet Engineering Task Force). This ! lead to a situation in which "known" security problems have not always been addressed by all vendors. In addition, in many cases vendors *************** *** 273,275 **** ! Producing a secure TCP/IP implementation nowadays is a very difficult --- 276,278 ---- ! Producing a less vulnerable TCP/IP implementation is a difficult *************** *** 284,288 **** a security roadmap for the protocols. Implementers are faced with ! the hard task of identifying relevant documentation and ! differentiating between that which provides correct advice, and that ! which provides misleading advice based on inaccurate or wrong assumptions. --- 287,292 ---- a security roadmap for the protocols. Implementers are faced with ! the complex task of identifying relevant documentation and ! differentiating between those that provide correct advice, and those ! that provide misleading or incomplete advice based on inaccurate or ! incorrect assumptions. *************** *** 330,331 **** --- 334,336 ---- Option" (6 pages) + Tcp-AO draft ?? should be included *** 365,366 **** --- 370,372 ---- + 1.3. Organization of this document *************** *** 369,374 **** contains a discussion of each of the TCP header fields, identifies ! their security implications, and discusses the possible countermeasures. The second part contains an analysis of the security implications of the mechanisms and policies implemented by ! TCP, and of a number of implementation strategies in use by a number of popular TCP implementations. --- 375,380 ---- contains a discussion of each of the TCP header fields, identifies ! their security implications, and discusses possible countermeasures. The second part contains an analysis of the security implications of the mechanisms and policies implemented by ! TCP and of a number of implementation strategies in use by a number of popular TCP implementations. *************** *** 428,430 **** original specification. RFC 2581 [Allman et al, 1999] specifies TCP ! congestion control and avoidance mechanisms, not present in the original specification. Other documents specify extensions and --- 434,437 ---- original specification. RFC 2581 [Allman et al, 1999] specifies TCP ! mechanisms for ! control and avoidanceof congestion , not present in the original specification. Other documents specify extensions and *************** *** 513,517 **** in response (provided that the incomming segment does not have the ! RST flag set). ! TCP MUST be able to grecefully handle the case where the source end- point (IP Source Address, TCP Source Port) is the same as the --- 520,525 ---- in response (provided that the incomming segment does not have the ! RST flag set). (wouldn't this cause the reset to have 0 as the source = or ! destination which would cause a reset back, giving us a ping pong effect? ! TCP MUST be able to gracefully handle the case where the source end- point (IP Source Address, TCP Source Port) is the same as the *************** *** 521,523 **** is in the LISTEN or CLOSED states for use as ephemeral ports, as this ! could allow attackers on the local system to "steal" incomming TCP connections. --- 529,531 ---- is in the LISTEN or CLOSED states for use as ephemeral ports, as this ! could allow attackers on the local system to "steal" incoming TCP connections. *************** *** 543,547 **** unique (not currently in use by any other transport protocol ! instance). In most of the discussion we refer to client-side (or "ephemeral") port-numbers and server-side port numbers, since that distinction is --- 551,558 ---- unique (not currently in use by any other transport protocol ! instance). (then doesn't this need to be 5tuple including ip protocol?= ) In most of the discussion we refer to client-side (or "ephemeral") + client side doesn't have to be ephermeral many tcp protocols use the same + port for both client and server (trandionally). Ephemeral means short liv= ed + (daily). port-numbers and server-side port numbers, since that distinction is *************** *** 562,565 **** ! port 0, an ephemeral port is selected for the corresponding TCP end- ! point. As a result, the TCP port number 0 is never actually used in TCP segments. --- 573,578 ---- ! port 0, an port from the systems "ephemeral port range" is selected fo= r ! the corresponding TCP end- ! point. As a result, the TCP port number 0 should never actually be us= ed ! in TCP segments. *************** *** 570,572 **** of 0 are usually employed for remote OS detection via TCP/IP stack ! fingerprinting [Jones, 2003]. --- 583,586 ---- of 0 are usually employed for remote OS detection via TCP/IP stack ! fingerprinting [Jones, 2003]. Additionally ip fragements don't have a = port ! number filled in which most systems interpret as port 0/0. *************** *** 582,587 **** an RST (provided these incoming segments do not have the RST bit ! set). Responding with an RST segment to incoming segments that have the RST ! bit would open the door to RST-war attacks. --- 596,601 ---- an RST (provided these incoming segments do not have the RST bit ! set) or do silent drop? Responding with an RST segment to incoming segments that have the RST ! bit would open the door to infinite RST loop attacks. *************** *** 595,597 **** legitimate scenarios, TCP should nevertheless be able to process them ! without the need of any "extra" code. --- 609,612 ---- legitimate scenarios, TCP should nevertheless be able to process them ! without the need of any "extra" code. + Of course there is "extra" code required you have to do a sanity check. *************** *** 651,652 **** --- 666,669 ---- connection in any state other than the fictional state CLOSED. This + Not fictional maybe incorrectly identifed? And here you use conection id'= s + which I believe is the four-tuple but isn't clearly called out as such. can be problematic in scenarios in which a client establishes *************** (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Thursday, March 11, 2010 10:01 PM > To: tcpm@ietf.org > Cc: tcpm-chairs@tools.ietf.org > Subject: [tcpm] Feedback request on > draft-ietf-tcpm-tcp-security (more time to comment!) > > Folks, > > Some of you had expressed interest in providing feedback on the > aforementioned I-D. However, so far only a one person (Wes) has sent > feedback. > > Given that more comments are needed, and that the last few weeks have > probably been particularly busy (IETF I-D submission > cut-off's), we have > extended the period of time to send comments on > draft-ietf-tcpm-tcp-security-01.txt > (http://tools.ietf.org/id/draft-ietf-tcpm-tcp-security-01.txt). > > I'm requesting feedback on all the sections through Section > 3.1.2.3. -- this includes the introduction sections, the basic > check on the TCP segment size (Section 3) and the discussion of port > numbers (Section 3.1 with all its subsections). > > Please review these sections and submit comments by Monday March 22nd, > 2010, so that we can move on to the next sections in a timely manner. > > Thanks! > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From L.Wood@surrey.ac.uk Mon Mar 22 12:43:13 2010 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 7B2763A685A for ; Mon, 22 Mar 2010 12:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[AWL=-1.865, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 nDRyuIzmzy9q for ; Mon, 22 Mar 2010 12:43:11 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 8406D3A67F0 for ; Mon, 22 Mar 2010 12:43:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-7.tower-72.messagelabs.com!1269287007!916544!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.43] Received: (qmail 21201 invoked from network); 22 Mar 2010 19:43:27 -0000 Received: from unknown (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-7.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 22 Mar 2010 19:43:27 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Mon, 22 Mar 2010 19:43:27 +0000 From: To: Date: Mon, 22 Mar 2010 19:43:26 +0000 Thread-Topic: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: AcrJ9/CwzUZOmv7ISoaz6zmk8HPaag== Message-ID: <6537EA7D-E91C-4751-8595-C8232206F202@surrey.ac.uk> References: <20100322180607.AC1BFB8FD48@lawyers.icir.org> In-Reply-To: <20100322180607.AC1BFB8FD48@lawyers.icir.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 22 Mar 2010 19:43:13 -0000 On 22 Mar 2010, at 18:06, Mark Allman wrote: > - But, to me, the right thing to do here is to roll these changes into > the work item this WG already has going: 1323bis. http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-01 is based on http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg25824= .html 1323bis has been going since 2003, and that's only in its current form. http://www.kohala.com/start/tcplw-extensions.txt predates that by another decade. (I've found this particular draft useful previously.) So, this prompts the question as to when this ever-iterated document might be published. > - So, I don't know why we'd spin off a second document when we are > already updating the main document in this space. if it's relatively self-contained without dependencies, treat it as a separate work item, and get it published, rather than getting bogged down in a larger item that is already close to two decades overdue. > TCP is fragmented > enough and so when we can fit things together we should. Further, > its one less document this WG will have to food fight over. 1323bis is too large, and too old. It's a massive food fight waiting to happen once people not even born when it was started wade in, not to mention a large editing work effort. My vote is to keep the timestamps stuff self-contained and separate. Publish what you can. > - Why straight to BCP? I don't really have any technological issues > here I want to flog, but it strikes me as pretty weird to move > a mechanism like this right to BCP. Even if I don't have a lot of > technical heartburn, we seemingly have a 'standards track' for a > reason.=20 I don't disagree. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From touch@ISI.EDU Mon Mar 22 13:03:45 2010 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 4AC143A69F1 for ; Mon, 22 Mar 2010 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 CdDAualTWr0s for ; Mon, 22 Mar 2010 13:03:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DA7613A6B06 for ; Mon, 22 Mar 2010 13:02:43 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2MK1ErQ009158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Mar 2010 13:01:16 -0700 (PDT) Message-ID: <4BA7CC89.9070507@isi.edu> Date: Mon, 22 Mar 2010 13:01:13 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100322191118.1F267B91393@lawyers.icir.org> In-Reply-To: <20100322191118.1F267B91393@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A8CE4AF4846DD90823F3BE0" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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, 22 Mar 2010 20:03:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A8CE4AF4846DD90823F3BE0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: >> http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt >> >> Please respond if you either: >> >> (1) Support making this document a WG document with the >> target for Informational. >> >> (2) Oppose making this document a WG document. >> >> Of course, other comments are also welcome :). >=20 > I think (1) is fine. I don't really think this document is needed, but= > I also don't think it hurts anything as a clarification. That's my view as well. Joe --------------enig4A8CE4AF4846DD90823F3BE0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkunzIkACgkQE5f5cImnZrs4awCgmIRrrE1PmLlPr9aJOxq1Ixmq UDgAnR47hkR+1TCWAuSwtkZBEs/0a5yd =/KYD -----END PGP SIGNATURE----- --------------enig4A8CE4AF4846DD90823F3BE0-- From nishida@sfc.wide.ad.jp Mon Mar 22 13:04:44 2010 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 D88EA3A6B96 for ; Mon, 22 Mar 2010 13:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.655 X-Spam-Level: *** X-Spam-Status: No, score=3.655 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 dtJDUIfn7fCk for ; Mon, 22 Mar 2010 13:04:43 -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 364A03A6B83 for ; Mon, 22 Mar 2010 13:04:43 -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 503BF4DF0C; Tue, 23 Mar 2010 05:04:57 +0900 (JST) Date: Tue, 23 Mar 2010 05:04:57 +0900 (JST) Message-Id: <20100323.050457.45904012.nishida@sfc.wide.ad.jp> To: hal.wigoda@gmail.com From: Yoshifumi Nishida In-Reply-To: <1DD325FE-05A0-4BEB-88B0-B8BC0E2EE2E0@gmail.com> References: <20100322.154833.183041911.nishida@sfc.wide.ad.jp> <1DD325FE-05A0-4BEB-88B0-B8BC0E2EE2E0@gmail.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 Cc: philip.eardley@bt.com, tcpm@ietf.org Subject: Re: [tcpm] Multipath TCP signaling 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, 22 Mar 2010 20:04:45 -0000 Hi Hal, All I can say now is we're going to discuss what is the best way to signal multipath TCP information to its peer on Tuesday. Also, the WG welcomes new insights and ideas. I think there are lots of rooms to bring your idea in mptcp since it has just started. Thanks, -- Yoshifumi Nishida nishida@sfc.wide.ad.jp From: Hal Wigoda Subject: Re: [tcpm] Multipath TCP signaling Date: Mon, 22 Mar 2010 02:52:18 -0500 Message-ID: <1DD325FE-05A0-4BEB-88B0-B8BC0E2EE2E0@gmail.com> > Will this have any effect on covert chanels? > > hal wigoda > chicago > student, depaul university > > On Mar 22, 2010, at 1:48 AM, Yoshifumi Nishida wrote: > > > > > Dear all, > > > > As Costin wrote in his mail, in multipath TCP working group, we are discussing > > signaling method for multipath TCP. On Tuesday, we're going to talk about this > > topic and see if we can reach consensue. We really appreciate if tcp experts > > give valuable feedbacks on this. > > Please come to California C at 15:20. It's right after tcpm meeting! > > > > Thanks, > > -- > > Phil and Yoshifumi > > > > From: Costin Raiciu > > Subject: [tcpm] Multipath TCP signaling > > Date: Wed, 24 Feb 2010 11:27:41 +0100 > > Message-ID: > > > >> Hi, > >> > >> In the multipath TCP working group we are trying to decide which is the best way to signal multipath specific information between endpoints. We are writing this message to invite contributions and thoughts from members of the tcpm list, as we believe that whatever solution we choose will impact other tcp signaling in the future. > >> > >> Let me briefly tell you what we are trying to do. > >> > >> Multipath works by assigning a data level sequence number to application data, and sending this data over different "subflows" which look like tcp over the wire. These subflows have their own sequence numbers too, on top of the data sequence number. > >> > >> The information multipath needs to get across is: > >> - multipath enabled / join connection - this is only on flow/subflow startup > >> - data sequence number (each segment must have this to enable the receiver to reorder data) > >> - add/remove ip to connection (not often) > >> - security negotiation, if needed > >> - subflow policy, etc. > >> > >> We have analyzed the requirements of this control information (e.g. reliable, in order) and two basic ways of signaling it: > >> - using TCP options - this is the traditional TCP way of signaling control information; it is unreliable and the space is limited, it will be a bit difficult to get it through existing middleboxes, but it plays nice with future "multipath aware" middleboxes. > >> - using the payload - this would use TLV like encoding (as in tls) and does not have space issues. However, all the control info is now ordered, congestion controlled and reliably sent - which may not be what we want. This will get through more middleboxes today, but it is not nice to future middleboxes: they have to keep state to be able to parse the control info. Also, the middleboxes cannot easily add control info (this is contentious, I know, but should be possible). > >> > >> The detailed analysis is in the following doc: http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf > >> > >> What do people think is the best approach? > >> Costin > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > From mallman@icir.org Mon Mar 22 13:18:55 2010 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 C2C313A69C5 for ; Mon, 22 Mar 2010 13:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 r5c8LtjE-oq9 for ; Mon, 22 Mar 2010 13:18:54 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 3E6423A6880 for ; Mon, 22 Mar 2010 13:18:50 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2MKJ6P5029432; Mon, 22 Mar 2010 13:19:07 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id D376BB91E92; Mon, 22 Mar 2010 16:19:06 -0400 (EDT) To: L.Wood@surrey.ac.uk From: Mark Allman In-Reply-To: <6537EA7D-E91C-4751-8595-C8232206F202@surrey.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Glory Days MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma53434-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 22 Mar 2010 16:19:06 -0400 Sender: mallman@icir.org Message-Id: <20100322201906.D376BB91E92@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 22 Mar 2010 20:18:55 -0000 ----------ma53434-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I don't track this stuff very closely. So, - If 1323bis is not happening then going with an independent document is fine with me. - It just strikes me as strange to do both strands independently if we are in fact doing both strands. - 1323bis can always pick this up at some point and obsolete any small document (as we have done for instance with 5681 picking up 3390 and 3042). - I need to see more justification before agreeing that this straight-to-BCP track is reasonable. allman ----------ma53434-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkun0LoACgkQWyrrWs4yIs5HxQCgksJgFzdNgH9+mEtTR9vkWbsI 63YAn1EGIkqu9rYC5XxZg9eaZwc6CNJb =tvXQ -----END PGP SIGNATURE----- ----------ma53434-1-- From johnwheffner@gmail.com Mon Mar 22 14:41:45 2010 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 2F3DC28C147 for ; Mon, 22 Mar 2010 14:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 f2akqLqXuaJI for ; Mon, 22 Mar 2010 14:41:44 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 5562C3A67AE for ; Mon, 22 Mar 2010 14:41:30 -0700 (PDT) Received: by wwg30 with SMTP id 30so2571380wwg.31 for ; Mon, 22 Mar 2010 14:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h2k3xVNEityvb6kqB5M5FgbZL007aOITMr+57dCMTuE=; b=rw9a9ZE2jZ6JopBt4yKxAWmgg01Aase7yyONTGsbI7fKSXxiWuRip3uSRCTAvZ3NJb sXAivs3jCwY3lI7wlN0wpinV812rTBOOuoM+O9iBrDQps6fkkyjaEIdT5izTF6GKSXAk /hZvX/oqw6Es4yDdTm4LzzJha/icaOO8ylH/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rN6KTEZZst98lgdn6xPjd1ZGMv7q5zDrnO4VcrGHyIZtB1vqVRAwFqTDMXNzumiFd/ 8TRNXutti2dLCvdQl1YqdIQjMLxVvXimO7krkm6wDIjkvjuhqmlVmnoZNSzWexFBTEJt uGoZ/YTYGKM+dVdo9zZInAjUqXmJ1oDikLjBA= MIME-Version: 1.0 Received: by 10.216.85.130 with SMTP id u2mr2793589wee.49.1269294102724; Mon, 22 Mar 2010 14:41:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Mar 2010 17:41:42 -0400 Message-ID: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> From: John Heffner To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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, 22 Mar 2010 21:41:45 -0000 I read the new version of this draft. For the record, my opinion hasn't changed since the -00 version, which is that publication of this draft as an RFC would be harmful. I don't object to the simple clarifying statement that a connection may be aborted while in the persist state. (I'm not sure this requires a new RFC.) However, this draft goes beyond that, implying that connections should be aborted *because* they are in persist state. In practical terms, what is the difference between a connection in persist state, and one where a receiver acknowledges one byte of data every 10 seconds, never advertising a zero window? -John On Mon, Mar 8, 2010 at 3:49 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > The authors have updated draft-ananth-persist, and asked > us to poll the TCPM WG to have this particular document > adopted with an Informational target. > > http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt > > This has been discussed to some extent on the mailing > list and at the Dublin meeting. =A0The authors have > responded to comments received thus far and updated the > document as it grew from the outcome of prior feedback > on the draft-mahesh-persist-timeout document. > > Please respond if you either: > > (1) Support making this document a WG document with the > =A0 =A0target for Informational. > > (2) Oppose making this document a WG document. > > Of course, other comments are also welcome :). > > It's relatively short, so if people could respond in the > next 2 weeks, this would allow us to determine consensus > during the week of the IETF meeting. > > -- > Wes Eddy > MTI Systems > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From mahesh@cisco.com Mon Mar 22 16:38:59 2010 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 EA6073A6861 for ; Mon, 22 Mar 2010 16:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 tlEDk0gan9od for ; Mon, 22 Mar 2010 16:38:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 26D0A3A6867 for ; Mon, 22 Mar 2010 16:38:57 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHKcp0urR7H+/2dsb2JhbACbKXOkN5hghH0Egx6GYw X-IronPort-AV: E=Sophos;i="4.51,290,1267401600"; d="scan'208";a="310755513" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 22 Mar 2010 23:39:15 +0000 Received: from [10.21.107.174] (sjc-vpnasa-942.cisco.com [10.21.107.174]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2MNdFIA015253 for ; Mon, 22 Mar 2010 23:39:15 GMT Message-ID: <4BA7FFA2.4020800@cisco.com> Date: Mon, 22 Mar 2010 16:39:14 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: tcpm@ietf.org References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> In-Reply-To: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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, 22 Mar 2010 23:39:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John, On 3/22/2010 2:41 PM, John Heffner wrote: > I read the new version of this draft. For the record, my opinion > hasn't changed since the -00 version, which is that publication of > this draft as an RFC would be harmful. I don't object to the simple > clarifying statement that a connection may be aborted while in the > persist state. (I'm not sure this requires a new RFC.) However, this > draft goes beyond that, implying that connections should be aborted > *because* they are in persist state. Where in the draft do we imply that "connections should be aborted *because* they are in persist state"? We are not implying that connections SHOULD be aborted because they are in persist state. Instead we are suggesting that connections should be *allowed* to be aborted in persist state. Currently RFC 1122 language is ambiguous in this regard when connections go into indefinite wait in ZWP condition. > > In practical terms, what is the difference between a connection in > persist state, and one where a receiver acknowledges one byte of data > every 10 seconds, never advertising a zero window? The objective of the current draft is to clarify the state of connections in persist condition. A one byte acknowledgment takes the connection out of persist condition which is out of the scope of this draft. > > -John > > > On Mon, Mar 8, 2010 at 3:49 PM, Eddy, Wesley M. (GRC-MS00)[ASRC > AEROSPACE CORP] wrote: >> The authors have updated draft-ananth-persist, and asked >> us to poll the TCPM WG to have this particular document >> adopted with an Informational target. >> >> http://www.ietf.org/id/draft-ananth-tcpm-persist-02.txt >> >> This has been discussed to some extent on the mailing >> list and at the Dublin meeting. The authors have >> responded to comments received thus far and updated the >> document as it grew from the outcome of prior feedback >> on the draft-mahesh-persist-timeout document. >> >> Please respond if you either: >> >> (1) Support making this document a WG document with the >> target for Informational. >> >> (2) Oppose making this document a WG document. >> >> Of course, other comments are also welcome :). >> >> It's relatively short, so if people could respond in the >> next 2 weeks, this would allow us to determine consensus >> during the week of the IETF meeting. >> >> -- >> Wes Eddy >> MTI Systems >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm - -- *Mahesh Jethanandani* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLp/+iAAoJEP9ZPWIqKBmieqAH/2abpfTCnWeBoVp62hYs5AtO t6BRHBVkGa8Udu6qxzJPfJizSz+IQlmucK89UHZf1gMe+7IKVluAAjjLHrNu/nAW klL59k5mjvANpjfnuavHn9P07pR4MG4ZTfUuPaLoUriW3udop+stTRt16bRkeN29 1iakjVOlBU58ZmI4zA2or1GxCTDANo9ugifvBtSlYkrD2TZEgrKTSwlQMXzLAX1X bp1L/RAnnY/7pItEWNZ5F7iqiKLAusOffWxD/qbfP2Mp4EU42rl3u3Fpoiq6kzZj pOTbuKUCL+pnT8P2X8n/XH3BI65mFWRiJIXgWWMlqnCExsibz+SEq7EvB698u4A= =45Q9 -----END PGP SIGNATURE----- From touch@ISI.EDU Mon Mar 22 18:07:10 2010 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 369123A68AE for ; Mon, 22 Mar 2010 18:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 U6LwuKHXZPQ8 for ; Mon, 22 Mar 2010 18:07:09 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5B0D03A68AB for ; Mon, 22 Mar 2010 18:07:09 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2N171wN009193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Mar 2010 18:07:02 -0700 (PDT) Message-ID: <4BA81434.5000808@isi.edu> Date: Mon, 22 Mar 2010 18:07:00 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mahesh Jethanandani References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> In-Reply-To: <4BA7FFA2.4020800@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8C959A5B1897E9B3833F74C4" X-MailScanner-ID: o2N171wN009193 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 01:07:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C959A5B1897E9B3833F74C4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani wrote: > John, >=20 > On 3/22/2010 2:41 PM, John Heffner wrote: >> I read the new version of this draft. For the record, my opinion >> hasn't changed since the -00 version, which is that publication of >> this draft as an RFC would be harmful. I don't object to the simple >> clarifying statement that a connection may be aborted while in the >> persist state. (I'm not sure this requires a new RFC.) However, this= >> draft goes beyond that, implying that connections should be aborted >> *because* they are in persist state. >=20 > Where in the draft do we imply that "connections should be aborted > *because* they are in persist state"? We are not implying that > connections SHOULD be aborted because they are in persist state. Instea= d > we are suggesting that connections should be *allowed* to be aborted in= > persist state.=20 FWIW, that's my view. > Currently RFC 1122 language is ambiguous in this regard > when connections go into indefinite wait in ZWP condition. I don't think that's true, however. RFC 1122 never mandates that an endsystem cannot terminate a connection this way. I'm ambivalent to this as well, I don't see the need for this doc, but also don't see the harm. Joe --------------enig8C959A5B1897E9B3833F74C4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuoFDUACgkQE5f5cImnZrv0/QCcDpNYSAN8tqaCHODiqZbMQPge p7QAoLkOsK2Sv44jQpL9V143rk4Vh1Mk =QgSV -----END PGP SIGNATURE----- --------------enig8C959A5B1897E9B3833F74C4-- From ananth@cisco.com Mon Mar 22 18:30:42 2010 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 024BF3A68EF for ; Mon, 22 Mar 2010 18:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.752 X-Spam-Level: X-Spam-Status: No, score=-9.752 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 MdjpllTpE7RF for ; Mon, 22 Mar 2010 18:30:34 -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 1E4D63A68CE for ; Mon, 22 Mar 2010 18:30:34 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADq2p0urR7H+/2dsb2JhbACbKnOkfphuhH0Egx6LMA X-IronPort-AV: E=Sophos;i="4.51,291,1267401600"; d="scan'208";a="501059981" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 01:30:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2N1Uqhw022139; Tue, 23 Mar 2010 01:30:52 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 18:30:52 -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: Mon, 22 Mar 2010 18:30:51 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809284C32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4BA81434.5000808@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrKJTaG+gLYSZIURbeRKQ/3wQOHlAAAQXKg References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com><4BA7FFA2.4020800@cisco.com> <4BA81434.5000808@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Mahesh Jethanandani (mahesh)" X-OriginalArrivalTime: 23 Mar 2010 01:30:52.0498 (UTC) FILETIME=[79D4EB20:01CACA28] Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 01:30:42 -0000 =20 >=20 > I don't think that's true, however. RFC 1122 never mandates=20 > that an endsystem cannot terminate a connection this way. >=20 > I'm ambivalent to this as well, I don't see the need for this=20 > doc, but also don't see the harm. The problem is that all popular running implementations (BSD, Linux etc.,) have difficulties interpreting the RFC 1122 language in the way it is supposed to be interpreted which can lead to DOS scenario if properly not mitigated. That is the whole reason of coming up with this short draft. All these were discussed in the WG and the rough consensus of the WG was that it is ok to have this clarified in the form of a document. If there is anything that needs to be re-worded etc., to make this clear, we can address that. Thanks, -Anantha >=20 > Joe >=20 >=20 >=20 From david.borman@windriver.com Mon Mar 22 19:04:01 2010 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 1045D3A686A for ; Mon, 22 Mar 2010 19:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 V9SmBCe5Yrdl for ; Mon, 22 Mar 2010 19:04:00 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 136913A6880 for ; Mon, 22 Mar 2010 19:03:59 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o2N24EXL016439; Mon, 22 Mar 2010 19:04:14 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Mar 2010 19:04:14 -0700 Received: from unknown-233-90.windriver.com ([147.11.233.90]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Mar 2010 19:04:13 -0700 From: David Borman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2010 19:04:12 -0700 Message-Id: To: "tcpm@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 23 Mar 2010 02:04:13.0780 (UTC) FILETIME=[22B05140:01CACA2D] Cc: tsv-ads@tools.ietf.org Subject: [tcpm] Second TCPM session on Wednesday, 10:15 AM 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, 23 Mar 2010 02:04:01 -0000 The TCPM agenda has filled up, and we really want to have some time to = work on the TCP security document. So, we have gotten a second time = slot, on Wednesday morning at 10:15 AM in Pacific A. The goal of this = second session is to go through the TCP Security document and try to = identify what items everyone agrees with, and what items are = contentious. =46rom this we would be able to take the easy ones and get = them formatted up pretty quickly, and allow the mailing list discussions = to focus on the items that need discussion. -David Borman and Wes Eddy, TCPM co-chairs.= From johnwheffner@gmail.com Mon Mar 22 19:15:05 2010 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 770BF3A6817 for ; Mon, 22 Mar 2010 19:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 p87NOeQkxV+w for ; Mon, 22 Mar 2010 19:15:04 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id A5E873A6968 for ; Mon, 22 Mar 2010 19:15:00 -0700 (PDT) Received: by wwg30 with SMTP id 30so2738689wwg.31 for ; Mon, 22 Mar 2010 19:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KXyrE1EnxkJGRLfx7O+nqkWd8uUMdlP2kKYT9qIEsLU=; b=oFLoDBRoga/fIvmAfGZ24lwHLJp3urkHsv57iITJ3N/3ZvFBWwWK2BUz7FHkcwKavr cHjINX8UbHcieZfOq1iikavzHSxJmyI32QqrsE2toxXHwOB05zlqmEjFpPVLVOHq77d4 SzFzuKKUXqfo9+vUcT206rvxcu8MGxbG4tI1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i4CpDIcDuROOzjSrZ8zgRDHhmeF8lBPorlJb95U0PIGvfpJeaIY7I4FkYB0gX64gCR aWX5Qz3qv07boIKoVqfXbYxE4On2kZT0igfAZpOmrcfLW7MkQo1syGE+DrmOBKRj5wcM YRCvSu8elFIWwl98L14JuwJrP5hwpXpHPbi28= MIME-Version: 1.0 Received: by 10.216.179.133 with SMTP id h5mr2353190wem.62.1269310514130; Mon, 22 Mar 2010 19:15:14 -0700 (PDT) In-Reply-To: <4BA7FFA2.4020800@cisco.com> References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> Date: Mon, 22 Mar 2010 22:15:14 -0400 Message-ID: <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> From: John Heffner To: Mahesh Jethanandani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 02:15:05 -0000 On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John, > > On 3/22/2010 2:41 PM, John Heffner wrote: >> I read the new version of this draft. =A0For the record, my opinion >> hasn't changed since the -00 version, which is that publication of >> this draft as an RFC would be harmful. =A0I don't object to the simple >> clarifying statement that a connection may be aborted while in the >> persist state. =A0(I'm not sure this requires a new RFC.) =A0However, th= is >> draft goes beyond that, implying that connections should be aborted >> *because* they are in persist state. > > Where in the draft do we imply that "connections should be aborted > *because* they are in persist state"? We are not implying that > connections SHOULD be aborted because they are in persist state. Instead > we are suggesting that connections should be *allowed* to be aborted in > persist state. Currently RFC 1122 language is ambiguous in this regard > when connections go into indefinite wait in ZWP condition. I'm pretty sure Section 7 describes automatically aborting connections because they are in the persist state for some period of time. -John From MBashyam@OcarinaNetworks.com Mon Mar 22 23:36:47 2010 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 143023A69B7 for ; Mon, 22 Mar 2010 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.765 X-Spam-Level: ** X-Spam-Status: No, score=2.765 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, IP_NOT_FRIENDLY=0.334] 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 eBNMOZWKKJtd for ; Mon, 22 Mar 2010 23:36:46 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 2DC0E3A69B4 for ; Mon, 22 Mar 2010 23:36:46 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Mon, 22 Mar 2010 23:38:51 -0700 From: Murali Bashyam To: John Heffner , Mahesh Jethanandani Date: Mon, 22 Mar 2010 23:38:47 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrKLvSsbJhV1HnYQweQxSqhZK7bjQAItxKg Message-ID: References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> In-Reply-To: <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 06:36:47 -0000 There is no Section 7 in RFC 1122.=20 Section 4.2.2.17 states that "As long as the receiving TCP continues to sen= d acknowledgments in response to the probe segments, the sending TCP MUST a= llow the connection to stay open." This is the guideline that implementatio= ns have followed. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joh= n Heffner Sent: Monday, March 22, 2010 7:15 PM To: Mahesh Jethanandani Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John, > > On 3/22/2010 2:41 PM, John Heffner wrote: >> I read the new version of this draft. =A0For the record, my opinion >> hasn't changed since the -00 version, which is that publication of >> this draft as an RFC would be harmful. =A0I don't object to the simple >> clarifying statement that a connection may be aborted while in the >> persist state. =A0(I'm not sure this requires a new RFC.) =A0However, th= is >> draft goes beyond that, implying that connections should be aborted >> *because* they are in persist state. > > Where in the draft do we imply that "connections should be aborted > *because* they are in persist state"? We are not implying that > connections SHOULD be aborted because they are in persist state. Instead > we are suggesting that connections should be *allowed* to be aborted in > persist state. Currently RFC 1122 language is ambiguous in this regard > when connections go into indefinite wait in ZWP condition. I'm pretty sure Section 7 describes automatically aborting connections because they are in the persist state for some period of time. -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Mon Mar 22 23:59:33 2010 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 218133A6930 for ; Mon, 22 Mar 2010 23:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.431 X-Spam-Level: ** X-Spam-Status: No, score=2.431 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431] 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 UWR1G-lCKh2P for ; Mon, 22 Mar 2010 23:59:32 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 5ADB03A6890 for ; Mon, 22 Mar 2010 23:59:32 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2N6vnpB020289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Mar 2010 23:57:52 -0700 (PDT) Message-ID: <4BA8666D.7050106@isi.edu> Date: Mon, 22 Mar 2010 23:57:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Murali Bashyam References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4C99127AFDB08E01B1F9C94F" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 06:59:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4C99127AFDB08E01B1F9C94F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First, John is talking about Section 7 of your doc. Second, there are a few parts of the doc that do need to be discussed, notably anything that goes beyond "and it's always been the case that a TCP connection can be terminated by the OS". In particular, Section 7 defines an API that is beyond the scope of this recommendation, IMO. But that's separate from taking this doc on. Let's finish that decision first, right? Joe Murali Bashyam wrote: > There is no Section 7 in RFC 1122.=20 >=20 > Section 4.2.2.17 states that "As long as the receiving TCP continues to= send acknowledgments in response to the probe segments, the sending TCP = MUST allow the connection to stay open." This is the guideline that imple= mentations have followed. >=20 >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of= John Heffner > Sent: Monday, March 22, 2010 7:15 PM > To: Mahesh Jethanandani > Cc: tcpm@ietf.org > Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 >=20 > On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani = wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> John, >> >> On 3/22/2010 2:41 PM, John Heffner wrote: >>> I read the new version of this draft. For the record, my opinion >>> hasn't changed since the -00 version, which is that publication of >>> this draft as an RFC would be harmful. I don't object to the simple >>> clarifying statement that a connection may be aborted while in the >>> persist state. (I'm not sure this requires a new RFC.) However, thi= s >>> draft goes beyond that, implying that connections should be aborted >>> *because* they are in persist state. >> Where in the draft do we imply that "connections should be aborted >> *because* they are in persist state"? We are not implying that >> connections SHOULD be aborted because they are in persist state. Inste= ad >> we are suggesting that connections should be *allowed* to be aborted i= n >> persist state. Currently RFC 1122 language is ambiguous in this regard= >> when connections go into indefinite wait in ZWP condition. >=20 > I'm pretty sure Section 7 describes automatically aborting connections > because they are in the persist state for some period of time. >=20 > -John > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enig4C99127AFDB08E01B1F9C94F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuoZm0ACgkQE5f5cImnZrtFGACgua4sXX+Avol3b2kX6RnErbqu NyIAn06F45jUvJYJi2C/VGJTnw6JL3QT =sMzP -----END PGP SIGNATURE----- --------------enig4C99127AFDB08E01B1F9C94F-- From MBashyam@OcarinaNetworks.com Tue Mar 23 00:34:16 2010 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 D9B273A6813 for ; Tue, 23 Mar 2010 00:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.745 X-Spam-Level: * X-Spam-Status: No, score=1.745 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] 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 M35HX87w516B for ; Tue, 23 Mar 2010 00:34:16 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 0C4203A67FB for ; Tue, 23 Mar 2010 00:34:16 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Tue, 23 Mar 2010 00:36:21 -0700 From: Murali Bashyam To: Joe Touch Date: Tue, 23 Mar 2010 00:36:17 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrKVrAaOmSTAaWkTnKE2BSbeqBFWQAAK8/A Message-ID: References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> <4BA8666D.7050106@isi.edu> In-Reply-To: <4BA8666D.7050106@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 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 07:34:16 -0000 Ok, I misunderstood the reference, my mistake. This email discussion is for the adoption, and we are making a case for it = purely based on the recommendation of 1122, and the consequent behavior of = the widely deployed implementations out there under these conditions (wait = indefinitely). Given this data, it beats me as to where the disagreement about adoption ca= n be. -----Original Message----- From: Joe Touch [mailto:touch@ISI.EDU]=20 Sent: Monday, March 22, 2010 11:58 PM To: Murali Bashyam Cc: John Heffner; Mahesh Jethanandani; tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 First, John is talking about Section 7 of your doc. Second, there are a few parts of the doc that do need to be discussed, nota= bly anything that goes beyond "and it's always been the case that a TCP con= nection can be terminated by the OS". In particular, Section 7 defines an A= PI that is beyond the scope of this recommendation, IMO. But that's separate from taking this doc on. Let's finish that decision fir= st, right? Joe Murali Bashyam wrote: > There is no Section 7 in RFC 1122.=20 >=20 > Section 4.2.2.17 states that "As long as the receiving TCP continues to s= end acknowledgments in response to the probe segments, the sending TCP MUST= allow the connection to stay open." This is the guideline that implementat= ions have followed. >=20 >=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf=20 > Of John Heffner > Sent: Monday, March 22, 2010 7:15 PM > To: Mahesh Jethanandani > Cc: tcpm@ietf.org > Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 >=20 > On Mon, Mar 22, 2010 at 7:39 PM, Mahesh Jethanandani w= rote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> John, >> >> On 3/22/2010 2:41 PM, John Heffner wrote: >>> I read the new version of this draft. For the record, my opinion=20 >>> hasn't changed since the -00 version, which is that publication of=20 >>> this draft as an RFC would be harmful. I don't object to the simple=20 >>> clarifying statement that a connection may be aborted while in the=20 >>> persist state. (I'm not sure this requires a new RFC.) However,=20 >>> this draft goes beyond that, implying that connections should be=20 >>> aborted >>> *because* they are in persist state. >> Where in the draft do we imply that "connections should be aborted >> *because* they are in persist state"? We are not implying that=20 >> connections SHOULD be aborted because they are in persist state.=20 >> Instead we are suggesting that connections should be *allowed* to be=20 >> aborted in persist state. Currently RFC 1122 language is ambiguous in=20 >> this regard when connections go into indefinite wait in ZWP condition. >=20 > I'm pretty sure Section 7 describes automatically aborting connections=20 > because they are in the persist state for some period of time. >=20 > -John > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@ISI.EDU Tue Mar 23 09:03:56 2010 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 11AAF3A6928 for ; Tue, 23 Mar 2010 09:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.781 X-Spam-Level: * X-Spam-Status: No, score=1.781 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 yf5D7vXn-jiI for ; Tue, 23 Mar 2010 09:03:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 93DBB3A6830 for ; Tue, 23 Mar 2010 09:03:53 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2NG1BOp000852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 09:01:13 -0700 (PDT) Message-ID: <4BA8E5C6.8010509@isi.edu> Date: Tue, 23 Mar 2010 09:01:10 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27C90D7884A7DB13DE59C888" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 16:03:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27C90D7884A7DB13DE59C888 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yet another attempt to redefine TCP fields as providing "security". By randomizing the initial timestamp, we now need to keep per-connection timestamp offsets, which increases both state and processing. It also means that incoming connections to socket pairs in TIME_WAIT would silently fail roughly half the time, requiring undue timeouts. I don't think this represents an appropriate recommendation for the community, and oppose making it a WG doc. Joe Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote: > Hello, Fernando has made an update to his draft on the > generation of TCP timestamps, and asked us to poll the > TCPM WG to have this particular document adopted as a > WG draft for BCP. >=20 > http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-03 >=20 > This was briefly discussed at IETF 73 in Minneapolis, > and the decision was delayed until more people had read > it. >=20 > Please respond if you either: >=20 > (1) Support making this document a WG document with the > target for BCP. >=20 > (2) Oppose making this document a WG document. >=20 > Of course, other comments are also welcome :). >=20 > It's relatively short, so if people could respond in the > next 2 weeks, this would allow us to determine consensus > during the week of the IETF meeting. >=20 >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enig27C90D7884A7DB13DE59C888 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuo5cYACgkQE5f5cImnZrsiSQCfR5g4CGCVo/KqbjEWXwY7MpMI sgwAnj1l3erZo/0P/Ty0uKQJLP1z7oGq =ZBZ3 -----END PGP SIGNATURE----- --------------enig27C90D7884A7DB13DE59C888-- From mahesh@cisco.com Tue Mar 23 10:12:06 2010 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 5C01E3A681C for ; Tue, 23 Mar 2010 10:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 DlqMVEzDHZBB for ; Tue, 23 Mar 2010 10:12:01 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E08C33A69AE for ; Tue, 23 Mar 2010 10:10:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAOTqEurR7Ht/2dsb2JhbACbKXOkIJkvhH0Egx6GYw X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="104470918" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2010 17:11:16 +0000 Received: from [10.21.107.174] (sjc-vpnasa-942.cisco.com [10.21.107.174]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2NHBGAK024673; Tue, 23 Mar 2010 17:11:16 GMT Message-ID: <4BA8F634.6010707@cisco.com> Date: Tue, 23 Mar 2010 10:11:16 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: John Heffner References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> In-Reply-To: <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 17:12:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/22/2010 7:15 PM, John Heffner wrote: > I'm pretty sure Section 7 describes automatically aborting connections > because they are in the persist state for some period of time. Since your concern is about the wording of section 7 you can help us reword it to remove any doubts that you might have. Do you want to do that? - -- *Mahesh Jethanandani* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLqPY0AAoJEP9ZPWIqKBmiVssH/2Lp7nO/3c36Ehjbs6hWL6HW gq2fGRz/SR6dm0ZR1551LfpCNSuC3Jn53DYjGILSFr2m2kzrh9KSFgjKEzBHssE0 8WYih30ufdTv6M9XYGhrlLq5uX5bgDAlEJP4NfmjS4B9BgW5DP95rG3PN+r/jCCb mLFIuOjhGyZfCYEniZHnT+TpyPS71msaLzKrXCFnWHY1Y1ybaHz8lHp9oBykTIpv AwE90PHSRCWP/RHYmr9d7hAagJ6Xmuruh4KSomn3BsbZHzxpOAQ8SkdHXAuPcv9u 4iBIQtXlz5X7EseJcORxHPV6e2OISizjkcIBxZ9qOo3hr/w0HteW50hZMbCyGjg= =PAr7 -----END PGP SIGNATURE----- From fernando@gont.com.ar Tue Mar 23 10:23:10 2010 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 05D283A6910 for ; Tue, 23 Mar 2010 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.131 X-Spam-Level: X-Spam-Status: No, score=0.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 1eheknN8tmaz for ; Tue, 23 Mar 2010 10:23:09 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B161B3A6C17 for ; Tue, 23 Mar 2010 10:23:07 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AEF5D6B6A03; Tue, 23 Mar 2010 14:23:27 -0300 (ART) Received: from [192.168.0.126] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2NHNLvn014841; Tue, 23 Mar 2010 14:23:22 -0300 Message-ID: <4BA8F90C.6040703@gont.com.ar> Date: Tue, 23 Mar 2010 14:23:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4BA8E5C6.8010509@isi.edu> In-Reply-To: <4BA8E5C6.8010509@isi.edu> X-Enigmail-Version: 0.96.0 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, 23 Mar 2010 14:23:26 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 17:23:10 -0000 Hi, Joe, > By randomizing the initial timestamp, we now need to keep per-connection > timestamp offsets, which increases both state and processing. Huh? I don't follow this. Could you clarify what's the "extra state" and "extra processing" you're referring to? > It also > means that incoming connections to socket pairs in TIME_WAIT would > silently fail roughly half the time, requiring undue timeouts. Joe, please read the I-D. It's *without* this RFC1948-like scheme that timeouts/delays could occur. -- this mod actually improves the handling of incoming connection requests (SYNs), allowing connections that would have otherwise failed. (see also the reference to Mike Silbersack's presentation at BSDCan) 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 johnwheffner@gmail.com Tue Mar 23 10:28:44 2010 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 300E83A6A56 for ; Tue, 23 Mar 2010 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.031 X-Spam-Level: **** X-Spam-Status: No, score=4.031 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_19=0.6, MANGLED_OFF=2.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 wWbE8qAuGYDX for ; Tue, 23 Mar 2010 10:28:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 263193A6957 for ; Tue, 23 Mar 2010 10:28:42 -0700 (PDT) Received: by wyb29 with SMTP id 29so3157201wyb.31 for ; Tue, 23 Mar 2010 10:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vLuUZEwMvMFP3CDbIEglF5dcZz9HBryeYi578xBGSnA=; b=VM+AbSPw/EolcDc/UD8uu/hKKoPzc2Vgx70yajjWHxkJwzss/+et7gDiurRbt9U66B cSSvocACMo7qP1AX5k/l2Ueicjts6Xsb0A5PaefVoaK2OtUe26yh29s4Nqs7rBVzmNNG ezXEK3yUygUAvEpBq7x0G/39SlMwlHsUZWLC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GR9wCWpWAuJzcEN2g1dUJ0kordCdVs6mvBRGlgdtOoAVgGUGb1sCvxBjMPWuWICpb/ j+T52nC1nQWcp3ctSM2wX68iifaJsBtw+GaKxggE8TmQRgOegnIgeGw5zreliHvTc5Me OoImsmxlQU+gC7KdOK5curTwC40YtdA2fLuJE= MIME-Version: 1.0 Received: by 10.216.85.143 with SMTP id u15mr1280422wee.205.1269365337450; Tue, 23 Mar 2010 10:28:57 -0700 (PDT) In-Reply-To: <4BA8E5C6.8010509@isi.edu> References: <4BA8E5C6.8010509@isi.edu> Date: Tue, 23 Mar 2010 13:28:56 -0400 Message-ID: <1e41a3231003231028n413e59c0w36e03b752aa9eeff@mail.gmail.com> From: John Heffner To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 17:28:44 -0000 On Tue, Mar 23, 2010 at 12:01 PM, Joe Touch wrote: > By randomizing the initial timestamp, we now need to keep per-connection > timestamp offsets, which increases both state and processing. It also > means that incoming connections to socket pairs in TIME_WAIT would > silently fail roughly half the time, requiring undue timeouts. If I understand correctly, that's not the case. The function from Section 2: timestamp = T() + F(localhost, localport, remotehost, remoteport, secret_key) has no per-connection state*, and should not result in any issues with TIME_WAIT connections. Though it does not say so explicitly, my understanding is that secret_key is intended to be a system-wide value initialized on boot with random data.. It seems like a very reasonable approach to me -- low-cost and easy to implement with no major downsides. -John * I guess there would be some soft state, because you'll want to cache the value of F(). From touch@ISI.EDU Tue Mar 23 11:00:06 2010 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 B5BB33A683C for ; Tue, 23 Mar 2010 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.364 X-Spam-Level: ** X-Spam-Status: No, score=2.364 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_19=0.6, MANGLED_OFF=2.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 5l+DaBVKRLv9 for ; Tue, 23 Mar 2010 11:00:06 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 758CC3A6D39 for ; Tue, 23 Mar 2010 10:51:17 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2NHoXlY029117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 10:50:34 -0700 (PDT) Message-ID: <4BA8FF68.8040302@isi.edu> Date: Tue, 23 Mar 2010 10:50:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fernando Gont References: <4BA8E5C6.8010509@isi.edu> <4BA8F90C.6040703@gont.com.ar> In-Reply-To: <4BA8F90C.6040703@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5868E22829D72ACFF37A8053" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 18:00:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5868E22829D72ACFF37A8053 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Hi, Joe, >=20 >> By randomizing the initial timestamp, we now need to keep per-connecti= on >> timestamp offsets, which increases both state and processing.=20 >=20 > Huh? I don't follow this. Could you clarify what's the "extra state" an= d > "extra processing" you're referring to? timestamp =3D T() + F(localhost, localport, remotehost, remoteport, secret_key) Either I need to keep the result of F(...), or I need to recompute for each timestamp. The former costs processing, the latter costs state. Either way, you're adding an index and an add to the timestamp calculation. That's processing. We're talking about extra steps for every packet. >> It also >> means that incoming connections to socket pairs in TIME_WAIT would >> silently fail roughly half the time, requiring undue timeouts. >=20 > Joe, please read the I-D. It's *without* this RFC1948-like scheme that > timeouts/delays could occur. -- this mod actually improves the handling= > of incoming connection requests (SYNs), allowing connections that would= > have otherwise failed. The document never asserts that the "secret_key" would never change. If it does change, you run the risk that F(...) will end up being sufficiently lower that you fall through your checks and treat the SYN as a silent discard, which causes delays. Joe >=20 > (see also the reference to Mike Silbersack's presentation at BSDCan) >=20 > Thanks, --------------enig5868E22829D72ACFF37A8053 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuo/2gACgkQE5f5cImnZrudvgCgj+n6z1kDZXI1PlEk0vl/Vgif Y2MAnj4wODzWKFK4TRcGqz9IQmGGrwzV =QIf/ -----END PGP SIGNATURE----- --------------enig5868E22829D72ACFF37A8053-- From muraris@microsoft.com Tue Mar 23 11:25:04 2010 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 648853A6A10 for ; Tue, 23 Mar 2010 11:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.468 X-Spam-Level: X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 P3LcqRAwNQ8s for ; Tue, 23 Mar 2010 11:25:02 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6343A3A699A for ; Tue, 23 Mar 2010 11:25:01 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 23 Mar 2010 11:25:20 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.44]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Tue, 23 Mar 2010 11:25:19 -0700 From: Murari Sridharan To: "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Thread-Topic: Cloud faster Thread-Index: AcrKtiU22gxIxXLqT1SVu/poCRskww== Date: Tue, 23 Mar 2010 18:24:59 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF029138215@TK5EX14MBXC128.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bk17 DBXm DxYs D3vE E7Ce FmkE KC9R LxVe Mc/x NF6g O9G0 S/KJ UFW1 UUPy UYYG WGh4; 3; aQBjAGMAcgBnAEAAYwBzAC4AdQBjAGwALgBhAGMALgB1AGsAOwBtAGEAdABoAGkAcwBAAHAAcwBjAC4AZQBkAHUAOwB0AGMAcABtAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {2D1C6F75-ED7F-4755-A0B8-5F77759CB3B1}; bQB1AHIAYQByAGkAcwBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0A; Tue, 23 Mar 2010 18:24:59 GMT;QwBsAG8AdQBkACAAZgBhAHMAdABlAHIA x-cr-puzzleid: {2D1C6F75-ED7F-4755-A0B8-5F77759CB3B1} Content-Type: multipart/alternative; boundary="_000_03520536067DF14395EA93FE7ECFDCF029138215TK5EX14MBXC128r_" MIME-Version: 1.0 Cc: Matt Mathis , Jitu Padhye , Dave Maltz , Albert Greenberg Subject: [tcpm] Cloud faster 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, 23 Mar 2010 18:25:04 -0000 --_000_03520536067DF14395EA93FE7ECFDCF029138215TK5EX14MBXC128r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To follow up on what I mentioned at the mike, here is the work we have been= doing and we can help collect data here. http://research.microsoft.com/en-us/projects/cloudfaster/ Thanks --_000_03520536067DF14395EA93FE7ECFDCF029138215TK5EX14MBXC128r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To follow up on what I mentioned at the mike, here is = the work we have been doing and we can help collect data here.

 

http://r= esearch.microsoft.com/en-us/projects/cloudfaster/

 

Thanks

 

 

--_000_03520536067DF14395EA93FE7ECFDCF029138215TK5EX14MBXC128r_-- From fernando@gont.com.ar Tue Mar 23 11:33:51 2010 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 651FA3A67D3 for ; Tue, 23 Mar 2010 11:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.581 X-Spam-Level: * X-Spam-Status: No, score=1.581 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_19=0.6, MANGLED_OFF=2.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 8EVoa00+6cXj for ; Tue, 23 Mar 2010 11:33:50 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A15BE3A6B77 for ; Tue, 23 Mar 2010 11:33:47 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AA7B36B6644; Tue, 23 Mar 2010 15:34:08 -0300 (ART) Received: from [192.168.0.126] (61-128-17-190.fibertel.com.ar [190.17.128.61]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2NIY0pP025133; Tue, 23 Mar 2010 15:34:01 -0300 Message-ID: <4BA9099B.1050603@gont.com.ar> Date: Tue, 23 Mar 2010 15:34:03 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4BA8E5C6.8010509@isi.edu> <4BA8F90C.6040703@gont.com.ar> <4BA8FF68.8040302@isi.edu> In-Reply-To: <4BA8FF68.8040302@isi.edu> X-Enigmail-Version: 0.96.0 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, 23 Mar 2010 15:34:08 -0300 (ART) Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 18:33:51 -0000 Joe, >>> By randomizing the initial timestamp, we now need to keep per-connection >>> timestamp offsets, which increases both state and processing. >> Huh? I don't follow this. Could you clarify what's the "extra state" and >> "extra processing" you're referring to? > > timestamp = T() + F(localhost, localport, remotehost, remoteport, > secret_key) > > Either I need to keep the result of F(...), or I need to recompute for > each timestamp. The former costs processing, the latter costs state. I would argue that the benefits of this proposal outweigh e.g., the "extra state" (four bytes?) you're referring to. >>> It also >>> means that incoming connections to socket pairs in TIME_WAIT would >>> silently fail roughly half the time, requiring undue timeouts. >> Joe, please read the I-D. It's *without* this RFC1948-like scheme that >> timeouts/delays could occur. -- this mod actually improves the handling >> of incoming connection requests (SYNs), allowing connections that would >> have otherwise failed. > > The document never asserts that the "secret_key" would never change. > > If it does change, you run the risk that F(...) will end up being > sufficiently lower that you fall through your checks and treat the SYN > as a silent discard, which causes delays. I disagree. The delays are caused by RFC1337 (or by RFC793 itself), and *not* by the proposal in this I-D. i.e., the worst-case scenario of the proposal in this I-D is never worse than RFC1337 or RFC 793. That said, you may perform "heuristics" to decide when to change the key (e.g., when there has not been connections for 2MSL, or when the number of ongoing connections is really small). This should be already well understood, as the considerations for key changes are the same as for RFC1948 (for the generation of TCP ISNs). P.S.: I'm "surprised" to hear your comment, since during an informal meeting at the MPLS IETF with me and David Borman, you did support this I-D. P.S.: Just wanted to make my point. I won't respond further messages unless I have something else to add (not previously stated), in the hopes of keeping the S/N ratio of this list at a decent level. 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 johnwheffner@gmail.com Tue Mar 23 11:35:01 2010 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 2BAD03A6B86 for ; Tue, 23 Mar 2010 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.281 X-Spam-Level: * X-Spam-Status: No, score=1.281 tagged_above=-999 required=5 tests=[AWL=2.750, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 oLpsXSboPR0w for ; Tue, 23 Mar 2010 11:34:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1B8F23A6874 for ; Tue, 23 Mar 2010 11:34:55 -0700 (PDT) Received: by wwg30 with SMTP id 30so3268054wwg.31 for ; Tue, 23 Mar 2010 11:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=30kybrvs1FslDfzXoQLvyNBMmmJHbt3AArDCLYnoJxI=; b=M23ZuJoXYjNdd5S0tWcyda4DGb0zB53yd6o9sBU3MZH57K8gn7knjuTgEDD3k8CN3J 6G+IXVRlMmSlA13tgayOKWe1sD9l2hXRQcZ6Q+kLiss5fyWvk3lqpcTW9d/nLvtyskwH +JixrdoyNYpvVXT29vgZ6aAAmhGqreKuU1PmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=blVjWYWbhmEb0+GvssBQlrfNu7XoTMJIbKY03B13ZBkdDpqWeVsjmOx11nWqHQJ6rE JN5B5ohAt8vrtWIowNs8hzHtvnWaig+kZBY60b0CAwEnloO69rUYk7lcWM6scnXzXFpj M5e8QwVkQhp+XPwZ/yON4KnmVQf89bhjobtWE= MIME-Version: 1.0 Received: by 10.216.86.131 with SMTP id w3mr4138774wee.156.1269369312004; Tue, 23 Mar 2010 11:35:12 -0700 (PDT) In-Reply-To: <4BA8F634.6010707@cisco.com> References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> <4BA8F634.6010707@cisco.com> Date: Tue, 23 Mar 2010 14:35:11 -0400 Message-ID: <1e41a3231003231135t7daf61e7i3ce94613d2b2ea8e@mail.gmail.com> From: John Heffner To: Mahesh Jethanandani Content-Type: text/plain; charset=ISO-8859-1 Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 18:35:01 -0000 Here's all I think needs to be said (at all, not just section 7), but I'm a minimalist. :) ---- Section 4.2.2.17 of RFC 1122 states: A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. To clarify, the above statement is not meant to restrict the ABORT command [RFC793] in any way. TCP should react to an ABORT in the same way regardless of the current receive window. ---- -John On Tue, Mar 23, 2010 at 1:11 PM, Mahesh Jethanandani wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 3/22/2010 7:15 PM, John Heffner wrote: > >> I'm pretty sure Section 7 describes automatically aborting connections >> because they are in the persist state for some period of time. > > Since your concern is about the wording of section 7 you can help us > reword it to remove any doubts that you might have. > > Do you want to do that? > > - -- > *Mahesh Jethanandani* > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLqPY0AAoJEP9ZPWIqKBmiVssH/2Lp7nO/3c36Ehjbs6hWL6HW > gq2fGRz/SR6dm0ZR1551LfpCNSuC3Jn53DYjGILSFr2m2kzrh9KSFgjKEzBHssE0 > 8WYih30ufdTv6M9XYGhrlLq5uX5bgDAlEJP4NfmjS4B9BgW5DP95rG3PN+r/jCCb > mLFIuOjhGyZfCYEniZHnT+TpyPS71msaLzKrXCFnWHY1Y1ybaHz8lHp9oBykTIpv > AwE90PHSRCWP/RHYmr9d7hAagJ6Xmuruh4KSomn3BsbZHzxpOAQ8SkdHXAuPcv9u > 4iBIQtXlz5X7EseJcORxHPV6e2OISizjkcIBxZ9qOo3hr/w0HteW50hZMbCyGjg= > =PAr7 > -----END PGP SIGNATURE----- > From mallman@icir.org Tue Mar 23 12:05:02 2010 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 659213A6958 for ; Tue, 23 Mar 2010 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 NX3x1WUw+5g4 for ; Tue, 23 Mar 2010 12:05:01 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 7BCCE3A6B59 for ; Tue, 23 Mar 2010 12:04:57 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2NJ5Fcr004821; Tue, 23 Mar 2010 12:05:16 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C7B4BBAF5D0; Tue, 23 Mar 2010 15:05:15 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4BA8E5C6.8010509@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma4331-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 23 Mar 2010 15:05:15 -0400 Sender: mallman@icir.org Message-Id: <20100323190515.C7B4BBAF5D0@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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: Tue, 23 Mar 2010 19:05:02 -0000 ----------ma4331-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Yet another attempt to redefine TCP fields as providing "security". Yeah, that's pretty bogus. But, I don't think the rest of your argument holds much water. In particular, - Yeah, more state, but not a lot more state. Yeah, more computation, but not a lot more computation. I think if moved forward this would be something like a MAY or a SHOULD, not a MUST. So, if someone had a good reason (and sometimes state and computation are in short supply) and they didn't want to do this, fine. - Perhaps the document needs clarification on the secret portion of the computation, but I don't buy that this will unduly cause issues. Worst case, we're where we are now---i.e., you discard SYNs until the end of TIME_WAIT. Best case, we understand that a new connection is a new connection and we can truncate TIME_WAIT. I just don't see the big worry here. If its optionally keeping a long around and doing an add / packet I think that is a quite minor complaint. On the other hand, is this really *needed*? No, absolutely not. The client has the needed control right now in that it can just use a different ephemeral port for each connection. And, unless you have some sort of Really Pathological Case then you're not going to need to re-use ephemerals often enough to hit a problem with everything being wedged in TIME_WAIT. So, don't get me wrong, I won't be terribly sad to see this just go away. But, it seems to me that plenty of people think its reasonable enough that the WG should take it on. And, in the absence of any actual big issues it seems to be like that ought to be enough. allman ----------ma4331-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkupEOsACgkQWyrrWs4yIs4fiACgnIFZiQIAPVaJqwWTW+5zrhyX KIQAoIunlSUnVUB79QowJqDzcXf5NURe =LDnp -----END PGP SIGNATURE----- ----------ma4331-1-- From touch@ISI.EDU Tue Mar 23 12:33:11 2010 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 EE3263A6984 for ; Tue, 23 Mar 2010 12:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 vTO5Enbf9Zdx for ; Tue, 23 Mar 2010 12:33:11 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id CA3263A69D5 for ; Tue, 23 Mar 2010 12:32:48 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2NJVdNL000093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 12:31:40 -0700 (PDT) Message-ID: <4BA9171A.6030804@isi.edu> Date: Tue, 23 Mar 2010 12:31:38 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100323190515.C7B4BBAF5D0@lawyers.icir.org> In-Reply-To: <20100323190515.C7B4BBAF5D0@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62F5FB5ADAB1926F489C7711" X-MailScanner-ID: o2NJVdNL000093 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 23 Mar 2010 19:33:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62F5FB5ADAB1926F489C7711 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See below... Mark Allman wrote: >> Yet another attempt to redefine TCP fields as providing "security". >=20 > Yeah, that's pretty bogus. >=20 > But, I don't think the rest of your argument holds much water. In > particular,=20 >=20 > - Yeah, more state, but not a lot more state. Yeah, more computation= , > but not a lot more computation. I think if moved forward this woul= d > be something like a MAY or a SHOULD, not a MUST. So, if someone ha= d > a good reason (and sometimes state and computation are in short > supply) and they didn't want to do this, fine. >=20 > - Perhaps the document needs clarification on the secret portion of > the computation, but I don't buy that this will unduly cause issues= =2E > Worst case, we're where we are now---i.e., you discard SYNs until > the end of TIME_WAIT. Best case, we understand that a new > connection is a new connection and we can truncate TIME_WAIT. >=20 > I just don't see the big worry here. If its optionally keeping a long > around and doing an add / packet I think that is a quite minor > complaint.=20 >=20 > On the other hand, is this really *needed*? No, absolutely not. So then why bother? Are we in favor of just adding state and computation to TCP? Consider benefit vs the cost, where cost is not just state and processing, but also specification complexity. And it's useful to consider that this isn't the only such mod coming down the pike. We just got done recommending random ephemeral ports. Now we want random timestamp offsets. How much of this do we actually need, and can we just keep it simple other than that? > The > client has the needed control right now in that it can just use a > different ephemeral port for each connection. And, unless you have som= e > sort of Really Pathological Case then you're not going to need to re-us= e > ephemerals often enough to hit a problem with everything being wedged i= n > TIME_WAIT. So, don't get me wrong, I won't be terribly sad to see this= > just go away. But, it seems to me that plenty of people think its > reasonable enough that the WG should take it on. And, in the absence o= f > any actual big issues it seems to be like that ought to be enough. IMO, the threshold for changing TCP ought to be "do we absolutely need it", not "absent big issues and seems reasonable". Joe --------------enig62F5FB5ADAB1926F489C7711 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkupFxoACgkQE5f5cImnZrvVrgCfZ8HYpS+CYr7f6o7OYc4TKLPi 5+UAn14KF3f3trw0QdS2cHWrSZ85xZ9T =Vq8n -----END PGP SIGNATURE----- --------------enig62F5FB5ADAB1926F489C7711-- From mallman@icir.org Tue Mar 23 12:42:59 2010 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 DAD863A68C0 for ; Tue, 23 Mar 2010 12:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=1.625, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 iDpzy6sjTSnj for ; Tue, 23 Mar 2010 12:42:58 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 229FE3A683E for ; Tue, 23 Mar 2010 12:42:53 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2NJhBGq010883; Tue, 23 Mar 2010 12:43:12 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B2D45BAFA6B; Tue, 23 Mar 2010 15:43:11 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4BA9171A.6030804@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma6607-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 23 Mar 2010 15:43:11 -0400 Sender: mallman@icir.org Message-Id: <20100323194311.B2D45BAFA6B@lawyers.icir.org> Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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: Tue, 23 Mar 2010 19:43:00 -0000 ----------ma6607-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe- > IMO, the threshold for changing TCP ought to be "do we absolutely need > it", not "absent big issues and seems reasonable". I don't buy that bar. Some of your work is not absolutely needed. (Mine, too, BTW.) Doesn't mean it isn't useful. The "bar" is a fuzzy thing. You don't find the cost-v-benefit for this worthwhile. Fine. I assume the chairs are noting that. Others find it worthwhile. I assume the chairs are noting that, as well. So, lets just---you and I---consider our points made. allman ----------ma6607-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkupGc8ACgkQWyrrWs4yIs65iwCgnWb+qsb/fBhyD8KyQBYb5oJp 4VUAn1WX8ScDmyNMMNoqt0En55Uxk+r8 =ACyB -----END PGP SIGNATURE----- ----------ma6607-1-- From root@core3.amsl.com Tue Mar 23 14:15:06 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 28FA23A6BD1; Tue, 23 Mar 2010 14:15:05 -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: <20100323211506.28FA23A6BD1@core3.amsl.com> Date: Tue, 23 Mar 2010 14:15:05 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-11.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: Tue, 23 Mar 2010 21:15:07 -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 : The TCP Authentication Option Author(s) : J. Touch, et al. Filename : draft-ietf-tcpm-tcp-auth-opt-11.txt Pages : 48 Date : 2010-03-23 This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-11.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-auth-opt-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-23140428.I-D@ietf.org> --NextPart-- From touch@ISI.EDU Tue Mar 23 14:22:21 2010 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 93F403A6CA8; Tue, 23 Mar 2010 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[AWL=1.284, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 lzKURaRiD84R; Tue, 23 Mar 2010 14:22:18 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9E47F3A68DC; Tue, 23 Mar 2010 14:22:18 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2NLLmg2017296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 14:21:50 -0700 (PDT) Message-ID: <4BA930EC.6040502@isi.edu> Date: Tue, 23 Mar 2010 14:21:48 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Internet-Drafts@ietf.org References: <20100323211506.28FA23A6BD1@core3.amsl.com> In-Reply-To: <20100323211506.28FA23A6BD1@core3.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEC02D0E32135003CA2530742" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-11.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: Tue, 23 Mar 2010 21:22:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC02D0E32135003CA2530742 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, The revisions in this document address the IESG DISCUSS issues. Joe Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the TCP Maintenance and Minor Extensions W= orking Group of the IETF. >=20 >=20 > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-11.txt > Pages : 48 > Date : 2010-03-23 >=20 > This document specifies the TCP Authentication Option (TCP-AO), which > obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO > specifies the use of stronger Message Authentication Codes (MACs), > protects against replays even for long-lived TCP connections, and > provides more details on the association of security with TCP > connections than TCP MD5. TCP-AO is compatible with either static > master key tuple (MKT) configuration or an external, out-of-band MKT > management mechanism; in either case, TCP-AO also protects > connections when using the same MKT across repeated instances of a > connection, using traffic keys derived from the MKT, and coordinates > MKT changes between endpoints. The result is intended to support > current infrastructure uses of TCP MD5, such as to protect long-lived > connections (as used, e.g., in BGP and LDP), and to support a larger > set of MACs with minimal other system and operational changes. TCP-AO > uses a different option identifier than TCP MD5, even though TCP-AO > and TCP MD5 are never permitted to be used simultaneously. TCP-AO > supports IPv6, and is fully compatible with the proposed requirements > for the replacement of TCP MD5. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-11.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------enigEC02D0E32135003CA2530742 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkupMOwACgkQE5f5cImnZrsiuACgp0DxTqrtB+N5AtcJHNwI4uOw ruwAoIWxLjysdEH044RAdNaYMgVZl9JI =qFd+ -----END PGP SIGNATURE----- --------------enigEC02D0E32135003CA2530742-- From L.Wood@surrey.ac.uk Tue Mar 23 14:24:57 2010 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 994B13A6B63; Tue, 23 Mar 2010 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 6TDsOuQ4J1w5; Tue, 23 Mar 2010 14:24:52 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 6C3013A67F2; Tue, 23 Mar 2010 14:24:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-82.messagelabs.com!1269379509!2364454!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.35] Received: (qmail 9155 invoked from network); 23 Mar 2010 21:25:09 -0000 Received: from unknown (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-4.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 23 Mar 2010 21:25:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.49]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Tue, 23 Mar 2010 21:25:09 +0000 From: To: , Date: Tue, 23 Mar 2010 21:24:23 +0000 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-11.txt Thread-Index: AcrKzv5zo00r3V3tST+HVwcIjA4xYAAADbxM Message-ID: References: <20100323211506.28FA23A6BD1@core3.amsl.com>, <4BA930EC.6040502@isi.edu> In-Reply-To: <4BA930EC.6040502@isi.edu> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tcpm@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-11.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: Tue, 23 Mar 2010 21:24:57 -0000 Dp we absolutely need this document? L. ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Joe Touch = [touch@ISI.EDU] Sent: 23 March 2010 21:21 To: Internet-Drafts@ietf.org Cc: tcpm@ietf.org; i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-11.txt Hi, all, The revisions in this document address the IESG DISCUSS issues. Joe Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TCP Maintenance and Minor Extensions Wor= king Group of the IETF. > > > Title : The TCP Authentication Option > Author(s) : J. Touch, et al. > Filename : draft-ietf-tcpm-tcp-auth-opt-11.txt > Pages : 48 > Date : 2010-03-23 > > This document specifies the TCP Authentication Option (TCP-AO), which > obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO > specifies the use of stronger Message Authentication Codes (MACs), > protects against replays even for long-lived TCP connections, and > provides more details on the association of security with TCP > connections than TCP MD5. TCP-AO is compatible with either static > master key tuple (MKT) configuration or an external, out-of-band MKT > management mechanism; in either case, TCP-AO also protects > connections when using the same MKT across repeated instances of a > connection, using traffic keys derived from the MKT, and coordinates > MKT changes between endpoints. The result is intended to support > current infrastructure uses of TCP MD5, such as to protect long-lived > connections (as used, e.g., in BGP and LDP), and to support a larger > set of MACs with minimal other system and operational changes. TCP-AO > uses a different option identifier than TCP MD5, even though TCP-AO > and TCP MD5 are never permitted to be used simultaneously. TCP-AO > supports IPv6, and is fully compatible with the proposed requirements > for the replacement of TCP MD5. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-11.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From muraris@microsoft.com Tue Mar 23 14:38:19 2010 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 8C3A43A6946 for ; Tue, 23 Mar 2010 14:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.168 X-Spam-Level: X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gxM50DbjufkS for ; Tue, 23 Mar 2010 14:38:18 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 6B2CA3A68DC for ; Tue, 23 Mar 2010 14:38:18 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 23 Mar 2010 14:38:38 -0700 Received: from TK5EX14MBXC128.redmond.corp.microsoft.com ([169.254.7.44]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi; Tue, 23 Mar 2010 14:38:37 -0700 From: Murari Sridharan To: "tcpm@ietf.org" , "iccrg@cs.ucl.ac.uk" Thread-Topic: Increasing ICW Thread-Index: AQHKytExWNOSVn3gF0CmWjqzyVkYTw== Date: Tue, 23 Mar 2010 21:38:29 +0000 Message-ID: <03520536067DF14395EA93FE7ECFDCF029138C6B@TK5EX14MBXC128.redmond.corp.microsoft.com> References: <03520536067DF14395EA93FE7ECFDCF029138215@TK5EX14MBXC128.redmond.corp.microsoft.com> In-Reply-To: <03520536067DF14395EA93FE7ECFDCF029138215@TK5EX14MBXC128.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_03520536067DF14395EA93FE7ECFDCF029138C6BTK5EX14MBXC128r_" MIME-Version: 1.0 Cc: Jitu Padhye , Dave Maltz , Albert Greenberg Subject: [tcpm] Increasing ICW 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, 23 Mar 2010 21:38:19 -0000 --_000_03520536067DF14395EA93FE7ECFDCF029138C6BTK5EX14MBXC128r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changed the title so we can continue discussion from the meeting. Below lin= k describes the approaches we are taking to make the web faster. There are = two sets of changes one primarily for the intra-datacenter flows and the ot= her for WAN transfers. The latter work is toying with the idea of increasin= g ICW. A lot of people voiced very valid concerns. We are also very concerned th= at there may be pockets of the Internet where a large ICW burst can be prob= lematic. However as I mentioned today morning we should make a data driv= en decision. We have been experimenting and we will share our results as we= ll. This is an important discussion to have in tcpm, whether or not the current= draft should be adopted by the WG should be debated in the coming meetings= . I think we need to consider this being a application driven socket option= instead of a global setting. Thanks Murari From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mur= ari Sridharan Sent: Tuesday, March 23, 2010 11:25 AM To: tcpm@ietf.org; iccrg@cs.ucl.ac.uk Cc: Matt Mathis; Jitu Padhye; Dave Maltz; Albert Greenberg Subject: [tcpm] Cloud faster To follow up on what I mentioned at the mike, here is the work we have been= doing and we can help collect data here. http://research.microsoft.com/en-us/projects/cloudfaster/ Thanks --_000_03520536067DF14395EA93FE7ECFDCF029138C6BTK5EX14MBXC128r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Changed the title so we c= an continue discussion from the meeting. Below link describes the approaches w= e are taking to make the web faster. There are two sets of changes one primar= ily for the intra-datacenter flows and the other for WAN transfers. The latter = work is toying with the idea of increasing ICW.

  A lot of people vo= iced very valid concerns. We are also very concerned that there may be pockets o= f the Internet where a large ICW burst can be problematic. However as I menti= oned today    morning we should make a data driven decision. We h= ave been experimenting and we will share our results as well.

This is an important discussion to have in tcpm, whether or not the current draft should be adop= ted by the WG should be debated in the coming meetings. I think we need to conside= r this being a application driven socket option instead of a global setting. =

Thanks<= /p>

Murari =

 =

 =

From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Mu= rari Sridharan
Sent: Tuesday, March 23, 2010 11:25 AM
To: tcpm@ietf.org; iccrg@cs.ucl.ac.uk
Cc: Matt Mathis; Jitu Padhye; Dave Maltz; Albert Greenberg
Subject: [tcpm] Cloud faster

 

To follow up on what I mentioned at the mike, here is = the work we have been doing and we can help collect data here.

 

http://r= esearch.microsoft.com/en-us/projects/cloudfaster/

 

Thanks

 

 

--_000_03520536067DF14395EA93FE7ECFDCF029138C6BTK5EX14MBXC128r_-- From gorry@erg.abdn.ac.uk Tue Mar 23 15:15:53 2010 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 D3AD23A6BF4 for ; Tue, 23 Mar 2010 15:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-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 q3OnThlLR6om for ; Tue, 23 Mar 2010 15:15:52 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id 16A153A6CE8 for ; Tue, 23 Mar 2010 15:15:37 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-155.meeting.ietf.org ([IPv6:2001:df8:0:24:21e:c2ff:febe:4c73]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id o2NMFd9T006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 23 Mar 2010 22:15:40 GMT Message-ID: <4BA93D8A.8080508@erg.abdn.ac.uk> Date: Tue, 23 Mar 2010 15:15:38 -0700 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 22:15:53 -0000 The point I raised in TCPM today was that there are likely other side-effects from a SYN RTO expiry. I saw appendix describes a measure to protect from unwanted side effects when the RTO is less than 3 secs. I suspect reducing the SYN over a longer path, such that there is a SYN retransmission can also have other side effects. One is noted that IW is not to be effected when the first RTO expires. I suggest there should be a more general change to the draft so that the TCP sender SHOULD NOT modify startup parameters when the RTO expires within "6" seconds (or whatever period you think applies in current use. My rationale is that there are transport methods that use retransmission of a SYN as the indication that there may be something problematic with the path, and then modify their behaviour. For example, ECN-capable systems may disable the use of ECN on SYN retransmission. RFC 3168 says: "A host that receives no reply to an ECN-setup SYN within the normal SYN retransmission timeout interval MAY resend the SYN and any subsequent SYN retransmissions with CWR and ECE cleared. To overcome normal packet loss that results in the original SYN being lost, the originating host may retransmit one or more ECN-setup SYN packets before giving up and retransmitting the SYN with the CWR and ECE bits cleared." An experimental use is Quickstart (s 4.7.2) where retransmission may use a similar method: "packet containing the Quick-Start Request, then the TCP sender SHOULD resend the SYN or SYN/ACK packet without the Quick-Start Request". Could there be similar implications for IPv6/IPv4 probing? Gorry From MBashyam@OcarinaNetworks.com Tue Mar 23 15:21:38 2010 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 EDFC13A6841 for ; Tue, 23 Mar 2010 15:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.305 X-Spam-Level: X-Spam-Status: No, score=0.305 tagged_above=-999 required=5 tests=[AWL=1.440, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] 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 c3lm4Qj8qwir for ; Tue, 23 Mar 2010 15:21:31 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 0241A3A691F for ; Tue, 23 Mar 2010 15:21:24 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Tue, 23 Mar 2010 15:23:28 -0700 From: Murali Bashyam To: John Heffner , Mahesh Jethanandani Date: Tue, 23 Mar 2010 15:23:19 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrKt9ml53tX+GGiTfSHyKXBSzdMFgAGbw0w Message-ID: References: <1e41a3231003221441s57d77a53m255fbe8c00cb370@mail.gmail.com> <4BA7FFA2.4020800@cisco.com> <1e41a3231003221915n45b07a07v3a0ace6a879bb4e9@mail.gmail.com> <4BA8F634.6010707@cisco.com> <1e41a3231003231135t7daf61e7i3ce94613d2b2ea8e@mail.gmail.com> In-Reply-To: <1e41a3231003231135t7daf61e7i3ce94613d2b2ea8e@mail.gmail.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" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-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: Tue, 23 Mar 2010 22:21:38 -0000 There are other aspects too, it's also important for the application to con= trol the duration that the connection spends in persist state, this is plan= ned to be accomplished via a socket option. Both *OS and application* need = to control the duration that a connection spends in the persist state. There are scenarios when the application releases its connection state afte= r writing all the data into the socket (so called orphan connections), and = after this if the TCP connection enters into a ZWP condition, the applicati= on does not have the connection state to issue the ABORT, but if it has set= up the socket option before, then TCP can still enforce the specified durat= ion. -----Original Message----- From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Joh= n Heffner Sent: Tuesday, March 23, 2010 11:35 AM To: Mahesh Jethanandani Cc: tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 Here's all I think needs to be said (at all, not just section 7), but I'm a minimalist. :) ---- Section 4.2.2.17 of RFC 1122 states: A TCP MAY keep its offered receive window closed indefinitely. As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open. To clarify, the above statement is not meant to restrict the ABORT command [RFC793] in any way. TCP should react to an ABORT in the same way regardless of the current receive window. ---- -John On Tue, Mar 23, 2010 at 1:11 PM, Mahesh Jethanandani wro= te: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 3/22/2010 7:15 PM, John Heffner wrote: > >> I'm pretty sure Section 7 describes automatically aborting connections >> because they are in the persist state for some period of time. > > Since your concern is about the wording of section 7 you can help us > reword it to remove any doubts that you might have. > > Do you want to do that? > > - -- > *Mahesh Jethanandani* > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJLqPY0AAoJEP9ZPWIqKBmiVssH/2Lp7nO/3c36Ehjbs6hWL6HW > gq2fGRz/SR6dm0ZR1551LfpCNSuC3Jn53DYjGILSFr2m2kzrh9KSFgjKEzBHssE0 > 8WYih30ufdTv6M9XYGhrlLq5uX5bgDAlEJP4NfmjS4B9BgW5DP95rG3PN+r/jCCb > mLFIuOjhGyZfCYEniZHnT+TpyPS71msaLzKrXCFnWHY1Y1ybaHz8lHp9oBykTIpv > AwE90PHSRCWP/RHYmr9d7hAagJ6Xmuruh4KSomn3BsbZHzxpOAQ8SkdHXAuPcv9u > 4iBIQtXlz5X7EseJcORxHPV6e2OISizjkcIBxZ9qOo3hr/w0HteW50hZMbCyGjg=3D > =3DPAr7 > -----END PGP SIGNATURE----- > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From wwwrun@core3.amsl.com Tue Mar 23 16:12:49 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7C2D53A6CFC; Tue, 23 Mar 2010 16:12:49 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100323231249.7C2D53A6CFC@core3.amsl.com> Date: Tue, 23 Mar 2010 16:12:49 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'The TCP Authentication Option' to Proposed Standard 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, 23 Mar 2010 23:12:49 -0000 The IESG has approved the following document: - 'The TCP Authentication Option ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-11.txt Technical Summary This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either static master key tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. Working Group Summary There was some initial controversy on this work due to the prior rushed deployment of a similar mechanism which had not been reviewed by the WG. The WG's decision to build an incompatible mechanism was not unanimous, with strong initial resistance from one of the implementers of the prior solution, however other implementors of that solution did come out in support of the WG's product during the course of its evolution. Document Quality Several widely-deployed implementations exist of a pre-WG protocol which is not compatible with the WG's protocol, but very similar both functionally and on the wire. Some vendors have expressed strong support for implementing the WG's product. At one point, a Linux implementation was being pursued of the WG draft, though its status with regard to the current document is unknown. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From david.borman@windriver.com Tue Mar 23 17:52:53 2010 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 AC2123A69A6 for ; Tue, 23 Mar 2010 17:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 dE4h5xYxENGg for ; Tue, 23 Mar 2010 17:52:52 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 5356F3A69CF for ; Tue, 23 Mar 2010 17:52:52 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o2O0rBwq015416; Tue, 23 Mar 2010 17:53:11 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Mar 2010 17:53:11 -0700 Received: from unknown-233-80.windriver.com ([147.11.233.80]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Mar 2010 17:53:10 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: Date: Tue, 23 Mar 2010 17:53:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "tcpm@ietf.org WG" X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 24 Mar 2010 00:53:10.0640 (UTC) FILETIME=[60128700:01CACAEC] Cc: tsv-ads@tools.ietf.org Subject: Re: [tcpm] Second TCPM session on Wednesday, 10:15 AM 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, 24 Mar 2010 00:52:53 -0000 The room in which we will be meeting does not have audio or video. Is = there anyone not at the IETF meeting that would like to attend this = meeting? If so, we can see about setting up a WebEx session. Please = respond ASAP if you would like to attend via WebEx, so we can get it set = up. -David Borman On Mar 22, 2010, at 7:04 PM, David Borman wrote: > The TCPM agenda has filled up, and we really want to have some time to = work on the TCP security document. So, we have gotten a second time = slot, on Wednesday morning at 10:15 AM in Pacific A. The goal of this = second session is to go through the TCP Security document and try to = identify what items everyone agrees with, and what items are = contentious. =46rom this we would be able to take the easy ones and get = them formatted up pretty quickly, and allow the mailing list discussions = to focus on the items that need discussion. >=20 > -David Borman and Wes Eddy, TCPM co-chairs. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mallman@icir.org Tue Mar 23 20:15:12 2010 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 D0E833A69A8 for ; Tue, 23 Mar 2010 20:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 tNFn9VNKC-k6 for ; Tue, 23 Mar 2010 20:15:11 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 7A6523A68D8 for ; Tue, 23 Mar 2010 20:15:10 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2O3FTM3006154; Tue, 23 Mar 2010 20:15:29 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 899D6BB39B1; Tue, 23 Mar 2010 23:15:29 -0400 (EDT) To: Joe Touch , "tcpm@ietf.org" From: Mark Allman In-Reply-To: <20100323194311.B2D45BAFA6B@lawyers.icir.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma33745-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 23 Mar 2010 23:15:29 -0400 Sender: mallman@icir.org Message-Id: <20100324031529.899D6BB39B1@lawyers.icir.org> Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 03:15:12 -0000 ----------ma33745-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Folks- Joe and I had a conversation (or something like that) off-list about this draft. Yeah, it was just as stupid as you can imagine given the two principals. I don't think either of our on-list comments were quite as precise as perhaps they could have and I *think* we agree on something here. Joe will no doubt inform you of how wrong I still am. In any case ... This document really has two parts: (1) a mechanism that provides a random starting point for timestamps based on a hash of the 4-tuple and some secret sauce and (2) a mechanism for TIME-WAIT truncation based on observed timestamps on subsequent connections involving the same 4-tuple. However, these two items are really not related at all---other than that they both involve timestamps. It seems from our on- and off-list discussion that both of us find (2) useful. But, it doesn't depend on (1) at all. Further, I believe we both find (1) to be dubious (there seems to be not much security benefit and there are concerns about storage & computation (more Joe's than mine, but)). So, a compromise proposal could be to take (2) as a work item and jettison (1). I personally would support a (2)-not-(1) document more strongly than the current version. Or, at least perhaps we could see more motivation for (1) that would sway us to understanding the tangible benefit it offers. In all seriousness, I believe this note accurately represents the result of the discussion Joe and I had and both welcome his corrections and apologize if I have mis-represented anything. allman ----------ma33745-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkupg9EACgkQWyrrWs4yIs6uGQCfS3BXrsYPouU1jWufgHVSRlAS i2IAoJBpWqNVi+c8Ep8QkXbai6Vejxmb =bGel -----END PGP SIGNATURE----- ----------ma33745-1-- From fernando@gont.com.ar Tue Mar 23 21:11:10 2010 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 093E43A6C27 for ; Tue, 23 Mar 2010 21:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.165 X-Spam-Level: * X-Spam-Status: No, score=1.165 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 f1-XZxvg7wQ6 for ; Tue, 23 Mar 2010 21:11:09 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 244A93A6C24 for ; Tue, 23 Mar 2010 21:11:05 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A1E956B68A9; Wed, 24 Mar 2010 01:11:29 -0300 (ART) Received: from [192.168.1.102] (102-134-17-190.fibertel.com.ar [190.17.134.102]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2O4BLiv012994; Wed, 24 Mar 2010 01:11:22 -0300 Message-ID: <4BA990EC.7030501@gont.com.ar> Date: Wed, 24 Mar 2010 01:11:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20100324031529.899D6BB39B1@lawyers.icir.org> In-Reply-To: <20100324031529.899D6BB39B1@lawyers.icir.org> X-Enigmail-Version: 0.96.0 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]); Wed, 24 Mar 2010 01:11:29 -0300 (ART) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 04:11:11 -0000 Mark Allman wrote: > This document really has two parts: (1) a mechanism that provides a > random starting point for timestamps based on a hash of the 4-tuple and > some secret sauce and (2) a mechanism for TIME-WAIT truncation based on > observed timestamps on subsequent connections involving the same > 4-tuple. However, these two items are really not related at all---other > than that they both involve timestamps. The relationship is that (2) needs timestamps that are monotonically-increasing across connections. (1) provides a scheme that complies with such requirement and that also has the good property that it makes it hard for an off-path attacker to guess the timestamps in use by victim connections. > It seems from our on- and off-list discussion that both of us find (2) > useful. But, it doesn't depend on (1) at all. Further, I believe we > both find (1) to be dubious (there seems to be not much security benefit > and there are concerns about storage & computation (more Joe's than > mine, but)). 32 bits of additional state for each connection is such a big deal? > So, a compromise proposal could be to take (2) as a work item and > jettison (1). I personally would support a (2)-not-(1) document more > strongly than the current version. > > Or, at least perhaps we could see more motivation for (1) that would > sway us to understanding the tangible benefit it offers. Using unpredictable values is acting pro-actively. If we, say, propose to have a global counter for generating the timestamps, at some point we'll be re-hashing the same type of discussion we've had for "in window" attacks, but for TCP timestamps. Actually, at least part of this discussion has already taken place: there's a CERT advisory on predictable timestamps (I think I referenced it in the I-D), and some implementations have chosen to trivially randomize the timestamps (i.e., "just call "random()"), which does not allow (2) to work - most likely because they didn't want predictable timestamps, but didin't have any other option at hand. 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 gregory.ietf@gmail.com Wed Mar 24 01:12:22 2010 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 9B7BA3A68F6; Wed, 24 Mar 2010 01:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.075 X-Spam-Level: X-Spam-Status: No, score=-98.075 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, 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 qTkn65MvhfPN; Wed, 24 Mar 2010 01:12:20 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id EF13D3A6C71; Wed, 24 Mar 2010 01:12:13 -0700 (PDT) Received: by iwn35 with SMTP id 35so4608119iwn.31 for ; Wed, 24 Mar 2010 01:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0JOQBjRM6WMPD3rGvAdG9rpsbaE0017fHQq0eciWK68=; b=kL4AlW/xAlr3RQxFLBTZpqh/TCLu/pe5QYiD8y2kNtAm49LSF8/BW7PBeuzZRL6CUJ kyeSSZXl7WqvQ9ISHjiFxsLgJfCRuDp+bQHQ05bBQK/xxxNR01YAds55/riFC5TdGFet AJatpsJ8Uv49fbrxzOBzYBfekUcHQmzgUyF1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TilXYNmaIOuDnClFMygvbJ29+7wqUL+ZIYoFkgmvCjZHeHpXpi6XrNjLb/vYnCUU0U hAy5EeSNHq+vOMjoRfYSmNMl/X6sQNAbpmcfJweFg6ibuJxa2tQ7V75VtHz54xOKrG63 744eeZLp6Q0meR4DBxsJ6V0u+0yYgO8rr4PvA= MIME-Version: 1.0 Received: by 10.231.169.144 with SMTP id z16mr1520599iby.25.1269418351280; Wed, 24 Mar 2010 01:12:31 -0700 (PDT) In-Reply-To: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> Date: Wed, 24 Mar 2010 01:12:31 -0700 Message-ID: From: Gregory Lebovitz To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= Content-Type: multipart/alternative; boundary=0016e6d26c5ae642ba0482877d85 Cc: Eric Rescorla , tcpm@ietf.org, secdir@ietf.org, Tim Polk , Pasi Eronen , iesg@ietf.org Subject: Re: [tcpm] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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, 24 Mar 2010 08:12:22 -0000 --0016e6d26c5ae642ba0482877d85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable all the below changes indicated, plus the editorial suggestions indicated i= n Magnus' Mar 05 email, are included in -03, which I'll publish shortly. See comments inline... On Mon, Mar 8, 2010 at 11:35 PM, Magnus Nystr=F6m wrote= : > Thanks Gregory - a couple of comments below, inline. > > On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz > wrote: > > Hey Magnus, > > Thanks a lot for the review. Comments inline below... > > > > On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m > wrote: > >> > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments > >> > >> This document specifies requirements on cryptographic algorithms to be > >> used in the TCP Authentication Option (TCP APO). It also specifies > >> some mandatory algorithms. > >> > >> Comments: > >> > >> Abstract: > >> > >> - The abstract does not mention that the document also specifies > >> requirements on future algorithms. IMO, it should. > > > > Ok > done > > > >> > >> Section 1: > >> (- Last paragraph is what prompted my comment on the abstract.) > >> > >> Section 2.2: > >> > >> - Suggest moving the note explaining the need to mandate two MAC > >> algorithms to the Security Considerations section as it does not > >> contain normative text but does contain security considerations. > > > > Good point. When I originally wrote this text it did contain normative > text. > > Then I got some feedback that maybe we should down-grade the text to be > > non-normative, but still clear guidance. If you think it makes a big > > difference, I can move it. Otherwise, I'd like to keep it with the text > > describing the "template" for how all TCP-AO algos are used, so that > people > > who are looking for the template will see the text right there, whereas > they > > might miss it if they are skimming and don't make it all the way to the > SC > > section. Let me know what you think. > > You could also place the note in the Security Considerations section > and then just reference it in 2.2, like "For an explanation of the > need for two MAC algorithms, see the Security Considerations section." > I think that would be better, keeping all security considerations in > one place. > done > > >> - Section 3.1.1.3: > >> > >> - It is a little surprising to see that the SHA-1-based MAC algorithm > >> is selected as the default one, given that this is a new specification > >> and the industry is moving away from SHA-1. C.f. the work on XML > >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends > >> against use of SHA-1 in new applications. > > > > In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not > have > > the same properties in this context, and has shown no weaknesses, afaik= . > As > > you can imagine we had a very long debate around which algo to make > > mandatory. In the end (as the text was supposed to explain), Pasi and T= im > > chose SHA-1 for both its strength and its wide availability in the targ= et > > devices (routers -- this is first and foremost being done for BGP > > protection). But, since it's been around a while, and we always want to > have > > 2 good algos in place, one the older more available, and a newer > > up-and-comer, the AES was also specified. Unless Pasi and Tim want to > change > > their recommendations to the TCPM WG, we'll probably sit tight with thi= s > the > > way it reads currently. > > Yes, I can (and did...) imagine you had lengthy discussions around > this... OK, since Pasi and Tim chose it I will rest my case... > > Best, > -- Magnus > > >> - Section 6 (Security Considerations): > >> > >> In the fourth paragraph, there is a discussion around the fact that > >> the document does not force use of a 16 octet key. I think it would be > >> useful to at least clearly state a recommended minimum key size. > > > > Interesting point. We had this debate in WG too. > > My .02: this is a security vs convenience thing. We give the deployer > > plenty enough guidance and pointers to other RFC's and NIST docs to all= ow > > them to do their homework to decide what length key they want, stopping > just > > short of telling them a recommended min key size. The deployers here ar= e > > router operators, for the most part. The ones that have a clue are > already > > using 128bit keys, generated randomly. The ones that aren't probably > aren't > > going to read this document anyway. > > Any thoughts from Tim or EKR? > No change made. Gregory. --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0016e6d26c5ae642ba0482877d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable all the below changes indicated, plus the editorial suggestions indicated i= n Magnus' Mar 05 email, are included in -03, which I'll publish sho= rtly. See comments inline...

On Mon, Mar = 8, 2010 at 11:35 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
Thanks Gregory - a couple of comments below= , inline.

On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <gregory.ietf@gmail.com> wrote:
> Hey Magnus,
> Thanks a lot for the review. Comments inline below...
>
> On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
>>
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG. =A0These comments were written primarily for the benefit of = the
>> security area directors. =A0Document editors and WG chairs should = treat
>> these comments just like any other last call comments
>>
>> This document specifies requirements on cryptographic algorithms t= o be
>> used in the TCP Authentication Option (TCP APO). It also specifies=
>> some mandatory algorithms.
>>
>> Comments:
>>
>> Abstract:
>>
>> - The abstract does not mention that the document also specifies >> requirements on future algorithms. IMO, it should.
>
> Ok

done
=A0<= /div>
>
>>
>> Section 1:
>> (- Last paragraph is what prompted my comment on the abstract.) >>
>> Section 2.2:
>>
>> - Suggest moving the note explaining the need to mandate two MAC >> algorithms to the Security Considerations section as it does not >> contain normative text but does contain security considerations. >
> Good point. When I originally wrote this text it did contain normative= text.
> Then I got some feedback that maybe we should down-grade the text to b= e
> non-normative, but still clear guidance. If you think it makes a big > difference, I can move it. Otherwise, I'd like to keep it with the= text
> describing the "template" for how all TCP-AO algos are used,= so that people
> who are looking for the template will see the text right there, wherea= s they
> might miss it if they are skimming and don't make it all the way t= o the SC
> section. Let me know what you think.

You could also place the note in the Security Considerations se= ction
and then just reference it in 2.2, like "For an explanation of the
need for two MAC algorithms, see the Security Considerations section."=
I think that would be better, keeping all security considerations in
one place.

done
=A0

>> - Section 3.1.1.3= :
>>
>> - It is a little surprising to see that the SHA-1-based MAC algori= thm
>> is selected as the default one, given that this is a new specifica= tion
>> and the industry is moving away from SHA-1. C.f. the work on XML >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends=
>> against use of SHA-1 in new applications.
>
> In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not= have
> the same properties in this context, and has shown no weaknesses, afai= k. As
> you can imagine we had a very long debate around which algo to make > mandatory. In the end (as the text was supposed to explain), Pasi and = Tim
> chose SHA-1 for both its strength and its wide availability in the tar= get
> devices (routers -- this is first and foremost being done for BGP
> protection). But, since it's been around a while, and we always wa= nt to have
> 2 good algos in place, one the older more available, and a newer
> up-and-comer, the AES was also specified. Unless Pasi and Tim want to = change
> their recommendations to the TCPM WG, we'll probably sit tight wit= h this the
> way it reads currently.

Yes, I can (and did...) imagine you had lengthy discussions around this... OK, since Pasi and Tim chose it I will rest my case...

Best,
-- Magnus

>> - Section 6 (Security Considerations):
>>
>> In the fourth paragraph, there is a discussion around the fact tha= t
>> the document does not force use of a 16 octet key. I think it woul= d be
>> useful to at least clearly state a recommended minimum key size. >
> Interesting point. We had this debate in WG too.
> My .02: =A0this is a security vs convenience thing. We give the deploy= er
> plenty enough guidance and pointers to other RFC's and NIST docs t= o allow
> them to do their homework to decide what length key they want, stoppin= g just
> short of telling them a recommended min key size. The deployers here a= re
> router operators, for the most part. The ones that have a clue are alr= eady
> using 128bit keys, generated randomly. The ones that aren't probab= ly aren't
> going to read this document anyway.
> Any thoughts from Tim or EKR?

No change made.

Gregory.=A0


--
----
IETF related email from
Gregory M.= Lebovitz
Juniper Networks
--0016e6d26c5ae642ba0482877d85-- From gregory.ietf@gmail.com Wed Mar 24 01:40:26 2010 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 336B03A6810; Wed, 24 Mar 2010 01:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.174 X-Spam-Level: X-Spam-Status: No, score=-98.174 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 GohoG7QLINLA; Wed, 24 Mar 2010 01:40:25 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id BC5453A67DA; Wed, 24 Mar 2010 01:40:24 -0700 (PDT) Received: by iwn35 with SMTP id 35so4627029iwn.31 for ; Wed, 24 Mar 2010 01:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=rwphckyrjAvfeUQImRI4Vy36OInNVtA9EdsoA48Yv9k=; b=KlEGdSwiXsuN/JJkym4eu2M8JGfWrgQKqDrZ3JtJOw2C9QQxbvZUMfoiiKGFm9hGbs tejW67TW4QN4HXNWr4CIDlcIpEVgFjjMqrqHHY7GNEhsSOBbUrEyAp1YpAX4Mv+L15Cb P2XyMuJ4aOl8+4qFLNBC521YdsP/Zcy0aYAJQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hwyJbi1MCFrC6pOioCThkGw4XVSlkmaT75Jh8CLiDrok8bHpShQzN8FxFwHPhtxGnT G6yg7VUE1tplWTMet1rTlIwIKlXwwlWJshyuyZvtvT+O7xM3/pcS/fDeFe2CJeLGLC7a tGuSFEkCTolnggMHpwIKBiMNF9t3l0NN9QNZs= MIME-Version: 1.0 Received: by 10.231.174.140 with SMTP id t12mr2317641ibz.89.1269420043849; Wed, 24 Mar 2010 01:40:43 -0700 (PDT) In-Reply-To: <201002242215.XAA04613@TR-Sys.de> References: <201002242215.XAA04613@TR-Sys.de> Date: Wed, 24 Mar 2010 01:40:43 -0700 Message-ID: From: Gregory Lebovitz To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: multipart/alternative; boundary=0016362852fec8d032048287e205 Cc: tcpm@ietf.org, ietf@ietf.org, draft-ietf-tcpm-tcp-ao-crypto@tools.ietf.org Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-ao-crypto ... -- editorials 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, 24 Mar 2010 08:40:26 -0000 --0016362852fec8d032048287e205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alfred, Thx for your review. The changes indicated inline below are being made in -03, which will be published shortly. On Wed, Feb 24, 2010 at 3:15 PM, Alfred H=CEnes wrote: > It looks like draft-ietf-tcpm-tcp-ao-crypto-02 is not yet ready for > publication. > > > Here is a collection of some editorials (found on a quick pass > over the draft) that should be fixed: > > (1) Section 1, last para > > The text there does not reflect the order of presentation in the > remainder of the document. In particular, "It then specifies ..." > is confusing. Please consider rearranging that text to reflect > the document content and not confuse the reader. > s/It then specifies/It specifies/ > > OTOH, it might make sense to indeed first present the general > requirements and then the specific requirements (i.e. swap > Sections 2.2 and 2.3 and leave that paragraph unchaged). > > (2) Section 3.1.1 ff. (recurring) > > The input representation repeatedly uses unbalanced spacing: > > ( i || Label || Context || Output_Length) > ^^ ^ > > Please use a balanced form, either > > ( i || Label || Context || Output_Length ) > this one was used > or > (i || Label || Context || Output_Length) > > Also, "Context :" recurs in the draft, while other items are written > with no white space before the colon. > removed the spaces > > (3) Sections 3.1.1.3 (see below, as well!) and 7: > > I seriously doubt that the very short names given to IANA and > as a SHOULD for UIs are useful. > > In particular not using "HMAC", only the shorthand "SHA1", will > likely raise again these concerns against SHA-1 that do not > properly distinguish between the cyptographical strenght/weekness > of plain SHA-1 and the HMAC construct employing SHA-1. > > The name "AES128" also seems to be confusing; future algorithms > for TCP-AO might also be based on AES-128 -- e.g. AES in GMAC mode. > Thus, a bit more precision would certainly help to avoid confusion. > Understood. There were fairly long debates about this in the WG, and the current formulation reflects WG's conclusion. You may well be right about future collisions, which we can address by making the future label more precise, e.g. "AES128-GMAC" in your example. > > (4) Sections 4 and 5 > > Usually, such sections are supplied as appendices, so that > the numbered sections do no need renumbering upon cleanup. > > OTOH, it's not clear why Section 5 (and the final editorial remark > in section 2.3) are still present at all in a document forwarded > to the IESG and subject to IETF LC. > deleting them both in -03. > > (5) idnits results > > I once assumed that documents forwarded to the IESG had to pass the > idnits checks beforehand -- besides actual "false alarms". > Please clean up the references and address all the other general > items and details that idnits reports (too much to reproduce here). > > (6) Further nits: > > * clean up non-paired spurious square brackets > found 2 instances, and deleted. > > * in 3.1.1: s/mutiple/multiple/ > done > > * please fix hyphenation (if used as an attribute, e.g. > "128-bit key", 16-byte jey" etc.) > Did not find anything matching what I thought you meant. No change. > > * Section 3.1.1.3 should betted be numbered 3.1.2; > it does not introduce a 3rd "Concrete KDF". > Subjective. 3.1.1 is about KDFs, and 3.1.1.3 is about the UI for these KDFs= . No change. > > * Section 3.2, last line: there's no "TCP-AO header"; > please use "TCP header" (or maybe "TCP-AO option"). > s/TCP-AO header/TCP-AO option field/ > > * Section 3.2.1: s/that has function/that hash function/ . > done > ^ ^^ > > * Section 6, 2nd para: > "cryptographic-based systems" ?? -- I suggest to use > "cryptography-based systems" or better > done > "systems based on cryptography". > > * Section 6, last para: > There are no algorithms with a requirement level of > or "SHOULD implement" > These three words should be deleted. > done Thanks a ton for the thorough reading and suggestions, Alfred. Gregory > > > Kind regards, > Alfred H=CEnes. > > -- > > +------------------------+--------------------------------------------+ > | 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 | > +------------------------+--------------------------------------------+ > > --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0016362852fec8d032048287e205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alfred,
Thx for your review. The changes indicated inline below are bei= ng made in -03, which will be published shortly.

On Wed, Feb 24, 2010 at 3:15 PM, Alfred H=CEnes &= lt;ah@tr-sys.de> wrote:
It looks like draft-ietf-tcpm-tcp-ao-crypto= -02 is not yet ready for
publication.


Here is a collection of some editorials (found on a quick pass
over the draft) that should be fixed:

(1) =A0Section 1, last para

The text there does not reflect the order of presentation in the
remainder of the document. =A0In particular, "It then specifies ...&qu= ot;
is confusing. =A0Please consider rearranging that text to reflect
the document content and not confuse the reader.

<= /div>
s/It then specifies/It specifies/
=A0

OTOH, it might make sense to indeed first present the general
requirements and then the specific requirements (i.e. swap
Sections 2.2 and 2.3 and leave that paragraph unchaged).

(2) Section 3.1.1 ff. (recurring)

The input representation repeatedly uses unbalanced spacing:

=A0 =A0 =A0 =A0 =A0 ( i || Label || Context || Output_Length)
=A0 =A0 =A0 =A0 =A0 ^^ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0^

Please use a balanced form, either

=A0 =A0 =A0 =A0 =A0 ( i || Label || Context || Output_Length )

this one was used
=A0
or
=A0 =A0 =A0 =A0 =A0 =A0(i || Label || Context || Output_Length)

Also, "Context :" recurs in the draft, while other items are writ= ten
with no white space before the colon.

r= emoved the spaces
=A0

(3) Sections 3.1.1.3 (see below, as well!) and 7:

I seriously doubt that the very short names given to IANA and
as a SHOULD for UIs are useful.

In particular not using "HMAC", only the shorthand "SHA1&quo= t;, will
likely raise again these concerns against SHA-1 that do not
properly distinguish between the cyptographical strenght/weekness
of plain SHA-1 and the HMAC construct employing SHA-1.

The name "AES128" also seems to be confusing; future algorithms for TCP-AO might also be based on AES-128 -- e.g. AES in GMAC mode.
Thus, a bit more precision would certainly help to avoid confusion.

Understood. There were fairly long debates abo= ut this in the WG, and the current formulation reflects WG's conclusion= . You may well be right about future collisions, which we can address by ma= king the future label more precise, e.g. "AES128-GMAC" in your ex= ample.
=A0

(4) Sections 4 and 5

Usually, such sections are supplied as appendices, so that
the numbered sections do no need renumbering upon cleanup.

OTOH, it's not clear why Section 5 (and the final editorial remark
in section 2.3) are still present at all in a document forwarded
to the IESG and subject to IETF LC.

del= eting them both in -03.=A0
=A0

(5) =A0idnits results

I once assumed that documents forwarded to the IESG had to pass the
idnits checks beforehand -- besides actual "false alarms".
Please clean up the references and address all the other general
items and details that idnits reports (too much to reproduce here).

(6) Further nits:

* =A0 clean up non-paired spurious square brackets
found 2 instances, and deleted.
=A0

* =A0 in 3.1.1: =A0s/mutiple/multiple/

= done
=A0

* =A0 please fix hyphenation (if used as an attribute, e.g.
=A0 =A0"128-bit key", 16-byte jey" etc.)

Did not find anything matching what I thought you meant. = No change.
=A0

* =A0Section 3.1.1.3 should betted be numbered 3.1.2;
=A0 it does not introduce a 3rd "Concrete KDF".
=

Subjective. 3.1.1 is about KDFs, and 3.1.1.3 is about t= he UI for these KDFs. No change.
=A0

* =A0Section 3.2, last line: =A0there's no "TCP-AO header"; =A0 please use "TCP header" (or maybe "TCP-AO option")= .

s/TCP-AO header/TCP-AO option field/= =A0
=A0

* =A0Section 3.2.1: =A0s/that has function/that hash function/ .

done
=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^ =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 ^^

* =A0Section 6, 2nd para:
=A0 "cryptographic-based systems" ?? -- I suggest to use
=A0 "cryptography-based systems" or better
=
done
=A0
=A0 "systems based on cryptography".

* =A0Section 6, last para:
=A0 There are no algorithms with a requirement level of
=A0 =A0 =A0 =A0 or "SHOULD implement"
=A0 These three words should be deleted.

done

Thanks a ton for the thorough reading and = suggestions, Alfred.=A0

Gregory
=A0


Kind regards,
=A0Alfred H=CEnes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes =A0 | =A0Alfred Hoenes =A0 Dipl.-Math., Dipl.-Phys. = =A0|
| Gerlinger Strasse 12 =A0 | =A0Phone: (+49)7156/9635-0, Fax: -18 =A0 =A0 = =A0 =A0 |
| D-71254 =A0Ditzingen =A0 =A0 | =A0E-Mail: =A0ah@TR-Sys.de =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
+------------------------+--------------------------------------------+




--
----
IETF rel= ated email from
Gregory M. Lebovitz
Juniper Networks
--0016362852fec8d032048287e205-- From gregory.ietf@gmail.com Wed Mar 24 01:48:54 2010 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 6C48A3A676A; Wed, 24 Mar 2010 01:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.39 X-Spam-Level: X-Spam-Status: No, score=-98.39 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 wOxsB6jh-Mti; Wed, 24 Mar 2010 01:48:53 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id E84BE3A69CB; Wed, 24 Mar 2010 01:48:50 -0700 (PDT) Received: by iwn35 with SMTP id 35so4632445iwn.31 for ; Wed, 24 Mar 2010 01:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3Ff6zPH6CIcQeLmfkfr0BrnvCkBEHByRyS198jhiGJw=; b=XxcqQKnvoDPgPl8cdC/4ROdd3ZhxgDFXQkJKeMset+cksvXq3JkY/6xOtNUXHZNu5X Cd9XOeB4HxE4D5JNlKPFDgukhe0IAxJfLI0yLN7IfdLzwHgvVPSyefdEDLIhJDt+0vvB 3+G1I/JyDIRSzFR7583zb/q9ti8Ts5fRfRbTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e0J5zatrRRiWSyXlVxP6grnOUyVXHeCOXGNJHEeCav7JiuptXT8BKnINmTKr+yoeUB lxiBQ92mLlzPe8O4SfWLgy67fZt9gcbkUlQ+VKGqQg79gvvNYbGwOS4u0O/pzU4nJfFY h8ldZH5DlIUozBsn0y+bxmmkVHhUn37BR01ko= MIME-Version: 1.0 Received: by 10.231.150.195 with SMTP id z3mr2925422ibv.3.1269420547515; Wed, 24 Mar 2010 01:49:07 -0700 (PDT) In-Reply-To: <20100310204920.EC2B03A6996@core3.amsl.com> References: <20100310204920.EC2B03A6996@core3.amsl.com> Date: Wed, 24 Mar 2010 01:49:07 -0700 Message-ID: From: Gregory Lebovitz To: Pasi Eronen Content-Type: multipart/alternative; boundary=005045013ba5ce270904828800ab Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, iesg@ietf.org, draft-ietf-tcpm-tcp-ao-crypto@tools.ietf.org Subject: Re: [tcpm] DISCUSS and COMMENT: draft-ietf-tcpm-tcp-ao-crypto 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, 24 Mar 2010 08:48:54 -0000 --005045013ba5ce270904828800ab Content-Type: text/plain; charset=ISO-8859-1 Thanks for the review, Pasi. The changes indicated below will be issued shortly in a -03 (along with Magnus SecDir review, Avshalom Houri's GenArt review, and Alfred H's reviews. See inline... On Wed, Mar 10, 2010 at 1:49 PM, Pasi Eronen wrote: > Discuss: > > I have reviewed draft-ietf-tcpm-tcp-ao-crypto-02, and have couple of > small concerns that I'd like to discuss before recommending approval > of the document: > > - In other contexts where manually configured pre-shared keys are > used, it has been found useful to specify some minimum requirements > for management interfaces -- i.e. how the human-readable/entered input > is converted to the octet string. For example, here's what > draft-ietf-bfd-base said about this: > > For interoperability, the management interface by which the > password is configured MUST accept ASCII strings, and SHOULD also > allow for the configuration of any arbitrary binary string in > hexadecimal form. Other configuration methods MAY be supported. > Good catch. Your suggested text was added into: the definition of "Master_Key" in s3.1 "Key Derivation Functions", and I changed "password" to "PSK", to fit the context. > > Something similar would be needed here, IMHO (and BTW, I don't think > mandating support for UTF-8 or SASLprep is needed in this context). > > - It looks like many of the informative references need to be normative. > At the very least, RFC 4493 (or NIST-SP800-38B, depending on which you > prefer) have replaced all instances of 4493 with NIST-SP800-38B > and RFC 2104; 2104 moved to Normative > and normative references to AES (FIPS 197) added to Normative > and > SHA-1 (FIPS 180-3) are needed, too. > added to Normative > > - Section 3.1.1, "based on PRF-HMAC-SHA1 [RFC2404]": the pointer to > RFC2404 here doesn't sound quite right (2404 doesn't define any PRFs; > it's just one protocol that happens to use HMAC-SHA1). Perhaps just > "based on HMAC-SHA1 [RFC2104][180-3]" would be sufficient? (also > applies to pointers in 2.2, 3.1.1.1, and 3.2) > done, in all mentioned sections. removed 2404 from document. > > - Section 3.1.1, "based on AES-CMAC-PRF-128 [RFC4615]": This is also > confusing, since the PRF in RFC 4615 uses a very different > construction. Perhaps just "based on AES-CMAC [800-38B][FIPS197]"? > (also applies to pointer in 3.1.1.2 ) > done. > > - Section 3.1.1: "not an even multiple of the output size" initially > confused me (why an odd multiple is not allowed?). "exact multiple", > perhaps? > changed > > Comment: > > Idnits finds some missing/erronous references remove the unused references > (which really ought to > have been fixed before sending this to IETF last call...) > agreed. Sorry about that. Gregory -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --005045013ba5ce270904828800ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the review, Pasi. The changes indicated below will be issued sho= rtly in a -03 (along with Magnus SecDir review, Avshalom Houri's GenArt= review, and Alfred H's reviews. See inline...

On Wed, Mar 10, 2010 at 1:49 PM, Pasi Eronen <pasi.eronen@nokia.com> wrot= e:
Discuss:

I have reviewed draft-ietf-tcpm-tcp-ao-crypto-02, and have couple of
small concerns that I'd like to discuss before recommending approval of the document:

- In other contexts where manually configured pre-shared keys are
used, it has been found useful to specify some minimum requirements
for management interfaces -- i.e. how the human-readable/entered input
is converted to the octet string. For example, here's what
draft-ietf-bfd-base said about this:

=A0 For interoperability, the management interface by which the
=A0 password is configured MUST accept ASCII strings, and SHOULD also
=A0 allow for the configuration of any arbitrary binary string in
=A0 hexadecimal form. =A0Other configuration methods MAY be supported.
=

Good catch. Your suggested=A0text was adde= d into: =A0the definition of "Master_Key" in s3.1 "Key Deriv= ation Functions", and I changed "password" to "PSK"= ;, to fit the context.
=A0

Something similar would be needed here, IMHO (and BTW, I don't think mandating support for UTF-8 or SASLprep is needed in this context).

- It looks like many of the informative references need to be normative. At the very least, RFC 4493 (or NIST-SP800-38B, depending on which you
prefer)

have replaced all instances of 449= 3 with NIST-SP800-38B
=A0
an= d RFC 2104;

2104 moved to Normative
=A0
and normative references to AES (FIPS 197)
=

added to Normative
=A0
and
SHA-1 (FIPS 180-3) are needed, too.

add= ed to Normative
=A0

- Section 3.1.1, "based on PRF-HMAC-SHA1 [RFC2404]": the pointer = to
RFC2404 here doesn't sound quite right (2404 doesn't define any PRF= s;
it's just one protocol that happens to use HMAC-SHA1). Perhaps just
"based on HMAC-SHA1 [RFC2104][180-3]" would be sufficient? (also<= br> applies to pointers in 2.2, 3.1.1.1, and 3.2)

done, in all mentioned sections. removed 2404 from document.
=A0

- Section 3.1.1, "based on AES-CMAC-PRF-128 [RFC4615]": This is a= lso
confusing, since the PRF in RFC 4615 uses a very different
construction. Perhaps just "based on AES-CMAC [800-38B][FIPS197]"= ?
(also applies to pointer in 3.1.1.2 )

d= one.
=A0

- Section 3.1.1: "not an even multiple of the output size" initia= lly
confused me (why an odd multiple is not allowed?). "exact multiple&quo= t;,
perhaps?

changed
=A0

Comment:

Idnits finds some missing/erronous references

remove the unused references
=A0
(which really ought to
have been fixed before sending this to IETF last call...)
<= div>
agreed. Sorry about that.

Grego= ry=A0

=A0

=A0
=


--
----
IETF related email from
Gregory M. = Lebovitz
Juniper Networks
--005045013ba5ce270904828800ab-- From gregory.ietf@gmail.com Wed Mar 24 02:02:44 2010 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 508BE3A6B0F; Wed, 24 Mar 2010 02:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.158 X-Spam-Level: X-Spam-Status: No, score=-98.158 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_22=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 VZgPxPXqsqhd; Wed, 24 Mar 2010 02:02:43 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 408593A6AF9; Wed, 24 Mar 2010 02:02:42 -0700 (PDT) Received: by iwn35 with SMTP id 35so4642071iwn.31 for ; Wed, 24 Mar 2010 02:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=eqomJo7awh37AOY9A6xCvnuY7JXsqgpPtbrpfm5B/Bs=; b=iZwu060UEGS3zitN67vEmVczHQzH4KpaTHPJKuGy2KLrTJJLxGmUXgzFyzKE7YcZV1 FRywxfMideXdAddTLB13LjhWQ5e2oudJHC4yWDVbyWRI6tD+gQfIJ5x/OA1nldRWYCTS nIDqDtJlU427MO7tSAIEp1/7LRRvvnCv5vxOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XsucsDllG+Ba1ccWkb6D7sUq1HiUHrUcyAb6RugiBGDUW11J3gKVsTDG7EbihkAwId lEdl5rkUl0bNfxE9a0CNDCCzuivnBX8Vq9/kb4J9JNKSdrsuKAUAhVEMZhQzESJpaSUt j4shdqbhwG1zAjIYpYI+NrWavi1XgRjIwuVFc= MIME-Version: 1.0 Received: by 10.231.182.211 with SMTP id cd19mr81051ibb.55.1269421377536; Wed, 24 Mar 2010 02:02:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Mar 2010 02:02:57 -0700 Message-ID: From: Gregory Lebovitz To: Avshalom Houri Content-Type: multipart/alternative; boundary=0016364ee3b64744590482883265 Cc: General Area Review Team , tcpm@ietf.org, Russ Housley , ekr@rtfm.com Subject: Re: [tcpm] Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-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, 24 Mar 2010 09:02:44 -0000 --0016364ee3b64744590482883265 Content-Type: text/plain; charset=ISO-8859-1 Avshalom, Thanks for your review. The indicated changes inline below have been made in -03, which will be issued shortly. See inline... On Tue, Mar 9, 2010 at 3:20 PM, Avshalom Houri wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-tcpm-tcp-ao-crypto-02 > Reviewer: Avshalom Houri > Review Date: 2010-03-09 > IETF LC date: 2010-03-10 > IESG Telechat date: 2010-03-11 > > Summary: The draft is ready for a standard track RFC (see minor issues and > nits). > The document is a reasonable basis on which to build the salient part of > the > Internet infrastructure. > > Major issues: None > > Minor issues: > > Line 211 > This is the initial specification of required cryptography for > > Why it is initial? Initial RFC? > TCP-AO is brand new, and this is the first ever specification of required cryptography for -AO. We assume, as time goes on, that others could follow. No change to text. > > Lines 232-238 > I do not see the requirements only MUSTs. > Not sure what you mean here. The "Requirement" is "MUST" as opposed to SHOULD or MAY. No change. > > Line 260 > "MUST" to implement, in order to drive vendors toward its use, and to > > Should the IETF include something as a must in order to drive its > implementation? This decision/text was re-worked several times and reflects WG consensus. No change. > > > Line 862: > above. We simply attempted to "put a fence around stupidity", in as > > Maybe change the language for the RFC? > makes sense. s/stupidity/foolishness/ > > > Nits/editorial comments: > > Line 182 > verification between to end-points. In order to accomplish this > -> verification between two end-points. In order to accomplish this > done > > > Line 384 > starts = 1. > > -> starts at 1. > because "i" is a counter, I think being precise with the "=" is appropriate. No change. Thanks again for the review, Gregory. > > --Avshalom > > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0016364ee3b64744590482883265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avshalom,
Thanks for your review. The indicated changes inline below ha= ve been made in -03, which will be issued shortly. See inline...

On Tue, Mar 9, 2010 at 3:20 PM, Avshalom Houri <AVSHALOM@il.ibm.co= m> wrote:
I hav= e been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for back= ground on Gen-ART, please see
http://www.alvestrand.n= o/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from yo= ur document shepherd
or AD before posting a new versio= n of the draft.

Document: draft-ietf-tcpm-tcp-ao-= crypto-02
Reviewer: Avshalom Houri
Review Date: 2010-03-09
IETF LC date: 2010-03-10
IESG Telechat date: 2010-03-11

Summary: The draft is ready for a= standard track RFC (see minor issues and nits).
The document is a reasonable basi= s on which to build the salient part of the
Internet infrastructure.

Major issues: None

Minor issues:

Line 211
=A0 =A0This is the initial specif= ication of required cryptography for

Why it is initial? Initial RFC?

TCP-AO is brand new, and this is the f= irst ever specification of required cryptography for -AO. We assume, as tim= e goes on, that others could follow. No change to text.
=A0

Lines 232-238
I do not see the requirements onl= y MUSTs.

Not sure what you mean here. The "= ;Requirement" is "MUST" as opposed to SHOULD or MAY. No chan= ge.
=A0

Line 260
=A0 =A0"MUST" to implem= ent, in order to drive vendors toward its use, and to

Should the IETF include something= as a must in order to drive its implementation?

This decision/text was re-worked several times and reflects WG con= sensus. No change.
=A0


Line 862:
=A0 =A0above. =A0We simply attempted to "put a fence around stupidity", in as

Maybe change the language for the= RFC?

makes sense. =A0s/stupidity/foolishnes= s/
=A0


Nits/editorial comments:

Line 182
=A0 =A0verification between to end-points. =A0In order to accomplish this
-> =A0 =A0verification between two end-points. =A0In order to accomplish this

done

=A0


Line 384
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0starts =3D 1.

-> starts at 1.

because "i" is a counter, I = think being precise with the "=3D" is appropriate. No change.

Thanks again for the review,
Gregory.=A0
=A0

--Avshalom





--
----
I= ETF related email from
Gregory M. Lebovitz
Juniper Networks
--0016364ee3b64744590482883265-- From mallman@icir.org Wed Mar 24 06:09:19 2010 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 F0C0F3A6818 for ; Wed, 24 Mar 2010 06:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 vlHbvjNjf34U for ; Wed, 24 Mar 2010 06:09:18 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 6697D3A69F6 for ; Wed, 24 Mar 2010 06:08:53 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2OD96sM000308; Wed, 24 Mar 2010 06:09:07 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9A725BB65C7; Wed, 24 Mar 2010 09:09:06 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4BA990EC.7030501@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma3823-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Mar 2010 09:09:06 -0400 Sender: mallman@icir.org Message-Id: <20100324130906.9A725BB65C7@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 13:09:19 -0000 ----------ma3823-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Fernando! > > This document really has two parts: (1) a mechanism that provides a > > random starting point for timestamps based on a hash of the 4-tuple and > > some secret sauce and (2) a mechanism for TIME-WAIT truncation based on > > observed timestamps on subsequent connections involving the same > > 4-tuple. However, these two items are really not related at all---other > > than that they both involve timestamps. > > The relationship is that (2) needs timestamps that are > monotonically-increasing across connections. Yep- we agree on that requirement. > (1) provides a scheme that > complies with such requirement Yep, it does. But, (1) does not somehow uniquely address that requirement. > and that also has the good property that it makes it hard for an > off-path attacker to guess the timestamps in use by victim > connections. The question is whether this is really important or not. > > So, a compromise proposal could be to take (2) as a work item and > > jettison (1). I personally would support a (2)-not-(1) document more > > strongly than the current version. > > > > Or, at least perhaps we could see more motivation for (1) that would > > sway us to understanding the tangible benefit it offers. > > Using unpredictable values is acting pro-actively. If we, say, propose > to have a global counter for generating the timestamps, at some point > we'll be re-hashing the same type of discussion we've had for "in > window" attacks, but for TCP timestamps. Well, we can encase a whole lot of stuff in "be pro-active". I don't think thats the right touchstone at all. E.g., wouldn't it be pro-active to encode the user's favorite color (in RGB, say) in a TCP option to make it even harder to mess with the connection? If you want to be so pro-active why are we not just saying every TCP connection should use the auth option? Or, IPsec? I find the "be pro-active" framing to be essentially a non-argument. If the "problem" can't be motivated with anything beyond "be pro-active" then it isn't much of a problem it seems to me. I seriously doubt we ever will do the re-hashing you're talking about: (1) An off path attacker already has to throw a bunch of packets at some connection if it knows the 4-tuple---a big if. E.g., about 42K packets if you assume a 100KB window. (2) Assuming we both (i) use the entire ephemeral port range and (ii) make the choice of ephemerals unpredictable (per recommendation coming from TSVWG) an attacker now has to throw an enormous amount of packets at some connection. E.g., assuming a 100KB window (which is bigger than we generally see) it would take 2.7 billion packets to exhaustively search the space---or, a mere 1.35 billion on average to muck with things. (3) Using back-of-the-envelope math, sourcing SYNs at 1Gbps means it would take more than 500 seconds on average (i.e., to send the 1.35 billion SYNs noted above) to find a connection assuming you knew one was going on and you knew three of the four elements of the 4-tuple. But, such long-lived connections are the very small exception, not the rule. So, you're not even aiming for a stable target on the timescales on which you can reliably bring down a connection. Even if you could gather 100x that capacity and reduce the time to 5 seconds that is still longer than nearly all the connections. (And, thats a bunch of resources to expend on the "benefit" of hosing up one TCP connection.) (4) And, yes, you could get lucky, but the odds are pretty long given a space of 2.7 billion. So, to be clear, thats (1) knowing a 3-tuple, (2) using 1Gbps of sending capacity, (3) assuming a generally large TCP window and (4) needing a connection to last over 500 seconds before we can reliably cause problems **for one TCP connection**. So then, yeah, with timestamps you also have to pass the PAWS check on top of all that and so its even harder. And, if you can somehow find an endhost's global clock then this reduces to the non-timestamp case. But, if you can't then you have some additional shot in the dark. But, even without adding this additional variable I hope you can see my skepticism and thinking that this adds basically nothing tangible to the situation because the bar is already So Damn High. Further, at some point you have to just decide that if you are going to count on a particular connection then you need to quit playing cat & mouse and actually secure the connection. I.e., really be pro-active. > Actually, at least part of this discussion has already taken place: > there's a CERT advisory on predictable timestamps (I think I referenced > it in the I-D), I can't find the reference in the I-D. Can you provide it? Perhaps they have more substantive motivation that you are providing. allman ----------ma3823-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuqDvIACgkQWyrrWs4yIs7cZgCfeohsi3mluXtcY5FswiVENBYD Fc0An0OOcLJH/LYZ3wXXFx0XcQ+lM3m3 =JmrZ -----END PGP SIGNATURE----- ----------ma3823-1-- From mallman@icir.org Wed Mar 24 06:33:05 2010 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 68ABC3A6B9B for ; Wed, 24 Mar 2010 06:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 CftHyqPK3pul for ; Wed, 24 Mar 2010 06:33:04 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 58C003A69E3 for ; Wed, 24 Mar 2010 06:31:49 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2ODW5Xh002847; Wed, 24 Mar 2010 06:32:06 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 95CFDBB8831; Wed, 24 Mar 2010 09:32:05 -0400 (EDT) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <4BA93D8A.8080508@erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma5205-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Mar 2010 09:32:05 -0400 Sender: mallman@icir.org Message-Id: <20100324133205.95CFDBB8831@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 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, 24 Mar 2010 13:33:05 -0000 ----------ma5205-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > My rationale is that there are transport methods that use > retransmission of a SYN as the indication that there may be something > problematic with the path, and then modify their behaviour. I wasn't in the meeting so perhaps I don't have the right context here. But, I guess I don't quite see the concern. Presumably these methods actually help the cause---not hurt it. I.e., if I send a SYN-with-ECN and then spuriously RTO because I am traversing a long path I will send a SYN-w/o-ECN. When I see a SYN-ACK I'll be able to tell which SYN triggered it and therefore do the right thing (i.e., get an RTT sample, tell if the retransmit was likely spurious or not, etc.). Am I missing something here? allman ----------ma5205-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuqFFUACgkQWyrrWs4yIs6zEwCfQjcVNtGhC0cVzZI0quWLMyk9 QMIAnA5YSRYo6TbVcRZW2UH0KpgdGs7H =75H2 -----END PGP SIGNATURE----- ----------ma5205-1-- From gorry@erg.abdn.ac.uk Wed Mar 24 07:52:59 2010 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 2EA373A684B for ; Wed, 24 Mar 2010 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_33=0.6, NO_RELAYS=-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 cXWAtPiwJv54 for ; Wed, 24 Mar 2010 07:52:58 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id DB3F03A6835 for ; Wed, 24 Mar 2010 07:52:57 -0700 (PDT) Received: from ra-gorry.erg.abdn.ac.uk ([IPv6:2001:df8:0:24:21e:c2ff:febe:4c73]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id o2OEr2qf004283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Mar 2010 14:53:04 GMT Message-ID: <4BAA274E.6050603@erg.abdn.ac.uk> Date: Wed, 24 Mar 2010 07:53:02 -0700 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: mallman@icir.org References: <20100324133205.95CFDBB8831@lawyers.icir.org> In-Reply-To: <20100324133205.95CFDBB8831@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 14:52:59 -0000 On 24/03/2010 06:32, Mark Allman wrote: > >> My rationale is that there are transport methods that use >> retransmission of a SYN as the indication that there may be something >> problematic with the path, and then modify their behaviour. > > I wasn't in the meeting so perhaps I don't have the right context here. > But, I guess I don't quite see the concern. Presumably these methods > actually help the cause---not hurt it. > > I.e., if I send a SYN-with-ECN and then spuriously RTO because I am > traversing a long path I will send a SYN-w/o-ECN. When I see a SYN-ACK > I'll be able to tell which SYN triggered it and therefore do the right > thing (i.e., get an RTT sample, tell if the retransmit was likely > spurious or not, etc.). > > Am I missing something here? > > allman > Thanks Mark, I wasn't saying the method broke ECN negotiation, and other things that work in this way. I wanted to be sure that implementors would realise that this MUST be handled correctly, and avoid finding that people over-focused on short paths, without realising that the 1st RTO expiry on a 1-3 sec path did NOT necessarily indicate a path problem. I could imagine a (bad) implementation that sent a SYN+ECN and the RTO expired, it then concluded that ECN (or whatever) wasn't supported, cleared the internal flag that indicates ECN would be used, and then sends a simple SYN. Whereas, what you outline seems good practice and I think says that the sender should take the received SYN-ACK+ECN as indication that ECN can be used (even if the sender knows the last SYN did not include this option, and the next SYN-ACK does not). I think this detail was not clear when ECN, QuickStart, etc was standardised. If this approach was called-out in the document this would seem to be good. Gorry From mallman@icir.org Wed Mar 24 07:58:21 2010 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 A4CA03A6A36 for ; Wed, 24 Mar 2010 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 AeCEQ-GEcmcP for ; Wed, 24 Mar 2010 07:58:20 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id CBCF33A68E1 for ; Wed, 24 Mar 2010 07:58:15 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2OEwXPv012088; Wed, 24 Mar 2010 07:58:33 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7E120BBAA52; Wed, 24 Mar 2010 10:58:33 -0400 (EDT) To: gorry@erg.abdn.ac.uk From: Mark Allman In-Reply-To: <4BAA274E.6050603@erg.abdn.ac.uk> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma10393-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Mar 2010 10:58:33 -0400 Sender: mallman@icir.org Message-Id: <20100324145833.7E120BBAA52@lawyers.icir.org> Cc: tcpm@ietf.org Subject: Re: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 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, 24 Mar 2010 14:58:21 -0000 ----------ma10393-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I think this detail was not clear when ECN, QuickStart, etc was > standardised. More than likely because spurious retransmissions after 3sec are pretty rare. > If this approach was called-out in the document this > would seem to be good. Your point is fair and I have made a note to include some words in a next revision of the document (assuming the WG thinks its a reasonable thing to work on in the first place). allman ----------ma10393-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuqKJkACgkQWyrrWs4yIs4YigCfSkQIUFMtrx7n3Ez0VrFMa8pV xSwAn2xpqODKS06ssSkIeWb1SvnZGicC =BqaS -----END PGP SIGNATURE----- ----------ma10393-1-- From Alexander.Zimmermann@nets.rwth-aachen.de Wed Mar 24 08:18:15 2010 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 F05473A6B50 for ; Wed, 24 Mar 2010 08:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 nD3xRwn7kXtW for ; Wed, 24 Mar 2010 08:18:14 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 8FF533A6B4B for ; Wed, 24 Mar 2010 08:18:13 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 24A635787E; Wed, 24 Mar 2010 16:18:33 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 24 Mar 2010 16:18:21 +0100 From: Alexander Zimmermann To: "" Thread-Topic: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 Thread-Index: AQHKytaTpyyzNsDO0EiRhJ76w9d+BJIBBliAgAAWngCAAAGLgIAABZGA Date: Wed, 24 Mar 2010 15:18:29 +0000 Message-ID: References: <20100324145833.7E120BBAA52@lawyers.icir.org> In-Reply-To: <20100324145833.7E120BBAA52@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <784874e1-3d57-4160-b3bb-df361c5c808a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [tcpm] SYN retransmission with draft-paxson-tcpm-rfc2988bis-00 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, 24 Mar 2010 15:18:15 -0000 Am 24.03.2010 um 07:58 schrieb Mark Allman: > (assuming the WG thinks its a reasonable > thing to work on in the first place). YES :-) >=20 > allman >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From mahesh@cisco.com Wed Mar 24 08:26:28 2010 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 255293A6B6C for ; Wed, 24 Mar 2010 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 v9uzVO6N-NI3 for ; Wed, 24 Mar 2010 08:26:27 -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 E04D43A6949 for ; Wed, 24 Mar 2010 08:26:25 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvMqUurR7H+/2dsb2JhbACbHnOmQpkJgk+CLwSDHoZm X-IronPort-AV: E=Sophos;i="4.51,301,1267401600"; d="scan'208";a="502154759" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 24 Mar 2010 15:26:42 +0000 Received: from [10.21.107.174] (sjc-vpnasa-942.cisco.com [10.21.107.174]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2OFQeBQ004010 for ; Wed, 24 Mar 2010 15:26:41 GMT Message-ID: <4BAA2F34.4000908@cisco.com> Date: Wed, 24 Mar 2010 08:26:44 -0700 From: Mahesh Jethanandani Organization: Cisco Systems Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tcpm] Second TCPM session on Wednesday, 10:15 AM 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, 24 Mar 2010 15:26:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to attend via a WebEx session. On 3/23/2010 5:53 PM, David Borman wrote: > The room in which we will be meeting does not have audio or video. Is there anyone not at the IETF meeting that would like to attend this meeting? If so, we can see about setting up a WebEx session. Please respond ASAP if you would like to attend via WebEx, so we can get it set up. > -David Borman > > On Mar 22, 2010, at 7:04 PM, David Borman wrote: > >> The TCPM agenda has filled up, and we really want to have some time to work on the TCP security document. So, we have gotten a second time slot, on Wednesday morning at 10:15 AM in Pacific A. The goal of this second session is to go through the TCP Security document and try to identify what items everyone agrees with, and what items are contentious. From this we would be able to take the easy ones and get them formatted up pretty quickly, and allow the mailing list discussions to focus on the items that need discussion. >> >> -David Borman and Wes Eddy, TCPM co-chairs. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm - -- *Mahesh Jethanandani* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLqi80AAoJEP9ZPWIqKBmiIioH/1fhscdtpO9/LYo8K7rWAKkX +OHDgJhXFOpFf0uwWT3Y6v4noLI1FKL32mBgY5rj8gHqa/pCEZKgZHeJZiqWvqJp +F25fgoImqyRurKRaJM/+nCUmnLelgqE8ZhTTk/XpLlK2k1KZG5ADLI3EyFD49gP NM83KExNQv7lfl5i3p66yiG4fpiMgpaxgaQUVlG0mZpKt0y3Xovwq1NkH4fZLM2B hmBWjtsZUuJ/Hf4X/shvZbGL6uXy4Egec0o0I9iogrCmUmAHtIkVtqTZ03CGjHSm l7hZUPD1fh+St1/+uTPmQJ9H7hJngTxZM+J+bJJcaq1pYTAriSkRxLMDNCWDkf0= =BksK -----END PGP SIGNATURE----- From david.borman@windriver.com Wed Mar 24 09:00:56 2010 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 BD2BC3A6BAD for ; Wed, 24 Mar 2010 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 2hp+BX1YQMys for ; Wed, 24 Mar 2010 09:00:55 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 0364E3A6BC2 for ; Wed, 24 Mar 2010 08:57:34 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o2OFvOMP023931; Wed, 24 Mar 2010 08:57:24 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Mar 2010 08:57:24 -0700 Received: from unknown-233-11.windriver.com ([147.11.233.11]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Mar 2010 08:57:23 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <4BAA2F34.4000908@cisco.com> Date: Wed, 24 Mar 2010 08:57:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BAA2F34.4000908@cisco.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 24 Mar 2010 15:57:23.0504 (UTC) FILETIME=[B14C9B00:01CACB6A] Cc: tcpm@ietf.org Subject: Re: [tcpm] Second TCPM session on Wednesday, 10:15 AM 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, 24 Mar 2010 16:00:56 -0000 Well, I asked about this, and it turns out I spoke too soon. When I = asked this morning at registration, they said only 2 rooms were set up = to do WebEx. So there doesn't appear to be enough time to get something = set up, my apologies. -David On Mar 24, 2010, at 8:26 AM, Mahesh Jethanandani wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I would like to attend via a WebEx session. >=20 > On 3/23/2010 5:53 PM, David Borman wrote: >> The room in which we will be meeting does not have audio or video. = Is there anyone not at the IETF meeting that would like to attend this = meeting? If so, we can see about setting up a WebEx session. Please = respond ASAP if you would like to attend via WebEx, so we can get it set = up. >> -David Borman >>=20 >> On Mar 22, 2010, at 7:04 PM, David Borman wrote: >>=20 >>> The TCPM agenda has filled up, and we really want to have some time = to work on the TCP security document. So, we have gotten a second time = slot, on Wednesday morning at 10:15 AM in Pacific A. The goal of this = second session is to go through the TCP Security document and try to = identify what items everyone agrees with, and what items are = contentious. =46rom this we would be able to take the easy ones and get = them formatted up pretty quickly, and allow the mailing list discussions = to focus on the items that need discussion. >>>=20 >>> -David Borman and Wes Eddy, TCPM co-chairs. >>> _______________________________________________ >>> 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 > *Mahesh Jethanandani* > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iQEcBAEBAgAGBQJLqi80AAoJEP9ZPWIqKBmiIioH/1fhscdtpO9/LYo8K7rWAKkX > +OHDgJhXFOpFf0uwWT3Y6v4noLI1FKL32mBgY5rj8gHqa/pCEZKgZHeJZiqWvqJp > +F25fgoImqyRurKRaJM/+nCUmnLelgqE8ZhTTk/XpLlK2k1KZG5ADLI3EyFD49gP > NM83KExNQv7lfl5i3p66yiG4fpiMgpaxgaQUVlG0mZpKt0y3Xovwq1NkH4fZLM2B > hmBWjtsZUuJ/Hf4X/shvZbGL6uXy4Egec0o0I9iogrCmUmAHtIkVtqTZ03CGjHSm > l7hZUPD1fh+St1/+uTPmQJ9H7hJngTxZM+J+bJJcaq1pYTAriSkRxLMDNCWDkf0=3D > =3DBksK > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Wed Mar 24 09:22:29 2010 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 6A4673A68D9 for ; Wed, 24 Mar 2010 09:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.017 X-Spam-Level: * X-Spam-Status: No, score=1.017 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_35=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 UOTGv6XgL-PE for ; Wed, 24 Mar 2010 09:22:17 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A04323A6BE8 for ; Wed, 24 Mar 2010 09:21:49 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id D9A8D6B680C; Wed, 24 Mar 2010 13:22:11 -0300 (ART) Received: from [192.168.0.102] (13-132-17-190.fibertel.com.ar [190.17.132.13]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2OGM62d014186; Wed, 24 Mar 2010 13:22:07 -0300 Message-ID: <4BAA3C2F.8090008@gont.com.ar> Date: Wed, 24 Mar 2010 13:22:07 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mallman@icir.org References: <20100324130906.9A725BB65C7@lawyers.icir.org> In-Reply-To: <20100324130906.9A725BB65C7@lawyers.icir.org> X-Enigmail-Version: 0.96.0 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]); Wed, 24 Mar 2010 13:22:11 -0300 (ART) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 16:22:29 -0000 Hi, Mark, >> (1) provides a scheme that >> complies with such requirement > > Yep, it does. > > But, (1) does not somehow uniquely address that requirement. Agreed. >> and that also has the good property that it makes it hard for an >> off-path attacker to guess the timestamps in use by victim >> connections. > > The question is whether this is really important or not. If the question is whether I think this is a vector that is currently being exploited or that will be exploited in the near term, I fully agree with you: I believe this is very unlikely. However, 32 bits of additional "state information" doesn't look like a big deal to me. So my argument was (?) that would fail on the side of unpredictable timestamps (i.e., this is so cheap....). -- but please see the end of this e-mail. >>> Or, at least perhaps we could see more motivation for (1) that would >>> sway us to understanding the tangible benefit it offers. >> Using unpredictable values is acting pro-actively. If we, say, propose [....] > option to make it even harder to mess with the connection? If you want > to be so pro-active why are we not just saying every TCP connection > should use the auth option? Or, IPsec? I guess two possible answers would be: * They are not a local policy, such as this algorithm (you do need the other side to cooperate to get TCP-AO or IPsec working) * They're hard to deploy for the general case, in practice. (But yes, I see your point) > So then, yeah, with timestamps you also have to pass the PAWS check on > top of all that and so its even harder. And, if you can somehow find an > endhost's global clock then this reduces to the non-timestamp case. > But, if you can't then you have some additional shot in the dark. But, > even without adding this additional variable I hope you can see my > skepticism and thinking that this adds basically nothing tangible to the > situation because the bar is already So Damn High. As mentioned above, I fully agree with you. For the most part, my take is (was?) that the overhead needed for unpredictable timestamps is so small that *I* would fail on the side of unpredictable timestamps. That said, if we don't recommend the RFC1948-like scheme, one could mention it as a "possible" approach ("MAY", or just an appendix with no RFC2119 text... or well, completely remove it if the wg decides so). I'd argue that the I-D should probably mention that if a global clock is used, the initial value should be randomized at system boot time, so that the system uptime is not leaked. >> Actually, at least part of this discussion has already taken place: >> there's a CERT advisory on predictable timestamps (I think I referenced >> it in the I-D), > > I can't find the reference in the I-D. Can you provide it? Perhaps > they have more substantive motivation that you are providing. It's "US-CERT Vulnerability Note VU#637934", available at: https://www.kb.cert.org/vuls/id/637934 -- I realize that while it discusses a timestamps-based vulnerability, it does not really discusses predictable timestamps (sorry :-( ). FWIW, re-reading this advisory caused me to re-analyze some of the "timestamps randomization" stuff: * While Section 4.2.2 of RFC1323 states some requirements for the Timestamp Clock, receivers don't "enforce" these requirements. That is, the timestamp will be considered valid if SEG.TSval >= TS.Recent. That means that an attacker would need to try only two timestamps to guess a "valid" one. * So the timestamps don't really add much to the mitigation of off-path attacks, and in that case, a global counter that is initialized at system boot time with a random value would do. (I guess that one could implement some type of "timestamps window", but this *would* be unnecessarily complex. -- Just for curiosity sake, I'll probably check the proposal that was made in 2005 (by Kacheong Poon?) to use timestamps as a mitigation for off-path attacks, to figure out how they used timestamps for this purpose). 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 touch@ISI.EDU Wed Mar 24 09:56:56 2010 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 CBC653A6BF3 for ; Wed, 24 Mar 2010 09:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 V1x7y-2htkkW for ; Wed, 24 Mar 2010 09:56:56 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C86EA3A6BC9 for ; Wed, 24 Mar 2010 09:56:55 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2OGte9d019425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 09:55:42 -0700 (PDT) Message-ID: <4BAA440C.9080707@isi.edu> Date: Wed, 24 Mar 2010 09:55:40 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100324031529.899D6BB39B1@lawyers.icir.org> In-Reply-To: <20100324031529.899D6BB39B1@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig828091EF141533284D03E3EB" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 16:56:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig828091EF141533284D03E3EB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Overall, I'll agree with what Mark posted below, except that I'm still not sure this whole thing makes sense. As per subsequent exchanges, the doc breaks into three separate issues: 1) random starting timestamp 2) monotonically increasing timestamp (required only per socket-pair) 3) TIME_WAIT truncation Note that #1 interferes with #2, because selecting a timestamp in the high end of the number space could present problems in maintaining #2 over the long term for very busy hosts. However, let's put that aside for now, since we can easily say "pick something in the low 1/2 of the range)" to address that issue. The issues with #1 being a protection have already been discussed. Depending on how #1 is specified, there are varying implications. The current spec for #1 requires: a- a hash per socket pair (e.g., on receipt of a SYN) b- larger retained state during TIME_WAIT c- retained state beyond TIME_WAIT (to enforce #2, since the timestamp start is per-socketpair) (a) is expensive - 20 instructions per 32-bit word *in the critical path*, or 520 instructions. Compare that to roughly 100-300 instructions to process a TCP packet. You're more than doubling the cost for TCP processing in just this one step; other steps (randomizing ISN, etc.) make things worse. The only way around this is for everyone - client and server - to keep per-socketpair timestamps around for a long time. (b) is no big deal (c), however, is huge. Busy servers already toss out TIME_WAITs early to save space. There's very little reason to believe they'd keep per-socketpair timestamps around to ensure monotonicity. So let's expect that (c) won't happen. That means (a) requires computation, which is bad. The only way to recover this, AFAICT, is to claim that the timestamp_start is selected by some arbitrary function, but reused across connections. It can't - and doesn't need to be - per-connection specific. Take that out of the equation, and we get: timestamp =3D T() + secret_key That's fast, ensures #2, and allows #3 without the need to retain state even after TIME_WAIT is gone. Since we don't need the F(socketpair) part, let's strip that out and move on - and call this what it is: "Reducing TIME_WAIT using timestamps" The randomization part is marginally useful, but not the most significant part of this mechanism, IMO. Joe --------------enig828091EF141533284D03E3EB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuqRAwACgkQE5f5cImnZrtQvACg3RL4z2qVZSoSFHXncKGTZo44 wUQAoMYhs0Hp60yxg3qC/6Z1WpDAGXKi =RY38 -----END PGP SIGNATURE----- --------------enig828091EF141533284D03E3EB-- From gregory.ietf@gmail.com Wed Mar 24 10:36:37 2010 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 4C8523A68A3 for ; Wed, 24 Mar 2010 10:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.144 X-Spam-Level: X-Spam-Status: No, score=-99.144 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 jqm--s0FtoyW for ; Wed, 24 Mar 2010 10:36:36 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 049C53A6C59 for ; Wed, 24 Mar 2010 10:36:35 -0700 (PDT) Received: by iwn35 with SMTP id 35so4983472iwn.31 for ; Wed, 24 Mar 2010 10:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=CK88KevUjYjDBDXj0B5DzrLxt1nFNFUlFOqdTHQCr2s=; b=MI6OcIcTicb6nmHMwaduiL/fpA5i93whYWrC2tC/bCnfD1bH9/iMolmZCmLi1T1VdR Cb9JPca0ptPaoJ4qc2qJZs/dR2IGkL9IBl4jRWac7EML2VpOgaI5eZxabNSmn/CfCRh2 M7jzIXpaYe6eTcDaBvoUAG65PGQG3odfauHcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=nNB9UvlndhsJoziXQlTxDxLd6Bm81GMYjGQvfhGFYMdU8OnlqGtMFS5gWkXx7ZisXk Bq5YUq5esfFOMhDUXTTuly/Nsmf7oKzePuNXjlt4KFR5o9Xdg6Gfh5YNghEbG3uboOTg JSvmWnHe83pOi0Jl1XhAai7bX49p7t7Ff0TUk= MIME-Version: 1.0 Received: by 10.231.182.79 with SMTP id cb15mr1497753ibb.71.1269452214118; Wed, 24 Mar 2010 10:36:54 -0700 (PDT) Date: Wed, 24 Mar 2010 10:36:54 -0700 Message-ID: From: Gregory Lebovitz To: Lars Eggert , Pasi Eronen Content-Type: multipart/alternative; boundary=001485e5bfac482b2d04828f6029 Cc: "tcpm-chairs@tools.ietf.org" , tcpm@ietf.org, Joe Touch Subject: Re: [tcpm] draft-ietf-tcpm-tcp-AO-crypto 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: Wed, 24 Mar 2010 17:36:37 -0000 --001485e5bfac482b2d04828f6029 Content-Type: text/plain; charset=ISO-8859-1 Update 10:33-- I'm about to submit. -I have cleared the issue w/ IANA, and sent email on it -the formatting of the ToC is borked, but not even the xml2rfc guys (Brian Rosen) could figure out why. Mitigation: I sat with RFC editor, and they'll fix it in Auth48. No action needed by any of us. -There is one question Michelle (IANA) asked about location of the registry. I'll send that under separate cover. It does not affect IESG clearing review, and can be handled in Auth48. Phew, Gregory. On Wed, Mar 24, 2010 at 8:02 AM, Gregory Lebovitz wrote: > Update: > -I have almost all the changes made in the XML; you'll see emails about > these. > -open issue re: IANA section, and I am visiting the IANA table this morning > to try to get that answered. > -I was up until 03:30 trying to get the XML to build correctly, but it's > still failing on two things. I'm trying to get help this morning on it. > -Pasi says he can approve until today. > > I'll keep you posted, > Gregory > > > On Tue, Mar 23, 2010 at 5:55 PM, Joe Touch wrote: > >> Today would be a big deal, IMO. >> >> Joe >> >> Lars Eggert wrote: >> > Hi, >> > >> > On 2010-3-23, at 23:48, Gregory Lebovitz wrote: >> >> re: AO-crypto, I'll do an update (while I'm in these next two WG >> sessions) that addresses Passi's discuss. Then I'll publish that. >> >> >> >> I also got a genArt review that needs to be included, and I can do that >> update tomorrow. Will that suffice? >> > >> > If it's the same gen-art review I saw (from Avshalom Houri), is seems to >> be very minor. >> > >> > It at all possible, an update today would be good, because the outgoing >> ADs loose ballot rights today (I think). >> > >> > Lars >> > >> >> NOTE: pls include my "gregory.ietf@gmail.com" address in follow on >> emails, as I'm not checking the "gregory@juniper.net" much this week, but >> focusing on the other. >> >> >> >> Gregory. >> >> >> >> ________________________________________ >> >> From: Lars Eggert [lars.eggert@nokia.com] >> >> Sent: Tuesday, March 23, 2010 1:20 PM >> >> To: Joe Touch >> >> Cc: Gregory Lebovitz; tcpm-chairs@tools.ietf.org >> >> Subject: Re: AO >> >> >> >> What matters is whether the folks who raised the issues are OK with >> this resolution. If you believe this is the case, submit the revision and I >> will ask people to check and clear their discusses. >> >> >> >> On 2010-3-23, at 11:29, Joe Touch wrote: >> >> >> >>> Lars, >> >>> >> >>> Just to check, there are two additional adds I wanted to consider: >> >>> >> >>> 1) clarify that ICMP filtering applied only to connections in >> ESTABLISHED >> >>> this is consistent with RFC 5461 >> >>> >> >>> 2) clarify that TCP keepalives and/or recoverable storage for traffic >> >>> keys can be replaced by BGP keepalives >> >>> i.e., that's when BGP makes sure the connection never goes >> >>> idle, and thus would timeout on data delivery failure if the >> >>> other side reboots anyway >> >>> >> >>> Let me know ASAP if these are OK. >> >>> >> >>> Joe >> >>> >> >>> Lars Eggert wrote: >> >>>> Hi, Joe and Greg, >> >>>> >> >>>> if at all possible, could you send updates to the ao and crypto >> documents today (= in a few hours)? >> >>>> >> >>>> The reason is (as Pasi reminds me) that the old ADs loose their >> ballot rights today and new new ADs get theirs. In other words, you'd deal >> with a different set of ADs who will likely re-review the documents and may >> find new issues, causing further delay. >> >>>> >> >>>> We're very close to being done, and I'd like to avoid that. Pasi & >> others have promised to clear before they step down if you can get updates >> submitted that address their concerns. >> >>>> >> >>>> Lars >> > >> >> > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --001485e5bfac482b2d04828f6029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Update 10:33--
I'm about to submit.=A0
-I have cleared th= e issue w/ IANA, and sent email on it
-the formatting of the ToC = is borked, but not even the xml2rfc guys (Brian Rosen) could figure out why= . Mitigation: I sat with RFC editor, and they'll fix it in Auth48. No a= ction needed by any of us.
-There is one question Michelle (IANA) asked about location of the reg= istry. I'll send that under separate cover. It does not affect IESG cle= aring review, and can be handled in Auth48.=A0

Phe= w,
Gregory.

On Wed, Mar 24,= 2010 at 8:02 AM, Gregory Lebovitz <gregory.ietf@gmail.com> wrote:
Update:
-I have almost all the changes made in the XML; you'll see = emails about these.
-open issue re: IANA section, and I am visiti= ng the IANA table this morning to try to get that answered.
-I was = up until 03:30 trying to get the XML to build correctly, but it's still= failing on two things. I'm trying to get help this morning on it.
-Pasi says he can approve until today.

I'= ll keep you posted,
Gregory


On Tue, Mar 23, 2010 at 5:55 PM, Joe Touch <touch@isi.edu> wrote:
Today would be a big deal, IMO.

Joe

Lars Eggert wrote:
> Hi,
>
> On 2010-3-23, at 23:48, Gregory Lebovitz wrote:
>> re: AO-crypto, I'll do an update (while I'm in these next = two WG sessions) that addresses Passi's discuss. Then I'll publish = that.
>>
>> I also got a genArt review that needs to be included, and I can do= that update tomorrow. Will that suffice?
>
> If it's the same gen-art review I saw (from Avshalom Houri), is se= ems to be very minor.
>
> It at all possible, an update today would be good, because the outgoin= g ADs loose ballot rights today (I think).
>
> Lars
>
>> NOTE: pls include my "gregory.ietf@gmail.com" address in follow on = emails, as I'm not checking the "gregory@juniper.net" much this week, but f= ocusing on the other.
>>
>> Gregory.
>>
>> ________________________________________
>> From: Lars Eggert [lars.eggert@nokia.com]
>> Sent: Tuesday, March 23, 2010 1:20 PM
>> To: Joe Touch
>> Cc: Gregory Lebovitz; tcpm-chairs@tools.ietf.org
>> Subject: Re: AO
>>
>> What matters is whether the folks who raised the issues are OK wit= h this resolution. If you believe this is the case, submit the revision and= I will ask people to check and clear their discusses.
>>
>> On 2010-3-23, at 11:29, Joe Touch wrote:
>>
>>> Lars,
>>>
>>> Just to check, there are two additional adds I wanted to consi= der:
>>>
>>> 1) clarify that ICMP filtering applied only to connections in = ESTABLISHED
>>> =A0 =A0 =A0this is consistent with RFC 5461
>>>
>>> 2) clarify that TCP keepalives and/or recoverable storage for = traffic
>>> keys can be replaced by BGP keepalives
>>> =A0 =A0 =A0i.e., that's when BGP makes sure the connection= never goes
>>> =A0 =A0 =A0idle, and thus would timeout on data delivery failu= re if the
>>> =A0 =A0 =A0other side reboots anyway
>>>
>>> Let me know ASAP if these are OK.
>>>
>>> Joe
>>>
>>> Lars Eggert wrote:
>>>> Hi, Joe and Greg,
>>>>
>>>> if at all possible, could you send updates to the ao and c= rypto documents today (=3D in a few hours)?
>>>>
>>>> The reason is (as Pasi reminds me) that the old ADs loose = their ballot rights today and new new ADs get theirs. In other words, you&#= 39;d deal with a different set of ADs who will likely re-review the documen= ts and may find new issues, causing further delay.
>>>>
>>>> We're very close to being done, and I'd like to av= oid that. Pasi & others have promised to clear before they step down if= you can get updates submitted that address their concerns.
>>>>
>>>> Lars
>




--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks



--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--001485e5bfac482b2d04828f6029-- From root@core3.amsl.com Wed Mar 24 10:45:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DD35C3A6872; Wed, 24 Mar 2010 10:45: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: <20100324174501.DD35C3A6872@core3.amsl.com> Date: Wed, 24 Mar 2010 10:45:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-ao-crypto-03.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, 24 Mar 2010 17:45:02 -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 : Cryptographic Algorithms for TCP's Authentication Option, TCP-AO Author(s) : G. Lebovitz, E. Rescorla Filename : draft-ietf-tcpm-tcp-ao-crypto-03.txt Pages : 16 Date : 2010-03-24 The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism, and provides the interface for future MACs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-03.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-ao-crypto-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-24103750.I-D@ietf.org> --NextPart-- From gregory.ietf@gmail.com Wed Mar 24 10:49:43 2010 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 C51073A68B2 for ; Wed, 24 Mar 2010 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.964 X-Spam-Level: X-Spam-Status: No, score=-99.964 tagged_above=-999 required=5 tests=[AWL=1.504, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 vQF8jk5tJZGx for ; Wed, 24 Mar 2010 10:49:42 -0700 (PDT) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 2B3813A6910 for ; Wed, 24 Mar 2010 10:49:36 -0700 (PDT) Received: by pxi7 with SMTP id 7so3524164pxi.5 for ; Wed, 24 Mar 2010 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=IUbSJ4jAoRDWn/ZXPBuyNsiGfNC9ZhbEpRRIMKSUnKw=; b=Fhr0jeIxMfSxkjuIdbjaKof40y4ybgPSUjWrHVop49w2q2phz0j5sQazZ7JPOR0RoY +1d/WfnRxWBJ2L/1XZfzkOYZfHMwr9Gyylh2EIrmCGj+4NsHjPuMExhOeVkzadf/fcOA ytPbzo6cYfm7uORmHp5IOIcQG+k9tHHAf6wwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=UbmnvUzJUAGLS7mI5Le34jF4hDQpDQCUPupPw3bCZivpxxGVZ0euEhbXpdSy6AxQy5 fcdHya430lpTXPu1lTlnOBsSyMZuV8nHce5KtxrxgCp/Avp0LSrQKNPd8t/lufYrXyKw NkO/AGFFmlg2jsoW9CtcNgtjwkgMSoX2fJIX4= MIME-Version: 1.0 Received: by 10.141.2.4 with SMTP id e4mr8903224rvi.192.1269452991351; Wed, 24 Mar 2010 10:49:51 -0700 (PDT) Date: Wed, 24 Mar 2010 10:49:51 -0700 Message-ID: From: Gregory Lebovitz To: tcpm-chairs@tools.ietf.org, Lars Eggert , michelle.cotton@icann.org Content-Type: multipart/alternative; boundary=000e0cd1191e9bcc3e04828f8ec8 Cc: ekr@rtfm.com, tcpm@ietf.org, iana@iana.org Subject: [tcpm] tcp-ao-crypto-03, IANA registry location question 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, 24 Mar 2010 17:49:43 -0000 --000e0cd1191e9bcc3e04828f8ec8 Content-Type: text/plain; charset=ISO-8859-1 Draft-03 has now published addressing all issues. Michelle (IANA team) had a good question: Should the registry for this, "Cryptographic Algorithms for TCP-AO", be stand alone or should it sit under the current "tcp-parameters" registration? FYI, the other things in that "tcp-parameters" registry today are only two: TCP Option Kind Numbers, and TCP Alternate Checksum Numbers The specific question IANA will need answered: Do we want to (1) add "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" registry or (2) Create "Cryptographic Algorithims for TCP-AO" as a stand-alone registry Magnus happened to walk by while I was at IANA table with Michelle, and we both thought (1) above was best. Chairs? Lars? Michelle advises that IESG can clear the document, and we can address this in Auth48. Gregory On Wed, Mar 24, 2010 at 10:37 AM, IETF I-D Submission Tool < idsubmission@ietf.org> wrote: > > A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-03.txt has been > successfully submitted by Gregory Lebovitz and posted to the IETF > repository. > > Filename: draft-ietf-tcpm-tcp-ao-crypto > Revision: 03 > Title: Cryptographic Algorithms for TCP's Authentication Option, > TCP-AO > Creation_date: 2010-03-24 > WG ID: tcpm > Number_of_pages: 16 > > Abstract: > The TCP Authentication Option, TCP-AO, relies on security algorithms > to provide authentication between two end-points. There are many > such algorithms available, and two TCP-AO systems cannot interoperate > unless they are using the same algorithms. This document specifies > the algorithms and attributes that can be used in TCP-AO's current > manual keying mechanism, and provides the interface for future MACs. > > > > The IETF Secretariat. > > > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --000e0cd1191e9bcc3e04828f8ec8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Draft-03 has now published addressing all issues.

=
Michelle (IANA team) had a good question:

Sho= uld the registry for this, "Cryptographic Algorithms for TCP-AO",= be stand alone or should it sit under the current=A0"tcp-parameters&q= uot; registration? FYI, the other things in that "tcp-parameters"= registry today are only two: =A0
=A0=A0TCP Option Kind Numbers, and=A0
=A0=A0TCP Alternate Ch= ecksum Numbers

The specific question IANA will nee= d answered:
Do we want to
(1) add "Cryptographic A= lgorithms for TCP-AO" =A0as a "tcp-parameter" registry
or
(2) Create "Cryptographic Algorithims for TCP-AO&quo= t; as a stand-alone registry

Magnus happened to wa= lk by while I was at IANA table with Michelle, and we both thought (1) abov= e was best. Chairs? Lars?

Michelle advises that IESG can clear the document, and = we can address this in Auth48.

Gregory

On Wed, Mar 24, 2010 at 10:37 AM, IETF I-D Submiss= ion Tool <ids= ubmission@ietf.org> wrote:

A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-03.txt has been success= fully submitted by Gregory Lebovitz and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-tcpm-tcp-ao-crypto
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Cryptographic Algorithms for TCP's Authentic= ation Option, TCP-AO
Creation_date: =A0 2010-03-24
WG ID: =A0 =A0 =A0 =A0 =A0 tcpm
Number_of_pages: 16

Abstract:
The TCP Authentication Option, TCP-AO, relies on security algorithms
to provide authentication between two end-points. =A0There are many
such algorithms available, and two TCP-AO systems cannot interoperate
unless they are using the same algorithms. =A0This document specifies
the algorithms and attributes that can be used in TCP-AO's current
manual keying mechanism, and provides the interface for future MACs.



The IETF Secretariat.





--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--000e0cd1191e9bcc3e04828f8ec8-- From fernando@gont.com.ar Wed Mar 24 11:13:20 2010 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 E27693A6CAA for ; Wed, 24 Mar 2010 11:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=1.815, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 L5gsJda2a+fY for ; Wed, 24 Mar 2010 11:13:20 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 988863A6A79 for ; Wed, 24 Mar 2010 11:13:18 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 478C46B65C1; Wed, 24 Mar 2010 15:13:38 -0300 (ART) Received: from [192.168.0.102] (13-132-17-190.fibertel.com.ar [190.17.132.13]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2OIDW4R004147; Wed, 24 Mar 2010 15:13:33 -0300 Message-ID: <4BAA564C.7080308@gont.com.ar> Date: Wed, 24 Mar 2010 15:13:32 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <20100324031529.899D6BB39B1@lawyers.icir.org> <4BAA440C.9080707@isi.edu> In-Reply-To: <4BAA440C.9080707@isi.edu> X-Enigmail-Version: 0.96.0 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]); Wed, 24 Mar 2010 15:13:37 -0300 (ART) Cc: "tcpm@ietf.org" , mallman@icir.org Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 18:13:21 -0000 Joe Touch wrote: > As per subsequent exchanges, the doc breaks into three separate issues: > > 1) random starting timestamp > 2) monotonically increasing timestamp > (required only per socket-pair) > 3) TIME_WAIT truncation > > Note that #1 interferes with #2, because selecting a timestamp in the > high end of the number space could present problems in maintaining #2 > over the long term for very busy hosts. I don't follow this. The timestamp clock can be initilized to a random value. Once initilized, it's simply incremented as a counter. How does this interfere with #2? > However, let's put that aside > for now, since we can easily say "pick something in the low 1/2 of the > range)" to address that issue. Timestamps are compared in the same way as sequence numbers, IIRC. So you don't need to implement this "low 1/2" magic.... > The issues with #1 being a protection have already been discussed. > Depending on how #1 is specified, there are varying implications. > > The current spec for #1 requires: > > a- a hash per socket pair (e.g., on receipt of a SYN) > > b- larger retained state during TIME_WAIT I don't follow "b". What's the additional state here? You just need to keep TS.Recent, as RFC1323 already requires -- there's no additional state. > c- retained state beyond TIME_WAIT (to enforce #2, > since the timestamp start is per-socketpair) I don't follow this one, either. With the current I-D, timestamps are generated in the same way ISNs are generated with RFC1948. So there's no requirement of "retained state beyond TIME-WAIT state". Actually, this is the beuty of the RFC1948 scheme. > (a) is expensive - 20 instructions per 32-bit word *in the critical > path*, or 520 instructions. Compare that to roughly 100-300 instructions > to process a TCP packet. You're more than doubling the cost for TCP > processing in just this one step; other steps (randomizing ISN, etc.) > make things worse. The only way around this is for everyone - client and > server - to keep per-socketpair timestamps around for a long time. Can you elaborate this statement a bit more? > (b) is no big deal > > (c), however, is huge. Busy servers already toss out TIME_WAITs early to > save space. There's very little reason to believe they'd keep > per-socketpair timestamps around to ensure monotonicity. There's no need for that. Servers can still toss the TIME-WAIT state as they currently do, with no harm. > So let's expect that (c) won't happen. That means (a) requires > computation, which is bad. > > The only way to recover this, AFAICT, is to claim that the > timestamp_start is selected by some arbitrary function, but reused > across connections. It can't - and doesn't need to be - per-connection > specific. If the current proposed scheme (i.e., RFC1948-like) is used, initialization doesn't matter: it's F() that provides the randomness. If we recommend "a global timestamp shared by all connections", you just initilize it to a random value at system boot time, just so that the system uptime is not leaked. -- and that's it. 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 lars.eggert@nokia.com Wed Mar 24 11:17:21 2010 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 A4C813A6D50 for ; Wed, 24 Mar 2010 11:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 W7keBuDrZYvS for ; Wed, 24 Mar 2010 11:17:20 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0389B3A6C36 for ; Wed, 24 Mar 2010 11:17:19 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2OIH3Fu013966; Wed, 24 Mar 2010 20:17:13 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 20:17:12 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Mar 2010 20:17:11 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2OIHAjC011888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 20:17:10 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-87--910363657; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 24 Mar 2010 11:16:52 -0700 Message-Id: <1D49B1F3-AA12-459B-8D9F-2179D666A100@nokia.com> References: To: Gregory Lebovitz X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 24 Mar 2010 20:17:02 +0200 (EET) X-OriginalArrivalTime: 24 Mar 2010 18:17:11.0593 (UTC) FILETIME=[38FD6990:01CACB7E] X-Nokia-AV: Clean Cc: "tcpm-chairs@tools.ietf.org" , "ekr@rtfm.com" , "tcpm@ietf.org" , "michelle.cotton@icann.org" , "iana@iana.org" Subject: Re: [tcpm] tcp-ao-crypto-03, IANA registry location question 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, 24 Mar 2010 18:17:21 -0000 --Apple-Mail-87--910363657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-3-24, at 10:49, Gregory Lebovitz wrote: > The specific question IANA will need answered: > Do we want to > (1) add "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" = registry > or > (2) Create "Cryptographic Algorithims for TCP-AO" as a stand-alone = registry >=20 > Magnus happened to walk by while I was at IANA table with Michelle, = and we both thought (1) above was best. Chairs? Lars? (1) seems fine. Lars --Apple-Mail-87--910363657 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDMyNDE4MTY1MlowIwYJKoZIhvcNAQkEMRYEFLDR5BAYYM+v7k5UYm5s39Ft0AFSMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB5ty54biHv956IDm/LTLx24rDbfT0+vzmirei2jX+LaoJHfYwE5LTBZ5r6r1gjz/hGztCO QqjJWtnH8KQK52i5SDtSDq1VgvDKuGJSTmyRQbGgceuOuFqi4cvFr5P7JpYTEV2gHYJ5PJWF5rBC zJcMbssVxUx5re7rFq34XBK0L74B70dRr8M59XAXPZxBKiNfFpD0K3/7cOKhVs0G3u83F6HO9Fo3 mmfMAbkSSbbH7CUx2+LxzkCIMUGu98eeEMqsDbWp2Rq5ZyptMhHAqC0tWxmB+KEUYK5+OyQi6DYz uF6wzK9QaWNN8bqC32O7t1Z9lr10a7XT352O5RmVXyMGAAAAAAAA --Apple-Mail-87--910363657-- From gregory.ietf@gmail.com Wed Mar 24 11:35:32 2010 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 9FD193A68C4 for ; Wed, 24 Mar 2010 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.089 X-Spam-Level: X-Spam-Status: No, score=-100.089 tagged_above=-999 required=5 tests=[AWL=1.379, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 xwfK5HtScgpe for ; Wed, 24 Mar 2010 11:35:31 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id 88EB53A67F3 for ; Wed, 24 Mar 2010 11:35:31 -0700 (PDT) Received: by iwn35 with SMTP id 35so5007138iwn.31 for ; Wed, 24 Mar 2010 11:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dvAkAbKDkcD4D5fdK8igpcEsPCgvsEAA4VXK6o4eu2g=; b=aSz8Zt7Pfy8nAyHAMHM0uLad/NEH7XGKDs48EVshI0psawmjtzjhxEfZFqxfLMDYR7 j+Cfug7+cI8e8p32jyNJYhNfdgb59QTmUgiU/xHJGCpa1/uWPO0qYY4Rca8/txdW9LX3 03FFGCX/UJ1KVsIxkGK5xAJg5BX347CD4PZx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fb1V6B3piDLKQ+AENR/a9grys3ukYb9HD3rcjxCq8XCPxjXH/2KgzZUziSjpkLAhzP BGgJvbIg7Zm9Hj9yFa6EB/MC/TfdJ8zAa/uhtb+4JDsqYNxOficCECxk8N6CVZyZ8gZQ D43hbN+LvAodUSNNrwrfFPTrK+cfh6GrmwErI= MIME-Version: 1.0 Received: by 10.231.145.204 with SMTP id e12mr2745544ibv.36.1269455749134; Wed, 24 Mar 2010 11:35:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Mar 2010 11:35:48 -0700 Message-ID: From: Gregory Lebovitz To: michelle.cotton@icann.org Content-Type: multipart/alternative; boundary=001485e9acdcfc4fe904829032a0 Cc: tcpm-chairs@tools.ietf.org, ekr@rtfm.com, tcpm@ietf.org, iana@iana.org Subject: Re: [tcpm] tcp-ao-crypto-03, IANA registry location question 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, 24 Mar 2010 18:35:32 -0000 --001485e9acdcfc4fe904829032a0 Content-Type: text/plain; charset=ISO-8859-1 Michelle, After discussion with Lars, and with Magnus input, we believe (1) add "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" registry is best. IESG review has already completed. Do we want to edit IANA section to reflect this in Auth48, or how did you want to handle getting the text chagned? pls advise, Gregory On Wed, Mar 24, 2010 at 10:49 AM, Gregory Lebovitz wrote: > Draft-03 has now published addressing all issues. > > Michelle (IANA team) had a good question: > > Should the registry for this, "Cryptographic Algorithms for TCP-AO", be > stand alone or should it sit under the current "tcp-parameters" > registration? FYI, the other things in that "tcp-parameters" registry today > are only two: > TCP Option Kind Numbers, and > TCP Alternate Checksum Numbers > > The specific question IANA will need answered: > Do we want to > (1) add "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" > registry > or > (2) Create "Cryptographic Algorithims for TCP-AO" as a stand-alone registry > > Magnus happened to walk by while I was at IANA table with Michelle, and we > both thought (1) above was best. Chairs? Lars? > > Michelle advises that IESG can clear the document, and we can address this > in Auth48. > > Gregory > > On Wed, Mar 24, 2010 at 10:37 AM, IETF I-D Submission Tool < > idsubmission@ietf.org> wrote: > >> >> A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-03.txt has been >> successfully submitted by Gregory Lebovitz and posted to the IETF >> repository. >> >> Filename: draft-ietf-tcpm-tcp-ao-crypto >> Revision: 03 >> Title: Cryptographic Algorithms for TCP's Authentication Option, >> TCP-AO >> Creation_date: 2010-03-24 >> WG ID: tcpm >> Number_of_pages: 16 >> >> Abstract: >> The TCP Authentication Option, TCP-AO, relies on security algorithms >> to provide authentication between two end-points. There are many >> such algorithms available, and two TCP-AO systems cannot interoperate >> unless they are using the same algorithms. This document specifies >> the algorithms and attributes that can be used in TCP-AO's current >> manual keying mechanism, and provides the interface for future MACs. >> >> >> >> The IETF Secretariat. >> >> >> > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks > -- ---- IETF related email from Gregory M. Lebovitz Juniper Networks --001485e9acdcfc4fe904829032a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Michelle,
After discussion with Lars, and with Magnus input, we believe= =A0(1) add "Cryptographic Algorithms for TCP-AO" =A0as a "tc= p-parameter" registry is best.

IESG review ha= s already completed.

Do we want to edit IANA section to reflect this in Auth= 48, or how did you want to handle getting the text chagned?

<= /div>
pls advise,
Gregory

On Wed, Mar 24, 2010 at 10:49 AM, Gregory Lebovitz <gregory.ietf@gmail.com> wrote:
Draft-03 has now published addressing all issues.

=
Michelle (IANA team) had a good question:

Sho= uld the registry for this, "Cryptographic Algorithms for TCP-AO",= be stand alone or should it sit under the current=A0"tcp-parameters&q= uot; registration? FYI, the other things in that "tcp-parameters"= registry today are only two: =A0
=A0=A0TCP Option Kind Numbers, and=A0
=A0=A0TCP Alternate Ch= ecksum Numbers

The specific question IANA will nee= d answered:
Do we want to
(1) add "Cryptographic A= lgorithms for TCP-AO" =A0as a "tcp-parameter" registry
or
(2) Create "Cryptographic Algorithims for TCP-AO&quo= t; as a stand-alone registry

Magnus happened to wa= lk by while I was at IANA table with Michelle, and we both thought (1) abov= e was best. Chairs? Lars?

Michelle advises that IESG can clear the document, and = we can address this in Auth48.

Gregory

On Wed, Mar 24, 2010 at 10:37 AM, IETF I-D Submiss= ion Tool <idsubmission@ietf.org> wrote:

A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-03.txt has been success= fully submitted by Gregory Lebovitz and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-tcpm-tcp-ao-crypto
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 Cryptographic Algorithms for TCP's Authentic= ation Option, TCP-AO
Creation_date: =A0 2010-03-24
WG ID: =A0 =A0 =A0 =A0 =A0 tcpm
Number_of_pages: 16

Abstract:
The TCP Authentication Option, TCP-AO, relies on security algorithms
to provide authentication between two end-points. =A0There are many
such algorithms available, and two TCP-AO systems cannot interoperate
unless they are using the same algorithms. =A0This document specifies
the algorithms and attributes that can be used in TCP-AO's current
manual keying mechanism, and provides the interface for future MACs.



The IETF Secretariat.





--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks



--
----
IETF related em= ail from
Gregory M. Lebovitz
Juniper Networks
--001485e9acdcfc4fe904829032a0-- From mallman@icir.org Wed Mar 24 12:22:29 2010 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 6774C3A68CC for ; Wed, 24 Mar 2010 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.633 X-Spam-Level: X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Wu-8DIvC-eVN for ; Wed, 24 Mar 2010 12:22:26 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 7F2B83A6A7A for ; Wed, 24 Mar 2010 12:22:21 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2OJMaRI017347; Wed, 24 Mar 2010 12:22:36 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2D025BCAEF0; Wed, 24 Mar 2010 15:22:36 -0400 (EDT) To: Fernando Gont From: Mark Allman In-Reply-To: <4BAA3C2F.8090008@gont.com.ar> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Whole Lotta Love MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma26236-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Mar 2010 15:22:36 -0400 Sender: mallman@icir.org Message-Id: <20100324192236.2D025BCAEF0@lawyers.icir.org> Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 19:22:29 -0000 ----------ma26236-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It seems to me we (Joe, you and I) have converged to viewing the TIME_WAIT truncation business as worth a work item, but the need or desire for unpredictable timestamps seems to not be worthwhile. Truncation requires monotonically increasing timestamps across connections to be somehow ensured. Seemingly that is such a mundane requirement that we don't have to wade into the particulars of it in this document. Is this summary reasonable? And, if so, is that OK with everyone else? allman ----------ma26236-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEUEARECAAYFAkuqZnwACgkQWyrrWs4yIs4VRACeOiqOdbAho+kPx2Q80rzmeRX4 D9UAliUPqTf7CPinCsO/gzIsV/+Zn6Q= =xnKf -----END PGP SIGNATURE----- ----------ma26236-1-- From touch@ISI.EDU Wed Mar 24 12:59:12 2010 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 F21403A6BAF for ; Wed, 24 Mar 2010 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 NfaFIETiM2kx for ; Wed, 24 Mar 2010 12:59:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 41C793A6BAB for ; Wed, 24 Mar 2010 12:59:12 -0700 (PDT) Received: from [130.129.28.166] (dhcp-wireless-open-abg-28-166.meeting.ietf.org [130.129.28.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2OJwWKK003683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Mar 2010 12:58:34 -0700 (PDT) Message-ID: <4BAA6EE8.5050309@isi.edu> Date: Wed, 24 Mar 2010 12:58:32 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100324192236.2D025BCAEF0@lawyers.icir.org> In-Reply-To: <20100324192236.2D025BCAEF0@lawyers.icir.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig82E5F9B6833E1430F87BCFEC" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 24 Mar 2010 19:59:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig82E5F9B6833E1430F87BCFEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Allman wrote: > It seems to me we (Joe, you and I) have converged to viewing the > TIME_WAIT truncation business as worth a work item, but the need or > desire for unpredictable timestamps seems to not be worthwhile. > Truncation requires monotonically increasing timestamps across > connections to be somehow ensured. Seemingly that is such a mundane > requirement that we don't have to wade into the particulars of it in > this document. Is this summary reasonable?=20 I think so. Joe > And, if so, is that OK with > everyone else? >=20 > allman >=20 >=20 >=20 --------------enig82E5F9B6833E1430F87BCFEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuqbugACgkQE5f5cImnZrsBVgCcDlRhf9R4fsZPxaVdFKKQCHQt dtEAn2ytf+vvuWLWgNizM3FQxdx4muWw =y/bG -----END PGP SIGNATURE----- --------------enig82E5F9B6833E1430F87BCFEC-- From wwwrun@core3.amsl.com Wed Mar 24 13:28:20 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 35BD73A6D1B; Wed, 24 Mar 2010 13:28:19 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100324202820.35BD73A6D1B@core3.amsl.com> Date: Wed, 24 Mar 2010 13:28:20 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO' to Proposed Standard 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, 24 Mar 2010 20:28:20 -0000 The IESG has approved the following document: - 'Cryptographic Algorithms for TCP's Authentication Option, TCP-AO ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-ao-crypto-03.txt Technical Summary The TCP Authentication Option, TCP-AO, relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism. Document Quality Vendors have expressed support for this work and begun implementing it and sharing feedback with TCPM. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. RFC Editor Note Deficiencies in xml2rfc cause an invalid table-of-contents to be generated. As discussed during IETF-77, please manually recreate the table-of-contents. From Alexander.Zimmermann@nets.rwth-aachen.de Wed Mar 24 18:28:01 2010 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 572AC3A680D for ; Wed, 24 Mar 2010 18:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 DpWjiThn+VU3 for ; Wed, 24 Mar 2010 18:28:00 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 6E7C83A67D4 for ; Wed, 24 Mar 2010 18:28:00 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id C0E89578E8; Thu, 25 Mar 2010 02:28:20 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Thu, 25 Mar 2010 02:28:09 +0100 From: Alexander Zimmermann To: "william.allen.simpson@gmail.com" Thread-Topic: draft-simpson-tcpct-00 in RFC Editor queue Thread-Index: AQHKy7pt9uZdN5RqWUyA7OUJZv4t/g== Date: Thu, 25 Mar 2010 01:28:18 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6f0e4bb8-802c-4157-8fe4-83466bcba3b8> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions WG" Subject: [tcpm] draft-simpson-tcpct-00 in RFC Editor queue 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, 25 Mar 2010 01:28:01 -0000 Hi William, do you not think that it's probably a better way to discuss your draft (http://www.rfc-editor.org/internet-drafts/draft-simpson-tcpct-00.txt) on TCPM first *before* submitting it to the RFC Editor? Alex =20 From iana-shared@icann.org Wed Mar 24 13:02:31 2010 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 181853A6C81 for ; Wed, 24 Mar 2010 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.177 X-Spam-Level: X-Spam-Status: No, score=-8.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] 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 S0RwHjG0VD+p for ; Wed, 24 Mar 2010 13:02:29 -0700 (PDT) Received: from request.lax.icann.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id DFA513A6CFB for ; Wed, 24 Mar 2010 13:02:29 -0700 (PDT) Received: from request.lax.icann.org (localhost.localdomain [127.0.0.1]) by request.lax.icann.org (8.13.8/8.13.8) with ESMTP id o2OK1nPK032571; Wed, 24 Mar 2010 13:01:49 -0700 Received: (from apache@localhost) by request.lax.icann.org (8.13.8/8.13.8/Submit) id o2OK1n9o032570; Wed, 24 Mar 2010 13:01:49 -0700 From: "Michelle Cotton via RT" In-Reply-To: References: Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #309212 Managed-by: RT 3.8.3pre1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Wed, 24 Mar 2010 20:01:49 +0000 X-Mailman-Approved-At: Wed, 24 Mar 2010 19:08:07 -0700 Cc: tcpm-chairs@tools.ietf.org, ekr@rtfm.com, tcpm@ietf.org Subject: [tcpm] [IANA #309212] tcp-ao-crypto-03, IANA registry location question X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-questions@iana.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, 24 Mar 2010 20:02:31 -0000 Gregory, I don't think any text changes are needed. We'll make a note that the registry should be placed in tcp- parameters. Thanks, Michelle On Wed Mar 24 18:36:14 2010, gregory.ietf@gmail.com wrote: > Michelle, > After discussion with Lars, and with Magnus input, we believe (1) add > "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" registry > is > best. > > IESG review has already completed. > > Do we want to edit IANA section to reflect this in Auth48, or how did > you > want to handle getting the text chagned? > > pls advise, > Gregory > > On Wed, Mar 24, 2010 at 10:49 AM, Gregory Lebovitz > wrote: > > > Draft-03 has now published addressing all issues. > > > > Michelle (IANA team) had a good question: > > > > Should the registry for this, "Cryptographic Algorithms for TCP-AO", > be > > stand alone or should it sit under the current "tcp-parameters" > > registration? FYI, the other things in that "tcp-parameters" > registry today > > are only two: > > TCP Option Kind Numbers, and > > TCP Alternate Checksum Numbers > > > > The specific question IANA will need answered: > > Do we want to > > (1) add "Cryptographic Algorithms for TCP-AO" as a "tcp-parameter" > > registry > > or > > (2) Create "Cryptographic Algorithims for TCP-AO" as a stand-alone > registry > > > > Magnus happened to walk by while I was at IANA table with Michelle, > and we > > both thought (1) above was best. Chairs? Lars? > > > > Michelle advises that IESG can clear the document, and we can > address this > > in Auth48. > > > > Gregory > > > > On Wed, Mar 24, 2010 at 10:37 AM, IETF I-D Submission Tool < > > idsubmission@ietf.org> wrote: > > > >> > >> A new version of I-D, draft-ietf-tcpm-tcp-ao-crypto-03.txt has been > >> successfully submitted by Gregory Lebovitz and posted to the IETF > >> repository. > >> > >> Filename: draft-ietf-tcpm-tcp-ao-crypto > >> Revision: 03 > >> Title: Cryptographic Algorithms for TCP's Authentication > Option, > >> TCP-AO > >> Creation_date: 2010-03-24 > >> WG ID: tcpm > >> Number_of_pages: 16 > >> > >> Abstract: > >> The TCP Authentication Option, TCP-AO, relies on security > algorithms > >> to provide authentication between two end-points. There are many > >> such algorithms available, and two TCP-AO systems cannot > interoperate > >> unless they are using the same algorithms. This document specifies > >> the algorithms and attributes that can be used in TCP-AO's current > >> manual keying mechanism, and provides the interface for future > MACs. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> > > > > > > -- > > ---- > > IETF related email from > > Gregory M. Lebovitz > > Juniper Networks > > > > > From william.allen.simpson@gmail.com Wed Mar 24 19:15:44 2010 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 6BF913A67E7 for ; Wed, 24 Mar 2010 19:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 KVPPSliE2Mbk for ; Wed, 24 Mar 2010 19:15:42 -0700 (PDT) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by core3.amsl.com (Postfix) with ESMTP id 7D9403A6BD6 for ; Wed, 24 Mar 2010 19:15:36 -0700 (PDT) Received: by gxk9 with SMTP id 9so1876753gxk.8 for ; Wed, 24 Mar 2010 19:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iRhcOUbPyFqQBJSGAQdtLa2tkt/KG1M4TswmXf2X2HA=; b=JgvRd1KVP7W5M358VkyBGEccAc9OH3EoymbEwCGL1g202/jRHV9dwGls2K2ToJVjZw 0afvEoHHbGuYIzZqVqxMFuWBNQbpXgNX5RKaf3K+axgFm7yVZOwwxH3D7UC/IAFjPjlz peoI0f7j0WrG2EC7yi3UonRCg+JP8I0fMkJpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FK7gCUjaAU1CmHgzRJW43OhzGrYBkqlrfvJueHGvOItAU6l76qgUfTUsrfUKJ74rPI tx1P8BTA19jOXb1K7G9skZkBbe+OFsZqgOK9MFR+tJWrZ1/P/mfMBXMEcTGLON9nc0pS PnrCZowunfrBic2jP0vctj2htMmXYqbxNcfBQ= Received: by 10.101.202.34 with SMTP id e34mr8764704anq.107.1269483354891; Wed, 24 Mar 2010 19:15:54 -0700 (PDT) Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 21sm537872iwn.3.2010.03.24.19.15.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Mar 2010 19:15:53 -0700 (PDT) Message-ID: <4BAAC758.1050908@gmail.com> Date: Wed, 24 Mar 2010 22:15:52 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Alexander Zimmermann References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions WG" Subject: Re: [tcpm] draft-simpson-tcpct-00 in RFC Editor queue 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, 25 Mar 2010 02:15:44 -0000 On 3/24/10 9:28 PM, Alexander Zimmermann wrote: > do you not think that it's probably a better way to discuss your draft > (http://www.rfc-editor.org/internet-drafts/draft-simpson-tcpct-00.txt) > on TCPM first *before* submitting it to the RFC Editor? > No, thank you. This is not a Standards Track document. It has already had ample discussion among implementers during the past 6 months. If folks find errors, please send them to me directly. Although I have a local archive of the TCPM list, I don't review it regularly. Thanks for your interest. From Alexander.Zimmermann@nets.rwth-aachen.de Thu Mar 25 10:08:18 2010 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 834343A6DF7 for ; Thu, 25 Mar 2010 10:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 tOIyy-w2wgWm for ; Thu, 25 Mar 2010 10:08:13 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 9F0833A6B8F for ; Thu, 25 Mar 2010 10:08:06 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id CD0FB578B1; Thu, 25 Mar 2010 18:08:27 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Thu, 25 Mar 2010 18:08:16 +0100 From: Alexander Zimmermann To: William Allen Simpson Thread-Topic: draft-simpson-tcpct-00 in RFC Editor queue Thread-Index: AQHKy7pt9uZdN5RqWUyA7OUJZv4t/pIB2fYAgAD5XoA= Date: Thu, 25 Mar 2010 17:08:23 +0000 Message-ID: References: <4BAAC758.1050908@gmail.com> In-Reply-To: <4BAAC758.1050908@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <73582e0b-a227-47df-a1fc-3992ca575bd1> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions WG" Subject: Re: [tcpm] draft-simpson-tcpct-00 in RFC Editor queue 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, 25 Mar 2010 17:08:18 -0000 Am 24.03.2010 um 19:15 schrieb William Allen Simpson: > On 3/24/10 9:28 PM, Alexander Zimmermann wrote: >> do you not think that it's probably a better way to discuss your draft >> (http://www.rfc-editor.org/internet-drafts/draft-simpson-tcpct-00.txt) >> on TCPM first *before* submitting it to the RFC Editor? >>=20 > No, thank you. This is not a Standards Track document. It doesn't matter... We discuss/standardize also experimental stuff > It has already > had ample discussion among implementers during the past 6 months. I know. I am LKML aware, however LKML !=3D IETF (TCPM) >=20 > If folks find errors, please send them to me directly. Although I have a > local archive of the TCPM list, I don't review it regularly. >=20 > Thanks for your interest. Alex From david.borman@windriver.com Thu Mar 25 15:58:41 2010 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 8ACD43A6CC1 for ; Thu, 25 Mar 2010 15:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 MFcGQKOpnVQC for ; Thu, 25 Mar 2010 15:58:40 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 425AB3A67FA for ; Thu, 25 Mar 2010 15:58:39 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o2PMx1lW016839 for ; Thu, 25 Mar 2010 15:59:01 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Mar 2010 15:59:01 -0700 Received: from unknown-233-69.windriver.com ([147.11.233.69]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Mar 2010 15:59:00 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: David Borman In-Reply-To: Date: Thu, 25 Mar 2010 15:59:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "tcpm@ietf.org WG" X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 25 Mar 2010 22:59:00.0657 (UTC) FILETIME=[C1FD9210:01CACC6E] 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, 25 Mar 2010 22:58:41 -0000 On Aug 18, 2009, at 10:38 AM, 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've finally finished updating the MSS document, and have uploaded it. http://tools.ietf.org/html/draft-ietf-tcpm-tcpmss-03 I believe I have addressed all the comments received during the Last = Call, and have done some additional changes beyond that. I've been = discussing the document this week at the IETF with several people, and = the results of those conversations are included in this new draft. Because of the time lapse, and the number of changes that I've made to = the document, let's extend the WGLC to Thursday, April 8. Below are my responses to all the comments received during the original = WGLC. -David Borman On Aug 20, 2009, at 7:50 AM, Alexander Zimmermann wrote: > 1. Needs boilerplate update (Copyright section) Done. > 2. IMHO in line 50: %s/to do about TCP options/to do about IP and TCP = options/ Done. > 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. I've removed "in section 4.2.2.6", and replaced it with a reference to a = new Appendix A that has a more complete description of what is in RFC 1122. >=20 > Alex On Aug 20, 2009, at 11:28 AM, Joe Touch wrote: .... > I'd like to suggest the following for this doc: >=20 > 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): >=20 > - --- >=20 > 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. >=20 > As a result, when effective MSS varies, TCP SHOULD compute its > advertised MSS based on the smallest effective MSS. >=20 > - --- >=20 > Joe Added, with some rewording. On Aug 20, 2009, at 12:59 PM, = wrote: > 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. >=20 > >=20 Ok, this one I've gone round and round on this, including adding an = entire Appendix to discuss issues of which MTU value to use for = calculating the MSS, the history of this, issues with multi-homed hosts, = non-symetric routes, and making multiple recommendations, based on the = context. In the end it felt like it was getting out of control, as one = thing lead to another and the Appendix was getting quite large. In the = end, I deleted the Appendix, and now have just one sentence: The determination of what MTU value should be used, especially in the case of multihomed hosts, is beyond the scope = of this document. This document is about clarifying that you don't include IP and TCP = options when figuring out what to put in the MSS option, it is not about = what MTU value to use when calculating the MSS option, so it is best to = just not go down that path at all. That's not to say that this isn't a = topic that deserves discussion, but that it isn't the purpose of this = document. On Aug 26, 2009, at 6:56 AM, Mark Allman wrote: > 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. =20 >=20 > The statement that the MSS advertisement should not include the bytes > consumed by options is clear, but in the explanation of that rule. >=20 > + I had to work through the table to figure out "length" on the = y-axis > was the overall packet length. Fixed. > + 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. >=20 > + 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"). I've added a paragraph that says that the MSS value, being fixed, can = never accurately reflect all situations of IP and TCP options, because = by their very nature they are variable. On Sep 3, 2009, at 7:37 AM, Danny McPherson wrote: >=20 > I agree with Marks's comments - in general I like the document > (my colleague Aaron Campbell and I asked for and offered to write) > something similar quite a while back). >=20 > It is worth noting that the confusion isn't universal, at least, the > Linux, NetBSD, and OpenBSD people got it right (options are not > subtracted from the advertised MSS on these systems from our past > research). >=20 > RFC2385 is wrong, though: ... I've added a reference to this issue, and pointed out that RFC 2385 is = wrong. I've also added a reference to the issue with RFC-897, which = mostly got the definition correct until the very last section of the = document... :-) -David= From root@core3.amsl.com Thu Mar 25 16:00:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A25643A67E4; Thu, 25 Mar 2010 16:00: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: <20100325230001.A25643A67E4@core3.amsl.com> Date: Thu, 25 Mar 2010 16:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpmss-03.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: Thu, 25 Mar 2010 23:00: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 : This memo discusses what value to use with the TCP MSS option. Author(s) : D. Borman Filename : draft-ietf-tcpm-tcpmss-03.txt Pages : 9 Date : 2010-03-25 This memo discusses what value to use with the TCP MSS option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpmss-03.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-tcpmss-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-25155802.I-D@ietf.org> --NextPart-- From david.borman@windriver.com Thu Mar 25 19:11:47 2010 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 E89983A6934 for ; Thu, 25 Mar 2010 19:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 y3Z-i1fU8Bp9 for ; Thu, 25 Mar 2010 19:11:46 -0700 (PDT) Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id F25C73A67F8 for ; Thu, 25 Mar 2010 19:11:45 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id o2Q2C85D012830 for ; Thu, 25 Mar 2010 19:12:08 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Mar 2010 19:12:08 -0700 Received: from unknown-233-68.windriver.com ([147.11.233.68]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Mar 2010 19:12:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: David Borman In-Reply-To: <20100325230001.A25643A67E4@core3.amsl.com> Date: Thu, 25 Mar 2010 19:12:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100325230001.A25643A67E4@core3.amsl.com> To: "tcpm@ietf.org WG" X-Mailer: Apple Mail (2.1077) X-OriginalArrivalTime: 26 Mar 2010 02:12:08.0041 (UTC) FILETIME=[BC9C0D90:01CACC89] Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcpmss-03.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: Fri, 26 Mar 2010 02:11:47 -0000 Hmm... the actual title is "TCP Options and MSS". I suppose I had a = chance to fix the meta-data during the check-in process and just missed = it. -David On Mar 25, 2010, at 4:00 PM, Internet-Drafts@ietf.org wrote: > 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. >=20 >=20 > Title : This memo discusses what value to use with the = TCP MSS option. > Author(s) : D. Borman > Filename : draft-ietf-tcpm-tcpmss-03.txt > Pages : 9 > Date : 2010-03-25 >=20 > This memo discusses what value to use with the TCP MSS option. From Manqing.Huang@exar.com Fri Mar 26 11:20:51 2010 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 340D03A6C15 for ; Fri, 26 Mar 2010 11:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 AH4CGd699sPR for ; Fri, 26 Mar 2010 11:20:50 -0700 (PDT) Received: from smtp1.exar.com (webmail.exar.com [204.154.183.83]) by core3.amsl.com (Postfix) with ESMTP id BDF3B3A6A8D for ; Fri, 26 Mar 2010 11:20:37 -0700 (PDT) Received: from FRE1EXCH02.hq.exar.com ([fe80::e9a7:6160:4e13:1677]) by fre1-cas ([10.127.1.162]) with mapi; Wed, 24 Mar 2010 12:46:04 -0700 From: Manqing Huang To: "tcpm@ietf.org" Date: Wed, 24 Mar 2010 12:45:47 -0700 Thread-Topic: Introduing draft-huang-tcpm-tcp-eack-00 Thread-Index: AcrLiOoNMiJPN9TASRSs5257LzjRQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FCA91A92EE52B041906A0358FC28FCC38EED5246E7FRE1EXCH02hqe_" MIME-Version: 1.0 Cc: "weddy@grc.nasa.gov" Subject: [tcpm] Introduing draft-huang-tcpm-tcp-eack-00 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, 26 Mar 2010 18:20:51 -0000 --_000_FCA91A92EE52B041906A0358FC28FCC38EED5246E7FRE1EXCH02hqe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The p= urpose of the option proposed in this draft is to improve TCP performance b= y reducing the amount of separate ACK packets when there are multiple TCP c= onnections and each of the connections carries one way traffic. Application= s that can benefit from this option include HTTP and FTP. Comments are appreciated. Thank you. Manqing Huang ________________________________ The information and any attached documents contained in this message may be confidential and/or legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender immediately by return e-mail and destroy all copies of the original message. --_000_FCA91A92EE52B041906A0358FC28FCC38EED5246E7FRE1EXCH02hqe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hel= lo,
 
I w= ould like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The purp= ose of the option proposed in this draft is to improve = TCP performance by reducing the amount of separate ACK packets when there are multiple TCP connections and each of the connecti= ons carries one way traffic. Applications that can benefit from t= his option include HTTP and FTP.
 
Com= ments are appreciated.
 
Tha= nk you.
 
Man= qing Huang
 

The information and any atta= ched documents contained in this message
may be confidential and/or legally privileged. The message is
intended solely for the addressee(s). If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.
 --_000_FCA91A92EE52B041906A0358FC28FCC38EED5246E7FRE1EXCH02hqe_-- From Manqing.Huang@exar.com Fri Mar 26 11:21:42 2010 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 CE2593A68C3 for ; Fri, 26 Mar 2010 11:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 h9L2ngR1yOgM for ; Fri, 26 Mar 2010 11:21:41 -0700 (PDT) Received: from smtp1.exar.com (webmail.exar.com [204.154.183.83]) by core3.amsl.com (Postfix) with ESMTP id A32AA3A6B36 for ; Fri, 26 Mar 2010 11:21:17 -0700 (PDT) Received: from FRE1EXCH02.hq.exar.com ([fe80::e9a7:6160:4e13:1677]) by fre1-cas ([10.127.1.162]) with mapi; Fri, 26 Mar 2010 10:48:15 -0700 From: Manqing Huang To: "tcpm@ietf.org" Date: Fri, 26 Mar 2010 10:48:13 -0700 Thread-Topic: Introducing draft-huang-tcpm-tcp-eack-00 Thread-Index: AcrNDIIPyDp+kfoZRTOYRtFt8NT/gA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FCA91A92EE52B041906A0358FC28FCC38EED595E83FRE1EXCH02hqe_" MIME-Version: 1.0 Subject: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 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, 26 Mar 2010 18:21:42 -0000 --_000_FCA91A92EE52B041906A0358FC28FCC38EED595E83FRE1EXCH02hqe_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The p= urpose of the TCP option proposed in this draft is to improve TCP performan= ce by reducing the amount of separate ACK packets when there are multiple T= CP connections and each of the connections carries one way traffic. Applica= tions that can benefit from this option include HTTP and FTP. Comments are appreciated. Thank you. Manqing Huang ________________________________ The information and any attached documents contained in this message may be confidential and/or legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender immediately by return e-mail and destroy all copies of the original message. --_000_FCA91A92EE52B041906A0358FC28FCC38EED595E83FRE1EXCH02hqe_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hel= lo,
 
I w= ould like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The purp= ose of the TCP option proposed in this draft is to improve TCP perfo= rmance by reducing the amount of separate ACK packets when there are&n= bsp;multiple TCP connections and each of the connections carries = one way traffic. Applications that can benefit from this option includ= e HTTP and FTP.
 
Com= ments are appreciated.
 
Tha= nk you.
 
Man= qing Huang
 

The information and any atta= ched documents contained in this message
may be confidential and/or legally privileged. The message is
intended solely for the addressee(s). If you are not the intended
recipient, you are hereby notified that any use, dissemination, or
reproduction is strictly prohibited and may be unlawful. If you are
not the intended recipient, please contact the sender immediately by
return e-mail and destroy all copies of the original message.
 --_000_FCA91A92EE52B041906A0358FC28FCC38EED595E83FRE1EXCH02hqe_-- From fernando@gont.com.ar Fri Mar 26 11:53:33 2010 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 D8BC23A6A04 for ; Fri, 26 Mar 2010 11:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_LOW=-1, SARE_WEOFFER=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 TJWuT1uF1wpT for ; Fri, 26 Mar 2010 11:53:33 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A1EF73A6901 for ; Fri, 26 Mar 2010 11:53:31 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 09B3B6B6B10; Fri, 26 Mar 2010 15:53:57 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2QIrnI8004597; Fri, 26 Mar 2010 15:53:51 -0300 Message-ID: <4BAD02BD.6070907@gont.com.ar> Date: Fri, 26 Mar 2010 15:53:49 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100324192236.2D025BCAEF0@lawyers.icir.org> In-Reply-To: <20100324192236.2D025BCAEF0@lawyers.icir.org> X-Enigmail-Version: 0.96.0 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, 26 Mar 2010 15:53:56 -0300 (ART) Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 26 Mar 2010 18:53:33 -0000 Hi, Mark, > It seems to me we (Joe, you and I) have converged to viewing the > TIME_WAIT truncation business as worth a work item, but the need or > desire for unpredictable timestamps seems to not be worthwhile. > Truncation requires monotonically increasing timestamps across > connections to be somehow ensured. Seemingly that is such a mundane > requirement that we don't have to wade into the particulars of it in > this document. Is this summary reasonable? And, if so, is that OK > with everyone else? As a result of our discussion, I think a possible way forward would be for the doc to just require monotonically-increasing timestamps across connections, and TIME_WAIT truncation (with RFC2119-language). However, I think that an appendix (with no normative language) that describes a few possible algorithms to achieve monotonically-increasing timestamps might still be helpful/useful. One might include in that appendix the trivial "global timestamps clock" (with randomized initial value at system boot time) and the RFC1948-like scheme. My rationale is that if we're requiring monotonically-increasing timestamps, it would be helpful to at least mention possible approaches (without any requirements or specific choice). Some stacks already randomize timestamps (trivially....with random() )(e.g., OpenBSD). And my take is that unless we offer them an algorithm that generates unpredictable timestamps, they might not want to use the predictable "global timestamp clock" approach. -- and I think it would be best if everybody jumped into the "monotonically-increasing timestamps" wagon, no matter whether they are predictable or not. This is just me thinking out loud. -- If there's contention on the timestamps generation thing, I have no problem with splitting the I-D, and striping off the "timestamps generation algorithms" from the current I-D. Thoughts? 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 Fri Mar 26 12:41:03 2010 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 AE0023A6BDE for ; Fri, 26 Mar 2010 12:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=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 vaOUG8iKOOsG for ; Fri, 26 Mar 2010 12:41:02 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 1A6A93A6B68 for ; Fri, 26 Mar 2010 12:41:02 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 0F40B578DD; Fri, 26 Mar 2010 20:41:24 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Fri, 26 Mar 2010 20:41:11 +0100 From: Alexander Zimmermann To: Fernando Gont Thread-Topic: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: AQHKyqKSQdRELq6pUkCK5hfW014bKZH/0YGAgAAHXwCAAAM6gIAAfl+AgAAPoACAAJY7AIAANe6AgAAybQCAAxyfgIAADUqA Date: Fri, 26 Mar 2010 19:41:23 +0000 Message-ID: <26220A98-6987-4B2F-9C1C-262A2D1C4DE0@nets.rwth-aachen.de> References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> In-Reply-To: <4BAD02BD.6070907@gont.com.ar> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <10d2aa9a-f816-4c57-819d-2832b9e1b395> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Joe Touch , "tcpm@ietf.org" , "" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 26 Mar 2010 19:41:03 -0000 Hi Fernando, first of all, I didn't read your draft, so please apologizes my maybe stupid remark. I guess your algo. is not compatible with the timestamp generation in RFC 4987 (3.6. SYN Cookies). Right? Should we mention that? Alex Am 26.03.2010 um 11:53 schrieb Fernando Gont: > Hi, Mark, >=20 >> It seems to me we (Joe, you and I) have converged to viewing the=20 >> TIME_WAIT truncation business as worth a work item, but the need or=20 >> desire for unpredictable timestamps seems to not be worthwhile.=20 >> Truncation requires monotonically increasing timestamps across=20 >> connections to be somehow ensured. Seemingly that is such a mundane >> requirement that we don't have to wade into the particulars of it in >> this document. Is this summary reasonable? And, if so, is that OK=20 >> with everyone else? >=20 > As a result of our discussion, I think a possible way forward would be > for the doc to just require monotonically-increasing timestamps across > connections, and TIME_WAIT truncation (with RFC2119-language). >=20 > However, I think that an appendix (with no normative language) that > describes a few possible algorithms to achieve monotonically-increasing > timestamps might still be helpful/useful. >=20 > One might include in that appendix the trivial "global timestamps clock" > (with randomized initial value at system boot time) and the RFC1948-like > scheme. My rationale is that if we're requiring monotonically-increasing > timestamps, it would be helpful to at least mention possible approaches > (without any requirements or specific choice). >=20 > Some stacks already randomize timestamps (trivially....with random() > )(e.g., OpenBSD). And my take is that unless we offer them an algorithm > that generates unpredictable timestamps, they might not want to use the > predictable "global timestamp clock" approach. -- and I think it would > be best if everybody jumped into the "monotonically-increasing > timestamps" wagon, no matter whether they are predictable or not. >=20 > This is just me thinking out loud. -- If there's contention on the > timestamps generation thing, I have no problem with splitting the I-D, > and striping off the "timestamps generation algorithms" from the current > I-D. >=20 > Thoughts? >=20 > Thanks! >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From Alexander.Zimmermann@nets.rwth-aachen.de Fri Mar 26 12:48:40 2010 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 107D93A6C37 for ; Fri, 26 Mar 2010 12:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 o0ESZqe88e8P for ; Fri, 26 Mar 2010 12:48:39 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id CD4E43A6C06 for ; Fri, 26 Mar 2010 12:48:36 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 573FD579C3; Fri, 26 Mar 2010 20:49:00 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Fri, 26 Mar 2010 20:48:47 +0100 From: Alexander Zimmermann To: Manqing Huang Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 Thread-Index: AQHKzR1YCN1w7l2xYUyMH1O2EBvhRw== Date: Fri, 26 Mar 2010 19:48:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <80e64ba5-7ece-4606-98fd-6784280ce594> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 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, 26 Mar 2010 19:48:40 -0000 Hi, I take a quick look at your draft. I really have problems with your applica= tion scenarios. Do you really think that iperf generates congestion in the internet? Also the ftp example is seems quite artificial... Alex Am 26.03.2010 um 10:48 schrieb Manqing Huang: > Hello, > =20 > I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The= purpose of the TCP option proposed in this draft is to improve TCP perform= ance by reducing the amount of separate ACK packets when there are multiple= TCP connections and each of the connections carries one way traffic. Appli= cations that can benefit from this option include HTTP and FTP. > =20 > Comments are appreciated. > =20 > Thank you. > =20 > Manqing Huang > =20 >=20 > The information and any attached documents contained in this message > may be confidential and/or legally privileged. The message is > intended solely for the addressee(s). If you are not the intended > recipient, you are hereby notified that any use, dissemination, or > reproduction is strictly prohibited and may be unlawful. If you are > not the intended recipient, please contact the sender immediately by > return e-mail and destroy all copies of the original message. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From fernando@gont.com.ar Fri Mar 26 13:31:16 2010 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 D1FEF3A6BB9 for ; Fri, 26 Mar 2010 13:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, 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 TEGPk-0xZMQm for ; Fri, 26 Mar 2010 13:31:13 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 36B283A6A11 for ; Fri, 26 Mar 2010 13:31:10 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 839D16B69A0; Fri, 26 Mar 2010 17:31:36 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2QKVRGK027761; Fri, 26 Mar 2010 17:31:30 -0300 Message-ID: <4BAD199E.2060309@gont.com.ar> Date: Fri, 26 Mar 2010 17:31:26 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Alexander Zimmermann References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <26220A98-6987-4B2F-9C1C-262A2D1C4DE0@nets.rwth-aachen.de> In-Reply-To: <26220A98-6987-4B2F-9C1C-262A2D1C4DE0@nets.rwth-aachen.de> X-Enigmail-Version: 0.96.0 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, 26 Mar 2010 17:31:35 -0300 (ART) Cc: "tcpm@ietf.org" , "" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 26 Mar 2010 20:31:16 -0000 Hi, Alexander, > first of all, I didn't read your draft, so please apologizes my > maybe stupid remark. > > I guess your algo. is not compatible with the timestamp generation > in RFC 4987 (3.6. SYN Cookies). Right? Actually, there's an interesting part to it: What matters is that the client-side (i.e., the TCP performing the active open) generates timestamps such that they are monotonically-increasing across connections, as *those* are the timestamps that are used for "recycling" connections that are in the TIME_WAIT state. The timestamp generation implemented by FreeBSD makes sense for the server-side (the side implementing the extended SYN-cookies). Therefore, both approaches can co-exist: i.e., clients could generate timestamps such that they are monotonically-increasing (and thus allow the recycling of connections in the TIME_WAIT state), while servers can generate timestamps with the FreeBSD scheme, such that they allow for extended SYN cookies. Does this make sense? P.S.: Yes, clearly, this would be worth noting... and in particular, could be taken as a motivation for splitting the generation of timestamps into a separate I-D. Thanks so much for your comments! 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 Fri Mar 26 13:52:15 2010 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 AB4E93A6B2B for ; Fri, 26 Mar 2010 13:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 sHEK4Fn2UGez for ; Fri, 26 Mar 2010 13:52:15 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id A46313A6B5E for ; Fri, 26 Mar 2010 13:52:14 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id F33D7578DD; Fri, 26 Mar 2010 21:52:37 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Fri, 26 Mar 2010 21:52:13 +0100 From: Alexander Zimmermann To: Fernando Gont Thread-Topic: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: AQHKyqKSQdRELq6pUkCK5hfW014bKZH/0YGAgAAHXwCAAAM6gIAAfl+AgAAPoACAAJY7AIAANe6AgAAybQCAAxyfgIAADUqAgAAN/ACAAAXqAA== Date: Fri, 26 Mar 2010 20:52:36 +0000 Message-ID: References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <26220A98-6987-4B2F-9C1C-262A2D1C4DE0@nets.rwth-aachen.de> <4BAD199E.2060309@gont.com.ar> In-Reply-To: <4BAD199E.2060309@gont.com.ar> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 26 Mar 2010 20:52:15 -0000 Hi Fernando, thank you for clarification. I've got it. Alex Am 26.03.2010 um 13:31 schrieb Fernando Gont: > Hi, Alexander, >=20 >> first of all, I didn't read your draft, so please apologizes my >> maybe stupid remark. >>=20 >> I guess your algo. is not compatible with the timestamp generation >> in RFC 4987 (3.6. SYN Cookies). Right? >=20 > Actually, there's an interesting part to it: >=20 > What matters is that the client-side (i.e., the TCP performing the > active open) generates timestamps such that they are > monotonically-increasing across connections, as *those* are the > timestamps that are used for "recycling" connections that are in the > TIME_WAIT state. >=20 > The timestamp generation implemented by FreeBSD makes sense for the > server-side (the side implementing the extended SYN-cookies). Therefore, > both approaches can co-exist: i.e., clients could generate timestamps > such that they are monotonically-increasing (and thus allow the > recycling of connections in the TIME_WAIT state), while servers can > generate timestamps with the FreeBSD scheme, such that they allow for > extended SYN cookies. >=20 > Does this make sense? >=20 > P.S.: Yes, clearly, this would be worth noting... and in particular, > could be taken as a motivation for splitting the generation of > timestamps into a separate I-D. >=20 > Thanks so much for your comments! >=20 > Kind regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 From touch@ISI.EDU Fri Mar 26 16:51:05 2010 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 8BE6E3A6B69 for ; Fri, 26 Mar 2010 16:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 xqRuFCEpPg76 for ; Fri, 26 Mar 2010 16:51:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 96FDD3A6B5E for ; Fri, 26 Mar 2010 16:51:04 -0700 (PDT) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2QNo0G3005281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Mar 2010 16:50:01 -0700 (PDT) Message-ID: <4BAD4827.7030202@isi.edu> Date: Fri, 26 Mar 2010 16:49:59 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fernando Gont References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> In-Reply-To: <4BAD02BD.6070907@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFE2273E31DEB83D66F1AD10" X-MailScanner-ID: o2QNo0G3005281 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" , mallman@icir.org Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 26 Mar 2010 23:51:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFE2273E31DEB83D66F1AD10 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Presuming this is the path forward, one issue that needs to be addressed:= - what happens when one side assumes the timestamps are monotonically increasing, but they're not As recent exchanges suggest, there are possible reasons why either side might want to implement timestamps differently. In that case, it's might not be realistic to assume monotonicity. It's not appropriate to consider client/server roles here; the issue is who shuts down the connection and thus holds the TIME_WAIT - that is often the server, but need not be. Overall, if this suggestion requires the TIME_WAIT side assume properties of the other end, it may *require* a flag to ensure. Given we're not talking about such a flag, the entire mechanism may be moot as a result. Joe --------------enigFFE2273E31DEB83D66F1AD10 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkutSCgACgkQE5f5cImnZrtGHwCfd/nN3vm1ry38jONBVClJMuys +xwAoN5CgM8SmnR/XfseSgzpAb60KePx =9fWS -----END PGP SIGNATURE----- --------------enigFFE2273E31DEB83D66F1AD10-- From Manqing.Huang@exar.com Fri Mar 26 17:38:47 2010 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 A7E013A6972 for ; Fri, 26 Mar 2010 17:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 MhAODZ-PKSkn for ; Fri, 26 Mar 2010 17:38:46 -0700 (PDT) Received: from smtp1.exar.com (webmail.exar.com [204.154.183.83]) by core3.amsl.com (Postfix) with ESMTP id BC3753A6933 for ; Fri, 26 Mar 2010 17:38:46 -0700 (PDT) Received: from FRE1EXCH02.hq.exar.com ([fe80::e9a7:6160:4e13:1677]) by fre1-cas ([10.127.1.162]) with mapi; Fri, 26 Mar 2010 17:39:10 -0700 From: Manqing Huang To: Alexander Zimmermann Date: Fri, 26 Mar 2010 17:39:07 -0700 Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 Thread-Index: AQHKzR1YCN1w7l2xYUyMH1O2EBvhR5IEsoDg 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 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, 27 Mar 2010 00:38:47 -0000 Alex, Thank you for your comments. The congestion issue is easier to be observed in a data center. It was repo= rted by one of our customers who is a storage server vendor. The vendor ran= two FTP clients to test the bi-directional traffic between two servers whi= ch are connected by a switch. To debug this issue, we tried different open source TCP performance test to= ols. We found the majority of these tools transmit one-way traffic over eac= h TCP connection when testing bi-directional performance. This fact suggest= s that existing applications may not utilize the duplex feature of a TCP co= nnection when they send two-way traffic between two end points. In the real= world, FTP and HTTP without pipelining do either GET or PUT/POST but not b= oth at the same time. Surely I will try to improve the application scenarios in the draft when mo= re investigation results become available. Regards, Manqing -----Original Message----- From: Alexander Zimmermann [mailto:Alexander.Zimmermann@nets.rwth-aachen.de= ] Sent: Friday, March 26, 2010 12:49 PM To: Manqing Huang Cc: tcpm@ietf.org Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 Hi, I take a quick look at your draft. I really have problems with your applica= tion scenarios. Do you really think that iperf generates congestion in the internet? Also the ftp example is seems quite artificial... Alex Am 26.03.2010 um 10:48 schrieb Manqing Huang: > Hello, > > I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. The= purpose of the TCP option proposed in this draft is to improve TCP perform= ance by reducing the amount of separate ACK packets when there are multiple= TCP connections and each of the connections carries one way traffic. Appli= cations that can benefit from this option include HTTP and FTP. > > Comments are appreciated. > > Thank you. > > Manqing Huang > > > The information and any attached documents contained in this message > may be confidential and/or legally privileged. The message is intended > solely for the addressee(s). If you are not the intended recipient, > you are hereby notified that any use, dissemination, or reproduction > is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender immediately by return > e-mail and destroy all copies of the original message. > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm The information and any attached documents contained in this message may be confidential and/or legally privileged. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, dissemination, or reproduction is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender immediately by return e-mail and destroy all copies of the original message. From fernando@gont.com.ar Fri Mar 26 21:14:03 2010 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 9ACB53A67AD for ; Fri, 26 Mar 2010 21:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.708 X-Spam-Level: X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 88PHnPyVYuPP for ; Fri, 26 Mar 2010 21:14:02 -0700 (PDT) Received: from smtp1.xmundo.net (poseidon.xmundo.net [201.216.232.79]) by core3.amsl.com (Postfix) with ESMTP id ED2453A67B4 for ; Fri, 26 Mar 2010 21:14:00 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 049146B6E42; Sat, 27 Mar 2010 01:14:29 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2R4EKud005623; Sat, 27 Mar 2010 01:14:20 -0300 Message-ID: <4BAD861C.1030401@gont.com.ar> Date: Sat, 27 Mar 2010 01:14:20 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Joe Touch References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> In-Reply-To: <4BAD4827.7030202@isi.edu> X-Enigmail-Version: 0.96.0 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]); Sat, 27 Mar 2010 01:14:28 -0300 (ART) Cc: "tcpm@ietf.org" , mallman@icir.org Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 27 Mar 2010 04:14:03 -0000 Hi, Joe, These are interesting points to be addressed/clarified. Thanks! I will try to address these in the next rev of the document. -- Meanwhile, comments inline.... Joe Touch wrote: > Presuming this is the path forward, one issue that needs to be > addressed: > > - what happens when one side assumes the timestamps are monotonically > increasing, but they're not Worst case scenario: the TIME_WAIT state cannot be recycled, and hence the situation is no worse and no better than the current state of affairs, namely: a) The TIME_WAIT state is assasinated [RFC793], with the connection request being rejected b) The SYN segment is ignored, and thus the connection request times out, or is accepted after future retransmissions of the SYN [RFC1337] > As recent exchanges suggest, there are possible reasons why either > side might want to implement timestamps differently. In that case, > it's might not be realistic to assume monotonicity. It's not really about assuming that timestamps are intentionally monotonically-increasing. *If* they are, no matter whether that was by choice or by chance, you can recycle the TCB. *If* timestamps are monotonically-increasing, then you're sort of assured that the aforementioned "heuristics" will work. This parallels the processing of ISNs in the BSD hack (allowed by the very RFC793). There are stacks that completely randomize the ISNs (e.g., OpenBSD). If the ISN of an incoming SYN is larger than the last SEQ seen for a connection in the TIME_WAIT state, you recycle the TCB. If ISNs are randomized, these heuristics may or may not kick in. > It's not appropriate to consider client/server roles here; the issue > is who shuts down the connection and thus holds the TIME_WAIT - that > is often the server, but need not be. What I meant is that the side more concerned with recycling TCBs in the TIME_WAIT state is the server-side. And that the side that should generate monotonically-increasing timestamps is the client-side. You're right that which side remains in the TIME_WAIT state depends on which side performs the "active close" (rather than on client vs. server). But if it's the client TCB that remains in the TIME_WAIT state, the collision would not even occur, as it would be detected and avoided by the client itself. > Overall, if this suggestion requires the TIME_WAIT side assume > properties of the other end, it may *require* a flag to ensure. I believe this is unnecessary. The beauty of this "TIME_WAIT tossing" things is that this is a local policy, that can be applied even without agreement with the other side. Clearly, for the sake of this policy, it's better if clients generate timestamps such that they are monotonically-increasing across connections. If the chances of TIME_WAIT tossing are reduced. > Given we're not talking about such a flag, the entire mechanism may > be moot as a result. THe "TIME_WAIT tossing" thing is a local policy, rather than a mechanism. If clients generate timestamps such that they are monotonically-increasing they clearly contribute to the success of this policy. That's it. Again, the heuristics performed by BSD-derived kernels with the ISN of incoming SYNs when there's a previous incarnation of the same connection in the TIME_WAIT state. 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 huitema@microsoft.com Fri Mar 26 21:30:13 2010 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 90C763A67BD for ; Fri, 26 Mar 2010 21:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.075 X-Spam-Level: X-Spam-Status: No, score=-8.075 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 A8sf+zG8w+lD for ; Fri, 26 Mar 2010 21:30:12 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id C9F983A63D3 for ; Fri, 26 Mar 2010 21:30:12 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 26 Mar 2010 21:30:37 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 26 Mar 2010 21:30:36 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.99]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Fri, 26 Mar 2010 21:30:37 -0700 From: Christian Huitema To: Fernando Gont , Joe Touch Thread-Topic: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 Thread-Index: AQHKy4dcSKYbIs4o1kKdUE36sVbvi5IFCaGAgABSv4CAAEncAP//jpQQ Date: Sat, 27 Mar 2010 04:30:33 +0000 Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> In-Reply-To: <4BAD861C.1030401@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 27 Mar 2010 04:30:13 -0000 > Clearly, for the sake of this policy, it's better if clients generate > timestamps such that they are monotonically-increasing across > connections. If the chances of TIME_WAIT tossing are reduced. What are the side effects if a computer reboots, keeps the same IP address,= looses memory of the previous time stamps, and then tries to reestablish t= he previous connection? -- Christian Huitema From fernando@gont.com.ar Fri Mar 26 22:33:11 2010 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 46D593A6922 for ; Fri, 26 Mar 2010 22:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.668 X-Spam-Level: X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] 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 5ebe9FbnA+9V for ; Fri, 26 Mar 2010 22:33:10 -0700 (PDT) Received: from smtp1.xmundo.net (poseidon.xmundo.net [201.216.232.79]) by core3.amsl.com (Postfix) with ESMTP id 44F0D3A67CC for ; Fri, 26 Mar 2010 22:33:07 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id EE4486B6E52; Sat, 27 Mar 2010 02:33:36 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2R5XPQH005447; Sat, 27 Mar 2010 02:33:26 -0300 Message-ID: <4BAD98A4.5000708@gont.com.ar> Date: Sat, 27 Mar 2010 02:33:24 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christian Huitema References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.96.0 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]); Sat, 27 Mar 2010 02:33:36 -0300 (ART) Cc: "tcpm@ietf.org" , "mallman@icir.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 27 Mar 2010 05:33:11 -0000 Hello, Christian, Christian Huitema wrote: >> Clearly, for the sake of this policy, it's better if clients >> generate timestamps such that they are monotonically-increasing >> across connections. If the chances of TIME_WAIT tossing are >> reduced. > > What are the side effects if a computer reboots, keeps the same IP > address, looses memory of the previous time stamps, and then tries to > reestablish the previous connection? As per RFC 793, hosts must not establish new connections for a period of 2MSL after they boot (this is the "quiet time" concept defined in RFC793). As a result, specs-wise, that scenario should never occur. If a host does not comply with the "quiet time concept" (i.e., reality-based world), then: * If the selected timestamp for the new connection is monotonically-increasing wrt the last timestamp seen on the previous incarnation of the connection, the TIME_WAIT state is tossed (i.e., the "heuristics" kicks in). * Otherwise, as explained in my previous response to Joe's post, the connection request may time out or be rejected (i.e., this is no worse than the current state-of-affairs without this policy). i.e., I don't see any side-effects.... 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 A.Hoenes@TR-Sys.de Mon Mar 29 13:52:50 2010 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 C3BA73A6B7B for ; Mon, 29 Mar 2010 13:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.008 X-Spam-Level: X-Spam-Status: No, score=-93.008 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MANGLED_LIST=2.3, MIME_8BIT_HEADER=0.3, 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 dj5uHMqo1fL6 for ; Mon, 29 Mar 2010 13:52:49 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 68F4E3A6B2D for ; Mon, 29 Mar 2010 13:51:00 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA088085859; Mon, 29 Mar 2010 22:50:59 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA18283; Mon, 29 Mar 2010 22:50:58 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003292050.WAA18283@TR-Sys.de> To: tcpm@ietf.org Date: Mon, 29 Mar 2010 22:50:57 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security (resent) 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, 29 Mar 2010 20:52:50 -0000 [[ resending due to problem with antispam measures (now resolved) ]] > From: Alfred HÎnes > To: tcpm@ietf.org > Cc: fernando@gont.com.ar > Message-Id: <201003222003.VAA02727@TR-Sys.de> > Date: Mon, 22 Mar 2010 21:03:53 +0100 (MEZ) > Subject: Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security Prologue: It's always a trouble with the rush during the last few weeks before an IETF meeting, and all folks expecting feedback for updates shipped based on comments sent over several months, and all "hopefully before the wg session". :-) Nevertheless, I have provided a detailed off-list editorial review of the current snapshot of the tcp-security draft. I do not want to waste list bandwidth for the bulk of my suggestions, and so only highlight the most important things I found: (1) General I suggest to transform References as needed in text plugged into the WG draft and move them from the 'old refs' to the 'new Refs.' Note that space characters are not possible in ref. anchors for the RFC Editor, so e.g. [Silbersack, 2005] needs to become [Silbersack2005] (or a shorter form). [...] (3) Section 1.2 I suggest to leave off the parenthetical page counts in the list of RFCs and instead place ref. tags ("anchors") there. (1) applies. I also suggest to only use the "official" titles from the RFC index (for RFC 793). [...] The obsolescence of RFC 2581 should be noted; e.g.: o RFC 2581, "TCP Congestion Control" (14 pages) --- o RFC 2581, "TCP Congestion Control" [RFC2581] (recently superseded by RFC 5681) ... and add at the end of the list: o RFC 5681, "TCP Congestion Control" [RFC5681] (successor of RFC 2581) Further, since UTO should be dealt with among the TCP options, I'd suggest to add RFC 5482. [...] (4) Section 1.3 I suggest to reflect the intended grouping in the draft by adding "direct" as shown below: This document is basically organized in two parts. The first part contains a discussion of each of the TCP header fields, identifies | their direct security implications, and discusses the possible countermeasures. The second part contains an analysis of the security implications of the mechanisms [...] [...] (4) Section 2 (4.1) 2nd para and Figure 1 I propose to replace "DARPA" (which is in no way specific to the ARPANET or the Internet) by "TCP/IP" and "reference model" by "layering model". [...] The caption of Fig. 1 then can be simplified: Figure 1: TCP in the DARPA reference model --- Figure 1: The TCP/IP Layering Model (4.2) 2nd-to-last para Here as well, the transition from RFC 2581 to RFC 5681 should be mentioned. [...] (6) Section 3.1.1 (6.1) 2nd para (and other similar places) For clarification, I suggest adding "already" : [...] If a segment is received with port 0 as the Source Port or the Destination Port, a RST segment SHOULD be sent | in response (provided that the incomming segment does not already have the RST flag set). [...] (6.3) 5th para Privileged ports usually are 0-1023, not including 1024 ! Due to recurring issues, I once more urgently recommend to add the salvatory clause from RFC 1122 that no system should assume that another system makes this distinction. While some systems restrict use of the port numbers in the range | 0-1024 to privileged users, applications SHOULD NOT grant any trust | based on the port numbers used for a TCP connection. --- While some systems restrict use of the port numbers in the range | 0-1023 to privileged users, applications SHOULD NOT grant any trust | based on the port numbers used for a TCP connection, and a system | making this distinction locally MUST NOT assume that other systems | do that as well (cf. [RFC1122] and [RFC1812]). (6.4) last para [...] For similar reasons, I suggest to even more strongly state here: Middle-boxes such as packet filters MUST NOT assume that clients use | ephemeral port numbers from only some restricted port range. ^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^ [...] (9) Section 3.1.2.2 (9.1) 1st para The text there abuses the term "obfuscation" (cf. my LC comments for the Port Randomization draft on TSVWG). ... obfuscation of this four-tuple to an off-path attacker ... does not make sense IMO. The four-tuple is in the clear. Simply say: ... randomization of this four-tuple ... Later on: ... since this increases the obfuscation. [...] might better state: ... since this decreases the likelihood of correct guessing by an off-path attacker. [...] [...] (10) Section 3.1.2.3, 3rd para The present text there IMO confuses ephemeral ports and connection IDs -- the same ephemeral port can independently be used for other destinations. I suggest to add much more precision to the text and amend the paragraph as follows: If the connection rate is high enough, at some point all the ephemeral ports at the client will be in use by some connection in | the TIME-WAIT state, thus preventing the establishment of new | connections. In order to overcome this problem, a number of TCP | implementations include some heuristics to allow the creation of a | new incarnation of a connection that is in the TIME-WAIT state. [...] --- If the connection rate is high enough, at some point all the ephemeral ports at the client will be in use by some connection in | the TIME-WAIT state with the same source IP address and destination | IP address and port number, thus preventing the establishment of new | connections to that server. If the client detects such saturation of | connections in TIME-WAIT state, it must defer (although some | implementations will prematurely re-use a previous connection | identifier). For the case where the server encounters such TIME-WAIT | saturation, a number of TCP implementations include some heuristics | to overcome this problem and allow the creation of a new incarnation | of a connection that is in the TIME-WAIT state. [...] Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | 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 touch@ISI.EDU Mon Mar 29 16:37:16 2010 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 2B36B3A69B2 for ; Mon, 29 Mar 2010 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 w6HtCjIHapj9 for ; Mon, 29 Mar 2010 16:37:15 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 5C0CF3A6989 for ; Mon, 29 Mar 2010 16:37:15 -0700 (PDT) Received: from [192.168.1.131] (c-67-190-26-81.hsd1.co.comcast.net [67.190.26.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o2TNaphP009388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 16:36:54 -0700 (PDT) Message-ID: <4BB13993.5040801@isi.edu> Date: Mon, 29 Mar 2010 16:36:51 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fernando Gont References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BAD98A4.5000708@gont.com.ar> In-Reply-To: <4BAD98A4.5000708@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6AE0F0178C9E87252CA115F2" X-MailScanner-ID: o2TNaphP009388 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Christian Huitema , "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 29 Mar 2010 23:37:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6AE0F0178C9E87252CA115F2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, Given how this issue has evolved, it might be useful to hold off on the adoption decision to see the revised idea in its full context, i.e., in a revision of the doc... Joe --------------enig6AE0F0178C9E87252CA115F2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuxOZMACgkQE5f5cImnZruZOgCfSwBsdVIOBgXcy0VG6oJCk0+t Q7UAoLWeCOnOYSJT/RI8jN3LLJTr1cSn =FP5O -----END PGP SIGNATURE----- --------------enig6AE0F0178C9E87252CA115F2-- From fernando@gont.com.ar Mon Mar 29 18:18:04 2010 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 9B4503A682E for ; Mon, 29 Mar 2010 18:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.264 X-Spam-Level: X-Spam-Status: No, score=-0.264 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, 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 CchzwoFKDZKU for ; Mon, 29 Mar 2010 18:18:02 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 3CA2E3A685A for ; Mon, 29 Mar 2010 18:17:54 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id BB3DB6B67A2; Mon, 29 Mar 2010 22:18:26 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2U1IHoM002466; Mon, 29 Mar 2010 22:18:18 -0300 Message-ID: <4BB15156.3030408@gont.com.ar> Date: Mon, 29 Mar 2010 22:18:14 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Joe Touch References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BAD98A4.5000708@gont.com.ar> <4BB13993.5040801@isi.edu> In-Reply-To: <4BB13993.5040801@isi.edu> X-Enigmail-Version: 0.96.0 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]); Mon, 29 Mar 2010 22:18:26 -0300 (ART) Cc: Christian Huitema , "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 30 Mar 2010 01:18:04 -0000 Joe Touch wrote: > Given how this issue has evolved, it might be useful to hold off on the > adoption decision to see the revised idea in its full context, i.e., in > a revision of the doc... I don't follow what you mean by "how this issue has evolved". Some people asked for clarifications, and I have clarified those issues. If you want this even with the tiny details, here's it: * TCPs performing the active open should select timestamps such that they are monotonically increasing across connections. -- This does not mandate monotonically-increasng timestamps for TCPs that perform the passive open, as they may be willing to implement the extended syn cookies thing described a while ago by andre Opperman. * Processing of incoming SYN segments is done according to what's already in the I-D. Tihs has no bad side effect, no matter what the timestamps generation algorithm at the remote TCP. Please let's move on.... 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 Mon Mar 29 19:29:11 2010 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 235103A67C0 for ; Mon, 29 Mar 2010 19:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 rt3C9QMopgYV for ; Mon, 29 Mar 2010 19:29:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id D91B03A683C for ; Mon, 29 Mar 2010 19:29:09 -0700 (PDT) Received: from [192.168.1.131] (c-67-190-26-81.hsd1.co.comcast.net [67.190.26.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o2U2TA5j011559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 19:29:15 -0700 (PDT) Message-ID: <4BB161F5.3060805@isi.edu> Date: Mon, 29 Mar 2010 19:29:09 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Fernando Gont References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BAD98A4.5000708@gont.com.ar> <4BB13993.5040801@isi.edu> <4BB15156.3030408@gont.com.ar> In-Reply-To: <4BB15156.3030408@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9487CA616C0A5F80B192012D" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Christian Huitema , "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 30 Mar 2010 02:29:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9487CA616C0A5F80B192012D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >> Given how this issue has evolved, it might be useful to hold off on th= e >> adoption decision to see the revised idea in its full context, i.e., i= n >> a revision of the doc... >=20 > I don't follow what you mean by "how this issue has evolved". Some > people asked for clarifications, and I have clarified those issues. The 03 draft focused on creating an algorithm that prevented guess-based attacks. The discussion, as far as I can tell, has focused on the most peripheral part of 03 - the use of TS to cut TIME_WAIT. IMO, that's a sufficient change that we're no longer considering a mere evolution of 03. The title, abstract, and most of the discussion will change. Other points need to be addressed, notably: - are TS values already sufficiently monotonic, or is an alg needed? - is per-socketpair state needed to support monotonicity? - interaction with SYN cookies - corner cases (when not monotonic, whether that can be known, when it's supported on only one side, etc.) - whether this depends on knowing which end will close the connection first at SYN time I don't feel discussion on the mailing list is sufficient to consider the entirety of this proposal, and not just whether it's possible, but whether it's necessary. Joe --------------enig9487CA616C0A5F80B192012D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuxYfUACgkQE5f5cImnZru/xACdF0mJhAttxV8ni4xVWbpHcWly dnoAnj4Qgohoias1IAZTst3ik6xyLUYa =RJZC -----END PGP SIGNATURE----- --------------enig9487CA616C0A5F80B192012D-- From fernando@gont.com.ar Mon Mar 29 20:06:16 2010 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 EDB053A6872 for ; Mon, 29 Mar 2010 20:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 bUcYI379RUCr for ; Mon, 29 Mar 2010 20:06:16 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id AD2C13A67A2 for ; Mon, 29 Mar 2010 20:06:14 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 7E0EC6B6AC7; Tue, 30 Mar 2010 00:06:48 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2U36cTn023439; Tue, 30 Mar 2010 00:06:40 -0300 Message-ID: <4BB16ABB.4030506@gont.com.ar> Date: Tue, 30 Mar 2010 00:06:35 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Joe Touch References: <20100324192236.2D025BCAEF0@lawyers.icir.org> <4BAD02BD.6070907@gont.com.ar> <4BAD4827.7030202@isi.edu> <4BAD861C.1030401@gont.com.ar> <6B55F0F93C3E9D45AF283313B8D342BA68637D47@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <4BAD98A4.5000708@gont.com.ar> <4BB13993.5040801@isi.edu> <4BB15156.3030408@gont.com.ar> <4BB161F5.3060805@isi.edu> In-Reply-To: <4BB161F5.3060805@isi.edu> X-Enigmail-Version: 0.96.0 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, 30 Mar 2010 00:06:47 -0300 (ART) Cc: Christian Huitema , "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 30 Mar 2010 03:06:17 -0000 Joe, > The 03 draft focused on creating an algorithm that prevented guess-based > attacks. No. Version -03 focuses on creating an algorithm such that timestamps are monotonically-increasing. Another property of the algorithm is that timestamps are hard to guess. Finally, the doc proposes an algorithm for improved handling of SYN segments. See the abstract. It's not a "protecting TCP against blid attacks via tcp timestamps" at all. > The discussion, as far as I can tell, has focused on the most peripheral > part of 03 - the use of TS to cut TIME_WAIT. Peripheral? Please compare the length of Section 2 and Section 3. Most of the I-D is about processing SYN segments, rather than about generating timestamps. > IMO, that's a sufficient change that we're no longer considering a mere > evolution of 03. The title, abstract, and most of the discussion will > change. I disagree. But won't continue arguing on this one. You have apposed to this I-D since the thread was started. Hopefully the chairs have noted that. But hey have also noted the rest of the people, that did support it. > Other points need to be addressed, notably: > > - are TS values already sufficiently monotonic, or is > an alg needed? What's "sufficiently monotonic"? There's no requirement for monotonically-increasing timestamps across connections. > - is per-socketpair state needed to support monotonicity? Obviously not. It *is* useful for the algorithm currently proposed in the I-D. > - interaction with SYN cookies Note sure what you mean. Obviously, if timestamps are "on", you can take advantage of this. If not, no. > - corner cases (when not monotonic, whether that can be > known, when it's supported on only one side, etc.) This has all been clarified. > - whether this depends on knowing which end will close the > connection first at SYN time I have already clarified this. It doesn't matter who ends-up closing the connection. > I don't feel discussion on the mailing list is sufficient to consider > the entirety of this proposal, and not just whether it's possible, but > whether it's necessary. Joe, you have been opposed to this I-D, are opposed to this I-D, and will be opposed to this I-D. Point taken. Can the rest of us, if we agree, get some work done? P.S.: Again, nobody is shipping the I-D for publication as an RFC. So don't expect the I-D to be perfect at this point. 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 mallman@icir.org Mon Mar 29 20:06:31 2010 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 BB3373A68D7 for ; Mon, 29 Mar 2010 20:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 PK3kPI75YasR for ; Mon, 29 Mar 2010 20:06:30 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 9FB993A6835 for ; Mon, 29 Mar 2010 20:06:30 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o2U36sec002309; Mon, 29 Mar 2010 20:06:54 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id EB19EC2124C; Mon, 29 Mar 2010 23:06:53 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <4BB161F5.3060805@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Zombie MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma27341-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 29 Mar 2010 23:06:53 -0400 Sender: mallman@icir.org Message-Id: <20100330030653.EB19EC2124C@lawyers.icir.org> Cc: Christian Huitema , "tcpm@ietf.org" , Fernando Gont Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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: Tue, 30 Mar 2010 03:06:31 -0000 ----------ma27341-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Catching up, I will chime in with three things ... - It still seems to me like we have pretty well converged that the draft's value is in terms of the TIME_WAIT truncation scheme. - My own opinion is that the draft can simply say "this scheme works best with monotonically increasing timestamps" and leave it at that. I.e., it isn't a strict requirement because the fall-back is just what we have without timestamps and if it were a strict requirement we'd have to think about flags and such. I.e., TCP implementers are smart folks who don't need RFC pages to define for them how to generate a monotonic sequence of timestamps and so my view is that doing so is useless detail. - I agree with Joe's note below that this discussion has led to an evolved understanding of the issues and what will be in the draft and it'd be nice to see either (a) a new draft from Fernando that we can adopt or at least (b) an outline from the chairs that sketches a WG document and its major components that can then be filled in by some editor. allman > The 03 draft focused on creating an algorithm that prevented guess-based > attacks. > > The discussion, as far as I can tell, has focused on the most peripheral > part of 03 - the use of TS to cut TIME_WAIT. > > IMO, that's a sufficient change that we're no longer considering a mere > evolution of 03. The title, abstract, and most of the discussion will > change. > > Other points need to be addressed, notably: > > - are TS values already sufficiently monotonic, or is > an alg needed? > > - is per-socketpair state needed to support monotonicity? > > - interaction with SYN cookies > > - corner cases (when not monotonic, whether that can be > known, when it's supported on only one side, etc.) > > - whether this depends on knowing which end will close the > connection first at SYN time > > I don't feel discussion on the mailing list is sufficient to consider > the entirety of this proposal, and not just whether it's possible, but > whether it's necessary. ----------ma27341-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkuxas0ACgkQWyrrWs4yIs7CHQCfbJq8lyl55xKpG/sMGXphmdb3 Si4AoJRBa2vPv9KBCExTvRUNbUhbWh2X =b/xF -----END PGP SIGNATURE----- ----------ma27341-1-- From fernando@gont.com.ar Mon Mar 29 20:12:09 2010 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 920CC3A6813 for ; Mon, 29 Mar 2010 20:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.206 X-Spam-Level: X-Spam-Status: No, score=-1.206 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 TWAAD6nbA-2j for ; Mon, 29 Mar 2010 20:12:08 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 65F6C3A67FF for ; Mon, 29 Mar 2010 20:12:07 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AE9146B6AC7; Tue, 30 Mar 2010 00:12:41 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2U3CWxc025064; Tue, 30 Mar 2010 00:12:33 -0300 Message-ID: <4BB16C1D.2020502@gont.com.ar> Date: Tue, 30 Mar 2010 00:12:29 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: mallman@icir.org References: <20100330030653.EB19EC2124C@lawyers.icir.org> In-Reply-To: <20100330030653.EB19EC2124C@lawyers.icir.org> X-Enigmail-Version: 0.96.0 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, 30 Mar 2010 00:12:40 -0300 (ART) Cc: Christian Huitema , "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03 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, 30 Mar 2010 03:12:09 -0000 Mark, I can publish such a rev. Will split the "timestamps generation" into a separate I-D, and will address in the current draft those points that needed clarification, etc. Thanks, Fernando Mark Allman wrote: > Catching up, I will chime in with three things ... > > - It still seems to me like we have pretty well converged that the > draft's value is in terms of the TIME_WAIT truncation scheme. > > - My own opinion is that the draft can simply say "this scheme works > best with monotonically increasing timestamps" and leave it at > that. > > I.e., it isn't a strict requirement because the fall-back is just > what we have without timestamps and if it were a strict requirement > we'd have to think about flags and such. > > I.e., TCP implementers are smart folks who don't need RFC pages to > define for them how to generate a monotonic sequence of timestamps > and so my view is that doing so is useless detail. > > - I agree with Joe's note below that this discussion has led to an > evolved understanding of the issues and what will be in the draft > and it'd be nice to see either (a) a new draft from Fernando that we > can adopt or at least (b) an outline from the chairs that sketches > a WG document and its major components that can then be filled in by > some editor. > > allman > > > > >> The 03 draft focused on creating an algorithm that prevented guess-based >> attacks. >> >> The discussion, as far as I can tell, has focused on the most peripheral >> part of 03 - the use of TS to cut TIME_WAIT. >> >> IMO, that's a sufficient change that we're no longer considering a mere >> evolution of 03. The title, abstract, and most of the discussion will >> change. >> >> Other points need to be addressed, notably: >> >> - are TS values already sufficiently monotonic, or is >> an alg needed? >> >> - is per-socketpair state needed to support monotonicity? >> >> - interaction with SYN cookies >> >> - corner cases (when not monotonic, whether that can be >> known, when it's supported on only one side, etc.) >> >> - whether this depends on knowing which end will close the >> connection first at SYN time >> >> I don't feel discussion on the mailing list is sufficient to consider >> the entirety of this proposal, and not just whether it's possible, but >> whether it's necessary. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- 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 Mon Mar 29 23:38:43 2010 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 B57FD3A6A47 for ; Mon, 29 Mar 2010 23:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 mj4LKtH2AnsJ for ; Mon, 29 Mar 2010 23:38:43 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id CE0A13A6A00 for ; Mon, 29 Mar 2010 23:38:41 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C6A626B6A80; Tue, 30 Mar 2010 03:39:16 -0300 (ART) Received: from [192.168.0.102] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2U6d5pj013689; Tue, 30 Mar 2010 03:39:05 -0300 Message-ID: <4BB19C84.6000006@gont.com.ar> Date: Tue, 30 Mar 2010 03:39:00 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "tcpm@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=utf-8 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, 30 Mar 2010 03:39:16 -0300 (ART) Cc: "tcpm-chairs@tools.ietf.org" , =?UTF-8?B?QWxmcmVkIEjDtm5lcw==?= , Mark Allman , Joe Touch Subject: [tcpm] [Fwd: New Version Notification for draft-gont-tcpm-tcp-timestamps-04] 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, 30 Mar 2010 06:38:43 -0000 Folks, FYI. This is a first attempt to address he issues raised on the mailing-list. Please yell if I missed any. Thanks, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-tcpm-tcp-timestamps-04 Date: Mon, 29 Mar 2010 23:36:01 -0700 (PDT) From: IETF I-D Submission Tool To: fernando@gont.com.ar A new version of I-D, draft-gont-tcpm-tcp-timestamps-04.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-tcpm-tcp-timestamps Revision: 04 Title: Reducing the TIME-WAIT state using TCP timestamps Creation_date: 2010-03-30 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. The IETF Secretariat. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From root@core3.amsl.com Tue Mar 30 04:15:08 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DA9293A6A10; Tue, 30 Mar 2010 04:15:05 -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: <20100330111507.DA9293A6A10@core3.amsl.com> Date: Tue, 30 Mar 2010 04:15:05 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-12.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: Tue, 30 Mar 2010 11:15:11 -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-12.txt Pages : 41 Date : 2010-03-30 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). 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-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-30040459.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Tue Mar 30 07:00:01 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 91C593A69DC; Tue, 30 Mar 2010 07:00: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: <20100330140001.91C593A69DC@core3.amsl.com> Date: Tue, 30 Mar 2010 07:00:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcp-lcd-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: Tue, 30 Mar 2010 14:00: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 : Making TCP more Robust to Long Connectivity Disruptions (TCP-LCD) Author(s) : A. Zimmermann, A. Hannemann Filename : draft-ietf-tcpm-tcp-lcd-01.txt Pages : 26 Date : 2010-03-30 Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission. This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a revert strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in case of connectivity disruptions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-lcd-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcp-lcd-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-30064506.I-D@ietf.org> --NextPart-- From hannemann@i4.informatik.rwth-aachen.de Tue Mar 30 07:13:31 2010 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 6B1393A6BA4 for ; Tue, 30 Mar 2010 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.671 X-Spam-Level: X-Spam-Status: No, score=-3.671 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 CmfugHNYGhQV for ; Tue, 30 Mar 2010 07:13:23 -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 928B13A6BB2 for ; Tue, 30 Mar 2010 07:13:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-15 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 <0L0300JQVM70UJ30@mta-1.ms.rz.RWTH-Aachen.de> for tcpm@ietf.org; Tue, 30 Mar 2010 16:13:48 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.51,334,1267398000"; d="scan'208";a="50939718" Received: from relay-2.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.75]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 30 Mar 2010 16:13:48 +0200 Received: from [137.226.12.76] (informatik-4-137-226-12-76.nn.RWTH-Aachen.DE [137.226.12.76] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id o2UEDmXl013603 for ; Tue, 30 Mar 2010 16:13:48 +0200 (CEST) Message-id: <4BB2070B.6030100@i4.informatik.rwth-aachen.de> Date: Tue, 30 Mar 2010 16:13:31 +0200 From: Arnd Hannemann User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100322 Lightning/1.0b2pre Thunderbird/3.0.3 To: tcpm@ietf.org References: <20100330140001.91C593A69DC@core3.amsl.com> In-reply-to: <20100330140001.91C593A69DC@core3.amsl.com> Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-lcd-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: Tue, 30 Mar 2010 14:13:32 -0000 Hi all, as my colleague Alex mentioned at Anaheim here is our updated version of TCP-LCD. Besides the announced editorial changes, we also added a brief discussion about TCP-LCD's behavior during TCP's connection establishment (thanks to Mark Handley). Best regards, Arnd From AVSHALOM@il.ibm.com Sun Mar 28 08:04:25 2010 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 D26643A6405; Sun, 28 Mar 2010 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=0.6, 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 sWSigAdBT7Xi; Sun, 28 Mar 2010 08:04:24 -0700 (PDT) Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.17.161]) by core3.amsl.com (Postfix) with ESMTP id AEE7C3A63EB; Sun, 28 Mar 2010 08:04:21 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id o2SF4jCw016959; Sun, 28 Mar 2010 15:04:45 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2SF4jis1601652; Sun, 28 Mar 2010 17:04:45 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o2SF4jvV011031; Sun, 28 Mar 2010 17:04:45 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id o2SF4j1m011028; Sun, 28 Mar 2010 17:04:45 +0200 In-Reply-To: References: To: Gregory Lebovitz MIME-Version: 1.0 X-KeepSent: AD09193E:C6C78A0B-C22576F4:0051BB56; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Avshalom Houri Message-ID: Date: Sun, 28 Mar 2010 18:04:34 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 28/03/2010 18:04:44, Serialize complete at 28/03/2010 18:04:44 Content-Type: multipart/alternative; boundary="=_alternative 00527810C22576F4_=" X-Mailman-Approved-At: Tue, 30 Mar 2010 08:15:00 -0700 Cc: ekr@rtfm.com, tcpm@ietf.org, Russ Housley , General Area Review Team Subject: Re: [tcpm] Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-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: Sun, 28 Mar 2010 15:04:26 -0000 This is a multipart message in MIME format. --=_alternative 00527810C22576F4_= Content-Type: text/plain; charset="US-ASCII" Gregory Lebovitz wrote on 24/03/2010 11:02:57 AM: > Re: Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-02 > > Gregory Lebovitz > > to: > > Avshalom Houri > > 24/03/2010 11:03 AM > > Cc: > > General Area Review Team, ekr, Russ Housley, lars.eggert, tcpm > > Avshalom, > Thanks for your review. The indicated changes inline below have been > made in -03, which will be issued shortly. See inline... > On Tue, Mar 9, 2010 at 3:20 PM, Avshalom Houri wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-tcpm-tcp-ao-crypto-02 > Reviewer: Avshalom Houri > Review Date: 2010-03-09 > IETF LC date: 2010-03-10 > IESG Telechat date: 2010-03-11 > > Summary: The draft is ready for a standard track RFC (see minor > issues and nits). > The document is a reasonable basis on which to build the salient part of the > Internet infrastructure. > > Major issues: None > > Minor issues: > > Line 211 > This is the initial specification of required cryptography for > > Why it is initial? Initial RFC? > > TCP-AO is brand new, and this is the first ever specification of > required cryptography for -AO. We assume, as time goes on, that > others could follow. No change to text. Initial sounds as an initial version. Maybe say the first in a series or similar? > > > Lines 232-238 > I do not see the requirements only MUSTs. > > Not sure what you mean here. The "Requirement" is "MUST" as opposed > to SHOULD or MAY. No change. > I meant that I see the word MUST but I do not see the requirement itself. Is the algorithm or the key derivation function are the requirements? > > Line 260 > "MUST" to implement, in order to drive vendors toward its use, and to > > Should the IETF include something as a must in order to drive its > implementation? > > This decision/text was re-worked several times and reflects WG > consensus. No change. I still think that the IESG should address this. Many times even WG consensus is not accepted at the IESG level. > > > > Line 862: > above. We simply attempted to "put a fence around stupidity", in as > > Maybe change the language for the RFC? > > makes sense. s/stupidity/foolishness/ Why to use an offensive word? > > > > Nits/editorial comments: > > Line 182 > verification between to end-points. In order to accomplish this > -> verification between two end-points. In order to accomplish this > > done > > > > > Line 384 > starts = 1. > > -> starts at 1. > > because "i" is a counter, I think being precise with the "=" is > appropriate. No change. > > Thanks again for the review, > Gregory. > > > --Avshalom > > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > Juniper Networks --=_alternative 00527810C22576F4_= Content-Type: text/html; charset="US-ASCII" Gregory Lebovitz <gregory.ietf@gmail.com> wrote on 24/03/2010 11:02:57 AM:

> Re: Gen art LC+TC review of: draft-ietf-tcpm-tcp-ao-crypto-02
>
> Gregory Lebovitz
>
> to:
>
> Avshalom Houri
>
> 24/03/2010 11:03 AM
>
> Cc:
>
> General Area Review Team, ekr, Russ Housley, lars.eggert, tcpm
>
> Avshalom,
> Thanks for your review. The indicated changes inline below have been
> made in -03, which will be issued shortly. See inline...
> On Tue, Mar 9, 2010 at 3:20 PM, Avshalom Houri <AVSHALOM@il.ibm.com> wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-tcpm-tcp-ao-crypto-02
> Reviewer: Avshalom Houri
> Review Date: 2010-03-09
> IETF LC date: 2010-03-10
> IESG Telechat date: 2010-03-11
>
> Summary: The draft is ready for a standard track RFC (see minor
> issues and nits).
> The document is a reasonable basis on which to build the salient part of the
> Internet infrastructure.
>
> Major issues: None
>
> Minor issues:
>
> Line 211
>    This is the initial specification of required cryptography for
>
> Why it is initial? Initial RFC?
>
> TCP-AO is brand new, and this is the first ever specification of
> required cryptography for -AO. We assume, as time goes on, that
> others could follow. No change to text.

Initial sounds as an initial version. Maybe say the first in a series or
similar?

>  
>
> Lines 232-238
> I do not see the requirements only MUSTs.
>
> Not sure what you mean here. The "Requirement" is "MUST" as opposed
> to SHOULD or MAY. No change.
>  

I meant that I see the word MUST but I do not see the requirement itself.
Is the algorithm or the key derivation function are the requirements?

>
> Line 260
>    "MUST" to implement, in order to drive vendors toward its use, and to
>
> Should the IETF include something as a must in order to drive its
> implementation?
>
> This decision/text was re-worked several times and reflects WG
> consensus. No change.

I still think that the IESG should address this. Many times even WG
consensus is not accepted at the IESG level.

>  
>
>
> Line 862:
>    above.  We simply attempted to "put a fence around stupidity", in as
>
> Maybe change the language for the RFC?
>
> makes sense.  s/stupidity/foolishness/

Why to use an offensive word?

>  
>
>
> Nits/editorial comments:
>
> Line 182
>    verification between to end-points.  In order to accomplish this
> ->    verification between two end-points.  In order to accomplish this
>
> done
>
>  
>
>
> Line 384
>                    starts = 1.
>
> -> starts at 1.
>
> because "i" is a counter, I think being precise with the "=" is
> appropriate. No change.
>
> Thanks again for the review,
> Gregory. 
>  
>
> --Avshalom
>

>
>
>
> --
> ----
> IETF related email from
> Gregory M. Lebovitz
> Juniper Networks --=_alternative 00527810C22576F4_=-- From Alexander.Zimmermann@nets.rwth-aachen.de Wed Mar 31 05:27:29 2010 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 83F203A67B1 for ; Wed, 31 Mar 2010 05:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 DKptHSoEKh4a for ; Wed, 31 Mar 2010 05:27:28 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 5162E3A677C for ; Wed, 31 Mar 2010 05:27:26 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id D8F8A57AC2; Wed, 31 Mar 2010 14:27:56 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 31 Mar 2010 14:27:38 +0200 From: Alexander Zimmermann To: David Borman Thread-Topic: [tcpm] WGLC for MSS document Thread-Index: AQHKzG7BmJAD/fL+R0Se50NJqKDMOJIL4McA Date: Wed, 31 Mar 2010 12:27:54 +0000 Message-ID: <3D3F9DBD-D29B-400D-A8A1-653310F5C703@nets.rwth-aachen.de> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <5ddf3ab2-056f-4bc4-8516-ea9c7c8c4f67> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tcpm@ietf.org WG" 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: Wed, 31 Mar 2010 12:27:29 -0000 SGkgRGF2aWQsDQoNCkkgbGlrZSB0aGUgY2hhbmdlcyB5b3UgaGF2ZSBtYWRlLiBFc3BlY2lhbGx5 LCB0aGUgaGlzdG9yeSBzdHVmZiB5b3UNCmFkZGVkIChTZWMgMywgQXBwZW5kaXgpIGlzIHF1aXRl IGludGVyZXN0aW5nIGZvciAieW91bmciIGd1eXMgbGlrZSBtZS4NCg0KSG93ZXZlciwgaGVyZSBh cmUgc29tZSByZW1hcmtzLiBQbGVhc2Ugbm90ZSB0aGF0IHRoZXNlIGNvbW1lbnRzIGFyZQ0Kc29t ZWhvdyB0cml2aWEuIElmIHlvdSBkb24ndCBsaWtlIHRoZSBjaGFuZ2VzLCBmb3JnZXQgYWJvdXQg dGhlbS4gV2hhdA0KSSByZWFsbHkgZG8gbm90IHdhbnQgaXMgdG8gYmxvY2sgdGhlIHByb2dyZXNz Lg0KDQoqIFNlYyAyLCBwYXJhIDI6IEkgd291bGQgYWRkIHJlZmVyZW5jZXMgZm9yIHRoZSBUQ1Ag SVB2NC82DQpoZWFkZXIgbGVuZ3Rocw0KDQoqIEFwcGVuZGl4LCBsYXN0IGVxdWF0aW9uOiBJIHN1 Z2dlc3QgdG8gYWRkIHRoZSBib3VuZHMgaW50byB0aGUgZXF1YXRpb24NCiAgICAgIDU3NiA8PSBF TVRVX1IgLSBGaXhlZElQaGRyc2l6ZSAtIEZpeGVkVENQaGRyc2l6ZSA8PSBNVFUNCg0KKiBTZWMg NDogSUhPIHRoZSBleHBsYW5hdGlvbiBvZiB0aGUgdGFibGUgaXMgdG9vIGltcGxpY2l0Lg0KDQpJ biB0aGUgZm9sbG93aW5nLCBsZXQncyBuYW1lIHRoZSBmaWVsZHMgb2YgdGhlIHRhYmxlIGxpa2Ug dGhpczogdXBwZXIgbGVmdCAxLA0KdXBwZXIgcmlnaHQgMiwgbG93ZXIgbGVmdCAzLCBsb3dlciBy aWdodCA0Lg0KDQpSaWdodCBhZnRlciB0aGUgdGFibGUsIHRoZSBkcmFmdCBzYWlkOg0KDQoiU2lu Y2UgdGhlIGdvYWwgaXMgdG8gbm90IHNlbmQgSVAgZGF0YWdyYW1zIHRoYXQgaGF2ZSB0byBiZSBm cmFnbWVudGVkLCBhbmQNCnBhY2tldHMgc2VudCB3aXRoIHRoZSBjb25zdHJhaW50cyBpbiB0aGUg bG93ZXIgcmlnaHQgb2YgdGhpcyBncmlkIHdpbGwgY2F1c2UNCklQIGZyYWdtZW50YXRpb24sIHRo ZSBvbmx5IHdheSB0byBndWFyYW50ZWUgdGhhdCB0aGlzIGRvZXNu4oCZdCBoYXBwZW4gaXMgZm9y IHRoZQ0KZGF0YSBzZW5kZXIgdG8gZGVjcmVhc2UgdGhlIFRDUCBkYXRhIGxlbmd0aCBieSB0aGUg c2l6ZSBvZiB0aGUgSVAgYW5kIFRDUCBvcHRpb25zIg0KDQpIYXZpbmcgcmVhZCB0aGlzLCB0aGUg Zm9sbG93aW5nIGNvbWVzIHRvIG15IG1pbmQ6IEknbSBzaXR0aW5nIGluICg0KSBhbmQgSSB3YW50 IHRvDQpsZWF2ZSB0aGlzIHN0YXRlLiBUaGUgdGV4dCBzYWlkIHRoYXQgb25seSB0aGUgdHJhbnNp dGlvbiB0byAoMikgaXMgcG9zc2libGUuIEhvd2V2ZXIsDQp3aGVuIEkgbG9va2VkIGF0IHRoZSB0 YWJsZSwgSSB0aG91Z2h0OiBJIGNhbiBhbHNvIGdvIHRvICgzKSBzaW5jZSB0aGUgdGFibGUgc2Fp ZCBoZXJlDQoiUGFja2V0cyBhcmUgdGhlIGNvcnJlY3QgbGVuZ3RoIi4gQmFuZyEgSSBnb3QgY29u ZnVzZWQgc2luY2UgdGhlIHRleHQgc2FpZCwgdGhlDQoqb25seSogd2F5IGlzICgyKS4gQnV0IHdo eT8gQXQgdGhpcyBwb2ludCBJIGV4cGVjdGVkIGFuIGV4cGxhbmF0aW9uIHdoeSAoMykgaXMgYQ0K YmFkIGlkZWE/DQoNCkRvIHlvdSB1bmRlcnN0YW5kIHdoYXQgSSdtIHRyeWluZyB0byBzYXk/IE1h eWJlIEkgcmVhZCB0aGUgdGFibGUgd3JvbmcuIEkgcmVhZCBpdA0KbGlrZSBhIHRyYW5zaXRpb24g ZGlhZ3JhbS4gU2hvdWxkIEkgcmVhZCBpdCBsaW5lIGJ5IGxpbmUsIGNvbHVtbiBieSBjb2x1bW4s Li4uPw0KDQpBbGV4DQoNCkFtIDI1LjAzLjIwMTAgdW0gMjM6NTkgc2NocmllYiBEYXZpZCBCb3Jt YW46DQoNCj4gT24gQXVnIDE4LCAyMDA5LCBhdCAxMDozOCBBTSwgRWRkeSwgV2VzbGV5IE0uIChH UkMtTVMwMClbVmVyaXpvbl0gd3JvdGU6DQo+IA0KPj4gVGhpcyBub3RlIHN0YXJ0cyBhIDItd2Vl ayBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBvbiB0aGUgVENQTSBkb2N1bWVudDoNCj4+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS10Y3Btc3MtMDINCj4+IFBsZWFz ZSBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgVENQTSBsaXN0LiAgVGhlIFdHTEMgd2lsbCBsYXN0 IHVudGlsDQo+PiBTZXB0ZW1iZXIgMS4NCj4gDQo+IA0KPiBJJ3ZlIGZpbmFsbHkgZmluaXNoZWQg dXBkYXRpbmcgdGhlIE1TUyBkb2N1bWVudCwgYW5kIGhhdmUgdXBsb2FkZWQgaXQuDQo+IAlodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tdGNwbXNzLTAzDQo+IEkgYmVs aWV2ZSBJIGhhdmUgYWRkcmVzc2VkIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRo ZSBMYXN0IENhbGwsIGFuZCBoYXZlIGRvbmUgc29tZSBhZGRpdGlvbmFsIGNoYW5nZXMgYmV5b25k IHRoYXQuICBJJ3ZlIGJlZW4gZGlzY3Vzc2luZyB0aGUgZG9jdW1lbnQgdGhpcyB3ZWVrIGF0IHRo ZSBJRVRGIHdpdGggc2V2ZXJhbCBwZW9wbGUsIGFuZCB0aGUgcmVzdWx0cyBvZiB0aG9zZSBjb252 ZXJzYXRpb25zIGFyZSBpbmNsdWRlZCBpbiB0aGlzIG5ldyBkcmFmdC4NCj4gDQo+IEJlY2F1c2Ug b2YgdGhlIHRpbWUgbGFwc2UsIGFuZCB0aGUgbnVtYmVyIG9mIGNoYW5nZXMgdGhhdCBJJ3ZlIG1h ZGUgdG8gdGhlIGRvY3VtZW50LCBsZXQncyBleHRlbmQgdGhlDQo+IFdHTEMgdG8gVGh1cnNkYXks IEFwcmlsIDguDQo+IA0KPiBCZWxvdyBhcmUgbXkgcmVzcG9uc2VzIHRvIGFsbCB0aGUgY29tbWVu dHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBvcmlnaW5hbCBXR0xDLg0KPiANCj4gCQkJLURhdmlkIEJv cm1hbg0KPiANCj4gDQo+IE9uIEF1ZyAyMCwgMjAwOSwgYXQgNzo1MCBBTSwgQWxleGFuZGVyIFpp bW1lcm1hbm4gd3JvdGU6DQo+IA0KPj4gMS4gTmVlZHMgYm9pbGVycGxhdGUgdXBkYXRlIChDb3B5 cmlnaHQgc2VjdGlvbikNCj4gDQo+IERvbmUuDQo+PiAyLiBJTUhPIGluIGxpbmUgNTA6ICVzL3Rv IGRvIGFib3V0IFRDUCBvcHRpb25zL3RvIGRvIGFib3V0IElQIGFuZCBUQ1Agb3B0aW9ucy8NCj4g DQo+IERvbmUuDQo+PiAzLiBKdXN0IG9uZSBzZW50ZW5jZSBsYXRlcjogIlJGQy0xMTIyIFtCcmFk ZW44OV0gYXR0ZW1wdGVkIHRvIGNsYXJpZnkgdGhpcyBpbiBzZWN0aW9uIDQuMi4yLjYsIGJ1dA0K Pj4gdGhlcmUgc3RpbGwgc2VlbXMgdG8gYmUgY29uZnVzaW9uLiIgV2hhdCBpcyB0aGUgcHJvYmxl bSBoZXJlIHdpdGggUkZDIDExMjI/IFdoeSBkb2VzIFJGQyAxMTIyDQo+PiBkb2VzIG5vdCBtYW5h Z2UgdG8gY2xhcmlmeSB0aGUgc2l0dWF0aW9uLiBJIHRoaW5rIG9uZSBvciB0d28gc2VudGVuY2Ug bW9yZSBleHBsYW5hdGlvbiB3b3VsZCBiZQ0KPj4gZ3JlYXQuDQo+IEkndmUgcmVtb3ZlZCAiaW4g c2VjdGlvbiA0LjIuMi42IiwgYW5kIHJlcGxhY2VkIGl0IHdpdGggYSByZWZlcmVuY2UgdG8gYSBu ZXcgQXBwZW5kaXggQSB0aGF0DQo+IGhhcyBhIG1vcmUgY29tcGxldGUgZGVzY3JpcHRpb24gb2Yg d2hhdCBpcyBpbiBSRkMgMTEyMi4NCj4gDQo+PiANCj4+IEFsZXgNCj4gDQo+IE9uIEF1ZyAyMCwg MjAwOSwgYXQgMTE6MjggQU0sIEpvZSBUb3VjaCB3cm90ZToNCj4gDQo+IC4uLi4NCj4+IEknZCBs aWtlIHRvIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBmb3IgdGhpcyBkb2M6DQo+PiANCj4+IE1TU3Mg Y2FuIHNvbWV0aW1lcyB2YXJ5LCBhcyB3aGVuIHVzZWQgd2l0aCB2YXJpYWJsZSBjb21wcmVzc2lv biwgZS5nLiwNCj4+IFJPSEMuIFRoZSBST0hDIGRvYyBtaXNzZWQgYW4gb3Bwb3J0dW5pdHkgdG8g YWRkcmVzcyB0aGUgaW50ZXJhY3Rpb24gb2YNCj4+IHZhcmlhYmxlIE1TUyB3aXRoIFRDUCwgYW5k IHRoaXMgbWlnaHQgYmUgYSBnb29kIHBsYWNlIHRvIGluY2x1ZGUgYQ0KPj4gc2VudGVuY2Ugb3Ig dHdvIG9uIGl0LCBlLmcuIChJTU8pOg0KPj4gDQo+PiAtIC0tLQ0KPj4gDQo+PiBNU1NzIGNhbiBz b21ldGltZXMgdmFyeSwgYXMgd2hlbiB1c2VkIHdpdGggdmFyaWFibGUgY29tcHJlc3Npb24sIGUu Zy4sDQo+PiBST0hDIFtSRkM1MjU1XS4gSXQgaXMgdGVtcHRpbmcgZm9yIFRDUCB0byB3YW50IHRv IGFkdmVydGlzZSB0aGUgbGFyZ2VzdA0KPj4gcG9zc2libGUgTVNTLCB0byBzdXBwb3J0IHRoZSBt b3N0IGVmZmljaWVudCB1c2Ugb2YgY29tcHJlc3NlZCBwYXlsb2Fkcy4NCj4+IFVuZm9ydHVuYXRl bHksIHNvbWUgY29tcHJlc3Npb24gc2NoZW1lcyBvY2Nhc2lvbmFsbHkgbmVlZCB0byB0cmFuc21p dA0KPj4gZnVsbCBoZWFkZXJzIChhbmQgdGh1cyBzbWFsbGVyIHBheWxvYWRzKSB0byByZXN5bmNo cm9uaXplIHN0YXRlIGF0IHRoZWlyDQo+PiBlbmRwb2ludCBjb21wcmVzc29yL2RlY29tcHJlc3Nv cnMuIElmIHRoZSBsYXJnZXN0IE1TUyBpcyBhZHZlcnRpc2VkLCBUQ1ANCj4+IHJldHJhbnNtaXNz aW9uIG1heSBpbnRlcmZlcmUgd2l0aCBjb21wcmVzc29yIHJlc3luY2hvbml6YXRpb24uDQo+PiAN Cj4+IEFzIGEgcmVzdWx0LCB3aGVuIGVmZmVjdGl2ZSBNU1MgdmFyaWVzLCBUQ1AgU0hPVUxEIGNv bXB1dGUgaXRzDQo+PiBhZHZlcnRpc2VkIE1TUyBiYXNlZCBvbiB0aGUgc21hbGxlc3QgZWZmZWN0 aXZlIE1TUy4NCj4+IA0KPj4gLSAtLS0NCj4+IA0KPj4gSm9lDQo+IA0KPiBBZGRlZCwgd2l0aCBz b21lIHJld29yZGluZy4NCj4gDQo+IA0KPiBPbiBBdWcgMjAsIDIwMDksIGF0IDEyOjU5IFBNLCA8 TC5Xb29kQHN1cnJleS5hYy51az4gPEwuV29vZEBzdXJyZXkuYWMudWs+IHdyb3RlOg0KPiANCj4+ IENhbid0IFRDUCBNU1MgYWxzbyB2YXJ5IGFjcm9zcyBtdWx0aXBhdGggZW52aXJvbm1lbnRzPyBT dHJpa2VzIG1lDQo+PiB0aGF0IHRoZXNlIGFyZSBtb3JlIGNvbW1vbiB0aGFuIGhlYWRlciBjb21w cmVzc2lvbiAtIHdoaWNoIHNob3VsZA0KPj4gYmUgYWR2ZXJ0aXNpbmcgY29uc2VydmF0aXZlIG1p bmltdW0gTVRVcyBmb3IgdGhlaXIgbGluayBpbnRlcmZhY2VzLg0KPj4gDQo+PiA8aHR0cDovL3d3 dy5lZS5zdXJyZXkuYWMudWsvUGVyc29uYWwvTC5Xb29kLz48TC5Xb29kQHN1cnJleS5hYy51az4N Cj4+IA0KPiANCj4gT2ssIHRoaXMgb25lIEkndmUgZ29uZSByb3VuZCBhbmQgcm91bmQgb24gdGhp cywgaW5jbHVkaW5nIGFkZGluZyBhbiBlbnRpcmUgQXBwZW5kaXggdG8gZGlzY3VzcyBpc3N1ZXMg b2Ygd2hpY2ggTVRVIHZhbHVlIHRvIHVzZSBmb3IgY2FsY3VsYXRpbmcgdGhlIE1TUywgdGhlIGhp c3Rvcnkgb2YgdGhpcywgaXNzdWVzIHdpdGggbXVsdGktaG9tZWQgaG9zdHMsIG5vbi1zeW1ldHJp YyByb3V0ZXMsIGFuZCBtYWtpbmcgbXVsdGlwbGUgcmVjb21tZW5kYXRpb25zLCBiYXNlZCBvbiB0 aGUgY29udGV4dC4gIEluIHRoZSBlbmQgaXQgZmVsdCBsaWtlIGl0IHdhcyBnZXR0aW5nIG91dCBv ZiBjb250cm9sLCBhcyBvbmUgdGhpbmcgbGVhZCB0byBhbm90aGVyIGFuZCB0aGUgQXBwZW5kaXgg d2FzIGdldHRpbmcgcXVpdGUgbGFyZ2UuICBJbiB0aGUgZW5kLCBJIGRlbGV0ZWQgdGhlIEFwcGVu ZGl4LCBhbmQgbm93IGhhdmUganVzdCBvbmUgc2VudGVuY2U6DQo+IA0KPiAJVGhlIGRldGVybWlu YXRpb24gb2Ygd2hhdCBNVFUgdmFsdWUgc2hvdWxkIGJlIHVzZWQsDQo+IAllc3BlY2lhbGx5IGlu IHRoZSBjYXNlIG9mIG11bHRpaG9tZWQgaG9zdHMsIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YNCj4g CXRoaXMgZG9jdW1lbnQuDQo+IA0KPiBUaGlzIGRvY3VtZW50IGlzIGFib3V0IGNsYXJpZnlpbmcg dGhhdCB5b3UgZG9uJ3QgaW5jbHVkZSBJUCBhbmQgVENQIG9wdGlvbnMgd2hlbiBmaWd1cmluZyBv dXQgd2hhdCB0byBwdXQgaW4gdGhlIE1TUyBvcHRpb24sIGl0IGlzIG5vdCBhYm91dCB3aGF0IE1U VSB2YWx1ZSB0byB1c2Ugd2hlbiBjYWxjdWxhdGluZyB0aGUgTVNTIG9wdGlvbiwgc28gaXQgaXMg YmVzdCB0byBqdXN0IG5vdCBnbyBkb3duIHRoYXQgcGF0aCBhdCBhbGwuICBUaGF0J3Mgbm90IHRv IHNheSB0aGF0IHRoaXMgaXNuJ3QgYSB0b3BpYyB0aGF0IGRlc2VydmVzIGRpc2N1c3Npb24sIGJ1 dCB0aGF0IGl0IGlzbid0IHRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBPbiBB dWcgMjYsIDIwMDksIGF0IDY6NTYgQU0sIE1hcmsgQWxsbWFuIHdyb3RlOg0KPiANCj4+IEkgYW0g aW4gZ2VuZXJhbCBpbiBmYXZvciBvZiB0aGlzIGRvY3VtZW50LiAgQnV0LCB0aGlzIGRvY3VtZW50 IGlzIHNvcnRhDQo+PiBjb25mdXNpbmcgdG8gbWUgYW5kIHNvIEknZCB2b3RlICJub3QgcmVhZHki IGF0IHRoZSBtb21lbnQuICANCj4+IA0KPj4gVGhlIHN0YXRlbWVudCB0aGF0IHRoZSBNU1MgYWR2 ZXJ0aXNlbWVudCBzaG91bGQgbm90IGluY2x1ZGUgdGhlIGJ5dGVzDQo+PiBjb25zdW1lZCBieSBv cHRpb25zIGlzIGNsZWFyLCBidXQgaW4gdGhlIGV4cGxhbmF0aW9uIG9mIHRoYXQgcnVsZS4NCj4+ IA0KPj4gKyBJIGhhZCB0byB3b3JrIHRocm91Z2ggdGhlIHRhYmxlIHRvIGZpZ3VyZSBvdXQgImxl bmd0aCIgb24gdGhlIHktYXhpcw0KPj4gICB3YXMgdGhlIG92ZXJhbGwgcGFja2V0IGxlbmd0aC4N Cj4gDQo+IEZpeGVkLg0KPiANCj4+ICsgSSBmaW5kIGl0IHN0cmFuZ2UgdGhhdCB0aGUgdGFibGUg aXMgbGVmdCBhcyB0aGUgc29sZSBqdXN0aWZpY2F0aW9uDQo+PiAgIHdpdGhvdXQgZXZlbiBhIGxp dHRsZSBiaXQgb2YgcHJvc2UgdGhhdCBleHBsYWlucyBpdC4gIEluIGZhY3QsIEkNCj4+ICAgd291 bGQgdGhpbmsgYSBsaXR0bGUgcHJvc2UgaW5zdGVhZCBvZiB0aGUgdGFibGUgd291bGQgbWFrZSB0 aGUgd2hvbGUNCj4+ICAgdGhpbmcgbW9yZSBjbGVhci4NCj4+IA0KPj4gKyBUaGUgb3RoZXIgdGhp bmcgeW91IG1pZ2h0IG5vdGUgaXMgdGhhdCB0aGUgTVNTIGFkdmVydGlzZW1lbnQgY2Fubm90DQo+ PiAgIHBvc3NpYmx5IGNhcHR1cmUgdGhlIHJpZ2h0IG51bWJlciBvZiBvcHRpb24gYnl0ZXMgZm9y IGV2ZXJ5IHBhY2tldA0KPj4gICBpbiBhIGNvbm5lY3Rpb24gYmVjYXVzZSBvcHRpb25zIGFyZSB2 YXJpYWJsZSAoZS5nLiwgU0FDSykuICBTbywgZXZlbg0KPj4gICBpZiBvbmUgdHJpZXMgdG8gY2Fw dHVyZSBvcHRpb24gbGVuZ3RocyBpbiB0aGUgaGVhZGVyIHRoZSBsZW5ndGggd2lsbA0KPj4gICBz dGlsbCBoYXZlIHRvIGJlIGhhY2tlZCBvbiB0aGUgZmx5IChvciwgeW91J2xsIGhhdmUgdG8gdGFr ZSBhDQo+PiAgIHBlc3NpbWFsIHZpZXcgb2Ygb3B0aW9uIHVzYWdlIGFzICJ1c2luZyBhbGwgb2Yg aXQiKS4NCj4gDQo+IEkndmUgYWRkZWQgYSBwYXJhZ3JhcGggdGhhdCBzYXlzIHRoYXQgdGhlIE1T UyB2YWx1ZSwgYmVpbmcgZml4ZWQsIGNhbiBuZXZlciBhY2N1cmF0ZWx5IHJlZmxlY3QgYWxsIHNp dHVhdGlvbnMgb2YgSVAgYW5kIFRDUCBvcHRpb25zLCBiZWNhdXNlIGJ5IHRoZWlyIHZlcnkgbmF0 dXJlIHRoZXkgYXJlIHZhcmlhYmxlLg0KPiANCj4gDQo+IE9uIFNlcCAzLCAyMDA5LCBhdCA3OjM3 IEFNLCBEYW5ueSBNY1BoZXJzb24gd3JvdGU6DQo+IA0KPj4gDQo+PiBJIGFncmVlIHdpdGggTWFy a3MncyBjb21tZW50cyAtIGluIGdlbmVyYWwgSSBsaWtlIHRoZSBkb2N1bWVudA0KPj4gKG15IGNv bGxlYWd1ZSBBYXJvbiBDYW1wYmVsbCBhbmQgSSBhc2tlZCBmb3IgYW5kIG9mZmVyZWQgdG8gd3Jp dGUpDQo+PiBzb21ldGhpbmcgc2ltaWxhciBxdWl0ZSBhIHdoaWxlIGJhY2spLg0KPj4gDQo+PiBJ dCBpcyB3b3J0aCBub3RpbmcgdGhhdCB0aGUgY29uZnVzaW9uIGlzbid0IHVuaXZlcnNhbCwgYXQg bGVhc3QsIHRoZQ0KPj4gTGludXgsIE5ldEJTRCwgYW5kIE9wZW5CU0QgcGVvcGxlIGdvdCBpdCBy aWdodCAob3B0aW9ucyBhcmUgbm90DQo+PiBzdWJ0cmFjdGVkIGZyb20gdGhlIGFkdmVydGlzZWQg TVNTIG9uIHRoZXNlIHN5c3RlbXMgZnJvbSBvdXIgcGFzdA0KPj4gcmVzZWFyY2gpLg0KPj4gDQo+ PiBSRkMyMzg1IGlzIHdyb25nLCB0aG91Z2g6DQo+IC4uLg0KPiBJJ3ZlIGFkZGVkIGEgcmVmZXJl bmNlIHRvIHRoaXMgaXNzdWUsIGFuZCBwb2ludGVkIG91dCB0aGF0IFJGQyAyMzg1IGlzIHdyb25n LiAgSSd2ZSBhbHNvIGFkZGVkIGEgcmVmZXJlbmNlIHRvIHRoZSBpc3N1ZSB3aXRoIFJGQy04OTcs IHdoaWNoIG1vc3RseSBnb3QgdGhlIGRlZmluaXRpb24gY29ycmVjdCB1bnRpbCB0aGUgdmVyeSBs YXN0IHNlY3Rpb24gb2YgdGhlIGRvY3VtZW50Li4uIDotKQ0KPiANCj4gCQkJLURhdmlkDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFp bGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtDQoNCg== From Alexander.Zimmermann@nets.rwth-aachen.de Wed Mar 31 08:10:08 2010 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 0AFB53A6833 for ; Wed, 31 Mar 2010 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 sRshvpg6EcMD for ; Wed, 31 Mar 2010 08:10:06 -0700 (PDT) Received: from mail-i4.informatik.rwth-aachen.de (mail-i4.informatik.RWTH-Aachen.DE [137.226.12.21]) by core3.amsl.com (Postfix) with ESMTP id 4F4EB3A6919 for ; Wed, 31 Mar 2010 08:10:05 -0700 (PDT) Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.informatik.rwth-aachen.de (Postfix) with ESMTP id 4820057AC2; Wed, 31 Mar 2010 17:10:35 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28]) by MESSENGER.nets.rwth-aachen.de ([fe80::d0de:4cb1:8b0f:bd28%14]) with mapi; Wed, 31 Mar 2010 17:10:17 +0200 From: Alexander Zimmermann To: Manqing Huang Thread-Topic: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 Thread-Index: AQHKzR1YCN1w7l2xYUyMH1O2EBvhR5IEsoDggAdaWwA= Date: Wed, 31 Mar 2010 15:10:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6ece53d5-6be1-4181-9fb5-043ed1e86ea0> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 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, 31 Mar 2010 15:10:08 -0000 Hi Manqing, Am 27.03.2010 um 01:39 schrieb Manqing Huang: > Alex, >=20 > Thank you for your comments. >=20 > The congestion issue is easier to be observed in a data center. It was re= ported by one of our customers who is a storage server vendor. The vendor r= an two FTP clients to test the bi-directional traffic between two servers w= hich are connected by a switch. >=20 > To debug this issue, we tried different open source TCP performance test = tools. We found the majority of these tools transmit one-way traffic over e= ach TCP connection when testing bi-directional performance. Yeah, stupid clients. Either you can use a more sophisticated tool like "fl= owgrind" (sorry for the advertisement ;-)) or patch those clients. IMO TCP is not re= sponsible for the daftness of those performance measurement tools or even ftp clients > This fact suggests that existing applications may not utilize the duplex = feature of a TCP connection when they send two-way traffic between two end = points. In the real world, FTP and HTTP without pipelining do either GET or= PUT/POST but not both at the same time. >=20 > Surely I will try to improve the application scenarios in the draft when = more investigation results become available. >=20 > Regards, >=20 > Manqing >=20 > -----Original Message----- > From: Alexander Zimmermann [mailto:Alexander.Zimmermann@nets.rwth-aachen.= de] > Sent: Friday, March 26, 2010 12:49 PM > To: Manqing Huang > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Introducing draft-huang-tcpm-tcp-eack-00 >=20 > Hi, >=20 > I take a quick look at your draft. I really have problems with your appli= cation scenarios. > Do you really think that iperf generates congestion in the internet? > Also the ftp example is seems quite artificial... >=20 > Alex >=20 >=20 > Am 26.03.2010 um 10:48 schrieb Manqing Huang: >=20 >> Hello, >>=20 >> I would like to introduce draft-huang-tcpm-tcp-eack-00 to this group. Th= e purpose of the TCP option proposed in this draft is to improve TCP perfor= mance by reducing the amount of separate ACK packets when there are multipl= e TCP connections and each of the connections carries one way traffic. Appl= ications that can benefit from this option include HTTP and FTP. >>=20 >> Comments are appreciated. >>=20 >> Thank you. >>=20 >> Manqing Huang >>=20 >>=20 >> The information and any attached documents contained in this message >> may be confidential and/or legally privileged. The message is intended >> solely for the addressee(s). If you are not the intended recipient, >> you are hereby notified that any use, dissemination, or reproduction >> is strictly prohibited and may be unlawful. If you are not the >> intended recipient, please contact the sender immediately by return >> e-mail and destroy all copies of the original message. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > The information and any attached documents contained in this message > may be confidential and/or legally privileged. The message is > intended solely for the addressee(s). If you are not the intended > recipient, you are hereby notified that any use, dissemination, or > reproduction is strictly prohibited and may be unlawful. If you are > not the intended recipient, please contact the sender immediately by > return e-mail and destroy all copies of the original message. From wwwrun@core3.amsl.com Wed Mar 31 08:20:14 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0EEFA3A68A9; Wed, 31 Mar 2010 08:20:11 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100331152013.0EEFA3A68A9@core3.amsl.com> Date: Wed, 31 Mar 2010 08:20:12 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Document Action: 'ICMP attacks against TCP' to Informational RFC 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, 31 Mar 2010 15:20:14 -0000 The IESG has approved the following document: - 'ICMP attacks against TCP ' as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-12.txt Technical Summary This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, it describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. Working Group Summary This document was originally proposed for publication on the standards track. The WG did not reach consensus that the IETF should recommend the mitigation techniques documented in this document due to a number of associated drawbacks, although some of the these techniques are widely implemented in popular TCP stacks. There was WG consensus to publish a description of these techniques as an Informational RFC, to document deployed stack behavior. Protocol Quality There are several existing implementations that perform certain activities described in this document. These come from many different vendors and other sources, and some are widely deployed. Personnel Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From rs@netapp.com Wed Mar 31 22:46:43 2010 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 E015A3A6920 for ; Wed, 31 Mar 2010 22:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=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 TWlPLrTsEgdc for ; Wed, 31 Mar 2010 22:46:42 -0700 (PDT) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by core3.amsl.com (Postfix) with ESMTP id 77DFB3A67EC for ; Wed, 31 Mar 2010 22:46:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,346,1267430400"; d="scan'208";a="137790559" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 31 Mar 2010 22:47:11 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (webmail.europe.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o315lBbo018735; Wed, 31 Mar 2010 22:47:11 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 06:47:11 +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: Thu, 1 Apr 2010 06:47:09 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: <201003072316.AAA29042@TR-Sys.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] IANA TCP options registry ... Thread-Index: Acq+TVm5lvjWiOC+S96pFvaCqEQ/ggTENy8w References: <201003072316.AAA29042@TR-Sys.de> From: "Scheffenegger, Richard" To: =?iso-8859-1?Q?Alfred_H=CEnes?= , X-OriginalArrivalTime: 01 Apr 2010 05:47:11.0850 (UTC) FILETIME=[C65B8CA0:01CAD15E] Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 05:46:44 -0000 Hi Alfred et al, Out of curiousity, does anyone know about the to-be assigned option = number(s ?) for RFC 5690 (AckCC http://tools.ietf.org/html/rfc5690). Are there two option numbers proposed for that RFC, or will a single = option (with the length field being the necessary denominator between = AckCC control permitted and AckCC Ratio) suffice? Best regards, =20 Richard Scheffenegger Field Escalation Engineer NetApp Global Support=20 NetApp +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=20 Franz-Klein-Gasse 5 1190 Wien=20 =20 > -----Original Message----- > From: Alfred H=CEnes [mailto:ah@TR-Sys.de]=20 > Sent: Montag, 8. M=E4rz 2010 00:17 > To: huitema@microsoft.com; tcpm@ietf.org > Subject: Re: [tcpm] IANA TCP options registry ... >=20 > [ resending after error correction ... ] >=20 >=20 > Christian, > thanks for the interesting information at the end of your message: >=20 > > The bubba and skeeter options were reserved by Stev Knowles, then=20 > > working at FTP Software. The options are parts of an=20 > encryption system. > > The documentation for that system was not made publicly available. > > According to Stev, the options were actually deployed and used,=20 > > certainly until 2000, and possibly later. >=20 > The latter comes a bit to surprise. > When I sent out my questionaires on TCP options in 2006, I=20 > tried hard to follow all traces of bouncing IANA 'people'=20 > references and emailed many folks. > The most concrete information I could get wrt Skeeter & Bubba=20 > was a 3rd-party statement that Stev Knowles did most likely=20 > not want to be reminded of that misfortune, and, although my=20 > inquiry had been forwarded to him, it was unsure whether he=20 > would want to respond... > ... and so it happened in January 2007. >=20 > The only internet-history posting I had found those days (and=20 > which Google still finds as the only one) was (by one=20 > "co-conspirator"): > r/000071.html> > This does not match very well your alleged report of deployment. >=20 > An interesting document supporting the impression of failure=20 > is the Dissertation of Simson L. Garfinkel (MIT, May 2005),=20 > available at . > Section 6.1 there gives some insight. >=20 > " ... The project was abandoned for two reasons. First, an > engineer at FTP thought that it would be wasteful to have computers > calculate large prime numbers for every TCP connection (none of > those working on the project had any training in=20 > cryptography ... ). > Second, people in the company who understood security=20 > critizised the > solution because it was susceptible to the=20 > man-in-the-middle attack. > Today the Bubba and Skeeter TCP options with the cryptic reference > to "[Knowles]" in the Internet's list of Assigned Numbers=20 > RFCs (e.g., > RFC 1700 [RP94]) are the only remnants of the project. > " >=20 > For more, please see . >=20 > The factual lack of disclosure of information on the design,=20 > until today, seems to support the assumption of failure and=20 > non-deployment. >=20 >=20 > According to my paper notes (would need to go to backups for=20 > more ...), I had mentioned the difficulty to get information=20 > on Skeeter/Bubba, and the pointer to this dissertation, in my=20 > original message in January 2007, but nobody followed up. >=20 >=20 > The basic work in 2006/2007 had been done, among other goals,=20 > to get an overview of whether the idea to include _partial_=20 > TCP option coverage into the proposed successors to the TCP=20 > MD5 option made any sense at all. It turned out that all TCP=20 > options for which I could get information were strictly=20 > end-to-end (as expected) and needed integrity protection. >=20 > When I eventually found the time to compile all results and=20 > posted the "annotated_tcp-parameters.20070216" paper to TCPM,=20 > again no feedback was received. >=20 > Since I now see interest in maintaining more reliable=20 > information, about TCP options, the related documentation,=20 > and their relevance in the current Internet, I will endeavor=20 > to write up the information in an I-D (it will need a few updates). > But due to current private&business time restrictions, please=20 > be patient. >=20 > Any more information would be welcome, in particular on Option #24. > That was the other 'hard stuff' those days. >=20 > For Option #26, I had received enough information from the=20 > registrant, and I hope to not forestall Steve in stating that=20 > the entry in the registry is kept for the historical record=20 > of an academic experiment. >=20 > For Option #18 (Trialer Checksum), it would also be=20 > interesting to get more information on its fate. >=20 >=20 > Some WGs maintain web pages about the related IETF protocols. > One possibility would be to maintain a page on the IETF tools=20 > servers linked to the TCPM WG wiki and/or the WG charter page. >=20 > draft-ogud-iana-maintenance-words should be considered as a=20 > base for adding 'status' information to other IANA registries as well. >=20 >=20 > > > > -----Original Message----- > > From: tcpm-bounces@ietf.org On Behalf Of Fernando Gont > > To: Joe Touch > > Cc: tcpm-chairs@tools.ietf.org; Alfred H=CEnes; tcpm@ietf.org > > Sent: Friday, March 05, 2010 2:51 PM > > Subject: Re: [tcpm] IANA TCP options registry > > > > Hi, Joe, > > > >>> The IANA TCP options registry > >>> (http://www.iana.org/assignments/tcp-parameters/) lacks=20 > of valuable=20 > >>> information. e.g., you need to figure out by yourself=20 > what the "Bubba" > >>> option is (or what it is used for), and missing references (e.g.,=20 > >>> for options #20 through #23 are missing). > >> > >> Some of that information might be solicited found elsewhere, e.g.,=20 > >> internet-history@postel.org ;-) > > > > Yes, but other than that, one should be able to know if the=20 > option was=20 > > ever deployed, whether it's obsolete, etc. > > > > e.g., if I wanted to design a firewall policy, I might need that=20 > > information. > > > > > >>> What'd be the procedure to have Alfred's registry replace the=20 > >>> current one? (i.e., have most/all of the information=20 > there make it=20 > >>> into the "official" IANA registry). > >> > >> Ask IANA (iana@iana.org). I don't think this really requires any=20 > >> particular policy stuff - some of that info isn't there because it=20 > >> just wasn't known when the page was created. > > > > Ok. I've just e-mailed them. Let's see what happens. >=20 > Early in 2007, IANA received a request to update references. > In 2008, I received a (kinda broadcast) message that they had=20 > lost record of many requests, and the recipients should=20 > please submit their requests again. That wasn't very=20 > encouraging, and after already having spent a lot of time=20 > before (in vain) for getting other registries fixed that=20 > contain(ed) material obviously contradicting the referenced=20 > RFCs, I didn't. :-) >=20 > > > > Thanks! > > > > Kind regards, > > -- > > Fernando Gont >=20 >=20 > Kind regards, > Alfred H=CEnes. >=20 > --=20 >=20 > +------------------------+------------------------------------ > --------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math.,=20 > Dipl.-Phys. | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18=20 > | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de =20 > | > +------------------------+------------------------------------ > --------+ >=20 > P.S.: > I'd appreciate if the DNS servers in Redmont would stop to > blackhole DNS queries from the random source port numbers (!=3D53) > that our NAT/Firewall access router inserts in (query) packets > originating on our local recursive DNS resolver, so that messages > could be delivered using normal, DNS-based mail routing. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 From lars.eggert@nokia.com Wed Mar 31 23:26:03 2010 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 276313A6950 for ; Wed, 31 Mar 2010 23:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.936 X-Spam-Level: X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6, 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 rwq86DFtefPm for ; Wed, 31 Mar 2010 23:26:01 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9DF1D3A6885 for ; Wed, 31 Mar 2010 23:26:01 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o316QNgX000728; Thu, 1 Apr 2010 01:26:32 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:26:30 +0300 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:26:30 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o316QRFR001701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 09:26:27 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-74--261799666; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> Date: Thu, 1 Apr 2010 09:26:16 +0300 Message-Id: <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com> References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.1078) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 09:26:17 +0300 (EEST) X-OriginalArrivalTime: 01 Apr 2010 06:26:30.0308 (UTC) FILETIME=[441BAE40:01CAD164] X-Nokia-AV: Clean Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , "tcpm@ietf.org" Subject: Re: [tcpm] IANA TCP options registry ... 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, 01 Apr 2010 06:26:03 -0000 --Apple-Mail-74--261799666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-4-1, at 8:47, Scheffenegger, Richard wrote: > Out of curiousity, does anyone know about the to-be assigned option = number(s ?) for RFC 5690 (AckCChttp://tools.ietf.org/html/rfc5690). >=20 > Are there two option numbers proposed for that RFC, or will a single = option (with the length field being the necessary denominator between = AckCC control permitted and AckCC Ratio) suffice? Section 10 is pretty clear, in that RFC5690 is for limited = experimentation only at this time and hence no separate option numbers = will be assigned. Experimenters are supposed to use the normal TCP = option numbers set aside for general experimentation (253/254) when = playing with this proposal: No IANA action is needed at this time. If this document was advanced as Experimental or Proposed Standard, then IANA would allocate the option numbers for the two TCP options, the ACK Congestion Control Permitted option, and the ACK Ratio option. In such a case, the following two lines would be added to the TCP Option Numbers registry (maintained by IANA -- http://www.iana.org): Kind Length Meaning Reference ---- ------ --------------------------------- ----------- TBD1 2 ACK Congestion Control Permitted [RFCXXXX] TBD2 3 ACK Ratio [RFCXXXX] In the absence of TCP option numbers allocated by IANA, experimenters may use the TCP Option Numbers set aside for Experimentation in RFC 4727 [RFC4727]. As stressed in Section 1 of RFC 3692 [RFC3692], the TCP Option Numbers in the experimental range are intended for experimentation and testing and not for wide or general deployments; these option numbers could be in use by other experimentors for other purposes. Lars= --Apple-Mail-74--261799666 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDQwMTA2MjYxNlowIwYJKoZIhvcNAQkEMRYEFLtQ3M0MT6RVx5BVrSFQmNTcgVJkMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCORziVbTQubprm38a207O7cgfpbbtOgNefiWG0SG9doN9NSotr+pwsqZmhVDIZhapMNKQ9 PiyrrTMsvUiOiYzRoedzTtZMcNQCcNQmvn3qmnVe4AW+MflCevB5R2uwvhs2Y+nXyLXcPR3uyi1+ hB+bbbrLATMQ1IsFvh2xOGyhXG6SWKHqcuKAdYkdtHpdSO40tHAJRi/cY3+b0B+0MO98wCMZ8z6y lz7cnkP3G53J2hMijh1Us5Q8rQNxOxUlYI58RQLrumJiRlbVin/q+uuauVqe6gRFfVv35XkpD2Wc EVHb1CqpkX/rHN54Uc6SHYW9MddVJfzUgC6kzwwRGlWTAAAAAAAA --Apple-Mail-74--261799666--