From nishida@sfc.wide.ad.jp Wed May 2 03:51:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED121F8AD2 for ; Wed, 2 May 2012 03:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YQIIEFVXMGa for ; Wed, 2 May 2012 03:51:28 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECE21F870E for ; Wed, 2 May 2012 03:51:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4BA412781BC for ; Wed, 2 May 2012 19:51:24 +0900 (JST) Received: by lbbgo11 with SMTP id go11so376546lbb.31 for ; Wed, 02 May 2012 03:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.144.101 with SMTP id sl5mr20197309lab.51.1335955881865; Wed, 02 May 2012 03:51:21 -0700 (PDT) Received: by 10.112.58.138 with HTTP; Wed, 2 May 2012 03:51:21 -0700 (PDT) Date: Wed, 2 May 2012 03:51:21 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org\"" Content-Type: multipart/alternative; boundary=e89a8f235261c6303a04bf0b77bd Subject: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 10:51:29 -0000 --e89a8f235261c6303a04bf0b77bd Content-Type: text/plain; charset=ISO-8859-1 Hello, Michael, Pasi and I have checked the reported errata on RFC793 and the below is the list of our current dispositions. We've classified the errata based on the guideline in http://www.ietf.org/iesg/statement/errata-processing.html Please let us know if you have comments on these. o http://www.rfc-editor.org/errata_search.php?eid=1567 Status: Held for Document Update Type: Technical Technical clarification proposal on data on SYN segment. According to the errata, there is some ambiguity in RFC 793 regarding data in SYNs. This might require changes beyond the suggested errata text, and thus we believe this issue should be held for a document update or a separate RFC on data in SYNs. o http://www.rfc-editor.org/errata_search.php?eid=1568 Status: Rejected Type: Technical Technical and editorial modification proposals on received packet inspection sequence. This errata combines several different suggestions. Some of them repeat updates of RFC 1122, some are subtle minor hints, and in some cases the errata does not propose better phrasing. The errata cannot be accepted in this form. It might be worth to consider individual aspects separately. o http://www.rfc-editor.org/errata_search.php?eid=1569 Status: Held for Document Update Type: Editorial Small editorial clarification proposal. But, we believe the original texts are clear enough. o http://www.rfc-editor.org/errata_search.php?eid=1570 Status: Rejected Type: Editorial An editorial modification proposal that changes the meaning of the text (plural to singular). We believe that the original text is not confusing and a change of the meaning is not required. o http://www.rfc-editor.org/errata_search.php?eid=1571 Status: Held for Document Update Type: Technical Technical clarification proposals on sending MSS option with SYN. We believe that there is not much ambiguity in RFC 793 and RFC 1122 with regard to this point, and thus an errata is not required. Regards, -- Yoshifumi --e89a8f235261c6303a04bf0b77bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Michael, Pasi and I have checked the reported errata on RFC79= 3 and the below is the list of our current dispositions.
We've class= ified the errata based on the guideline in http://www.ietf.org/iesg/statement/er= rata-processing.html
Please let us know if you have comments on these.


o http://www.rfc-edito= r.org/errata_search.php?eid=3D1567

=A0=A0 Status: Held for Docum= ent Update
=A0=A0 Type: Technical

=A0=A0 Technical clarification proposal on da= ta on SYN segment.
=A0=A0 According to the errata, there is some ambigui= ty in RFC 793 regarding data in SYNs.
=A0=A0 This might require changes = beyond the suggested errata text, and thus we believe
=A0=A0 this issue should be held for a document update or a separate RFC on= data in SYNs.


o http://www.rfc-editor.org/errata_search.php?eid=3D1568<= /a>

=A0=A0 Status: Rejected
=A0=A0 Type: Technical

=A0=A0 Technic= al and editorial modification proposals on received packet inspection seque= nce.
=A0=A0 This errata combines several different suggestions. Some of = them repeat updates of RFC 1122,
=A0=A0 some are subtle minor hints, and in some cases the errata does not p= ropose better phrasing.
=A0=A0 The errata cannot be accepted in this for= m. It might be worth to consider individual aspects
=A0=A0 separately.

o http:/= /www.rfc-editor.org/errata_search.php?eid=3D1569

=A0=A0 Status: = Held for Document Update
=A0=A0 Type: Editorial

=A0=A0 Small edit= orial clarification proposal. But, we believe the original texts are clear = enough.


o http://www.rfc-editor.org/errata_search.php?eid=3D1570

=A0=A0 = Status: Rejected
=A0=A0 Type: Editorial

=A0=A0 An editorial modif= ication proposal that changes the meaning of the text (plural to singular).=
=A0=A0 We believe that the original text is not confusing and a change of t= he meaning is not required.


o http://www.rfc-editor.org/errata_search.ph= p?eid=3D1571

=A0=A0 Status: Held for Document Update
=A0=A0 Type: Technical
=A0=A0 Technical clarification proposals on sending MSS option with SYN.<= br>=A0=A0 We believe that there is not much ambiguity in RFC 793 and RFC 11= 22 with regard to
=A0=A0 this point, and thus an errata is not required.


Regards,<= br>--
Yoshifumi
--e89a8f235261c6303a04bf0b77bd-- From nishida@sfc.wide.ad.jp Wed May 2 12:53:49 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B743521E80C6 for ; Wed, 2 May 2012 12:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUyN3mExaCG3 for ; Wed, 2 May 2012 12:53:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by ietfa.amsl.com (Postfix) with ESMTP id D770A21E80BE for ; Wed, 2 May 2012 12:53:48 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 6F6A029C012 for ; Thu, 3 May 2012 04:53:45 +0900 (JST) Received: by lagj5 with SMTP id j5so850025lag.31 for ; Wed, 02 May 2012 12:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.115.74 with SMTP id jm10mr21513271lab.32.1335988422873; Wed, 02 May 2012 12:53:42 -0700 (PDT) Received: by 10.112.91.143 with HTTP; Wed, 2 May 2012 12:53:42 -0700 (PDT) In-Reply-To: <4FA1726B.9040500@isi.edu> References: <4FA1726B.9040500@isi.edu> Date: Wed, 2 May 2012 12:53:42 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=f46d040891555e923204bf130b32 Cc: "tcpm@ietf.org\"" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 19:53:49 -0000 --f46d040891555e923204bf130b32 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Thanks for the comments. I think you are quite right if producing new RFCs is our consensus. But, I'm wondering rejecting by just potential needs is proper approach. -- Yoshifumi On Wed, May 2, 2012 at 10:44 AM, Joe Touch wrote: > Hi, all, > > I'm not clear on the categories. "Rejected" means the erratum is > incorrect. "Hold for document update" allows further scrutiny of the > erratum, but appears to imply (IMO) some potential validity. > > My read of "Rejected" is more appropriate for the two errata indicated > below - esp. given the indicated need for new RFCs on the specific issues. > > Joe > > > On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote: > >> Hello, >> >> Michael, Pasi and I have checked the reported errata on RFC793 and the >> below is the list of our current dispositions. >> We've classified the errata based on the guideline in >> http://www.ietf.org/iesg/**statement/errata-processing.**html >> Please let us know if you have comments on these. >> >> >> o http://www.rfc-editor.org/**errata_search.php?eid=1567 >> >> Status: Held for Document Update >> Type: Technical >> >> Technical clarification proposal on data on SYN segment. >> According to the errata, there is some ambiguity in RFC 793 >> regarding data in SYNs. >> This might require changes beyond the suggested errata text, and >> thus we believe >> this issue should be held for a document update or a separate RFC on >> data in SYNs. >> > ... > > > o http://www.rfc-editor.org/**errata_search.php?eid=1571 >> >> Status: Held for Document Update >> Type: Technical >> >> Technical clarification proposals on sending MSS option with SYN. >> We believe that there is not much ambiguity in RFC 793 and RFC 1122 >> with regard to >> this point, and thus an errata is not required. >> > > > > --f46d040891555e923204bf130b32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joe,

Thanks for the comments. I think you are quite right if pro= ducing new RFCs is our consensus.
But, I'm wondering rejecting by ju= st potential needs is proper approach.

--
Yoshifumi

On Wed, May 2, 2012 at 10:44 AM, Joe Touch <touch@isi.edu> wrote= :
Hi, all,

I'm not clear on the categories. "Rejected" means the erratum= is incorrect. "Hold for document update" allows further scrutiny= of the erratum, but appears to imply (IMO) some potential validity.

My read of "Rejected" is more appropriate for the two errata indi= cated below - esp. given the indicated need for new RFCs on the specific is= sues.

Joe


On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote:
Hello,

Michael, Pasi and I have checked the reported errata on RFC793 and the
below is the list of our current dispositions.
We've classified the errata based on the guideline in
http://www.ietf.org/iesg/statement/errata-processing.html
Please let us know if you have comments on these.


o http://www.rfc-editor.org/errata_search.php?eid=3D1567

=A0 =A0Status: Held for Document Update
=A0 =A0Type: Technical

=A0 =A0Technical clarification proposal on data on SYN segment.
=A0 =A0According to the errata, there is some ambiguity in RFC 793
regarding data in SYNs.
=A0 =A0This might require changes beyond the suggested errata text, and thus we believe
=A0 =A0this issue should be held for a document update or a separate RFC o= n
data in SYNs.
...


o http://www.rfc-editor.org/errata_search.php?eid=3D1571

=A0 =A0Status: Held for Document Update
=A0 =A0Type: Technical

=A0 =A0Technical clarification proposals on sending MSS option with SYN. =A0 =A0We believe that there is not much ambiguity in RFC 793 and RFC 1122=
with regard to
=A0 =A0this point, and thus an errata is not required.




--f46d040891555e923204bf130b32-- From touch@isi.edu Wed May 2 13:53:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF1011E80B2 for ; Wed, 2 May 2012 13:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbKB0zkphB1Q for ; Wed, 2 May 2012 13:53:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5102E11E8080 for ; Wed, 2 May 2012 13:53:40 -0700 (PDT) Received: from [207.151.142.82] ([207.151.142.82]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q42KrKDQ014525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2012 13:53:30 -0700 (PDT) Message-ID: <4FA19EBF.4090309@isi.edu> Date: Wed, 02 May 2012 13:53:19 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: <4FA1726B.9040500@isi.edu> In-Reply-To: <4FA1726B.9040500@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 20:53:41 -0000 Hi, all, I'm not clear on the categories. "Rejected" means the erratum is incorrect. "Hold for document update" allows further scrutiny of the erratum, but appears to imply (IMO) some potential validity. My read of "Rejected" is more appropriate for the two errata indicated below - esp. given the indicated need for new RFCs on the specific issues. Joe On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote: > Hello, > > Michael, Pasi and I have checked the reported errata on RFC793 and the > below is the list of our current dispositions. > We've classified the errata based on the guideline in > http://www.ietf.org/iesg/statement/errata-processing.html > Please let us know if you have comments on these. > > > o http://www.rfc-editor.org/errata_search.php?eid=1567 > > Status: Held for Document Update > Type: Technical > > Technical clarification proposal on data on SYN segment. > According to the errata, there is some ambiguity in RFC 793 > regarding data in SYNs. > This might require changes beyond the suggested errata text, and > thus we believe > this issue should be held for a document update or a separate RFC on > data in SYNs. ... > o http://www.rfc-editor.org/errata_search.php?eid=1571 > > Status: Held for Document Update > Type: Technical > > Technical clarification proposals on sending MSS option with SYN. > We believe that there is not much ambiguity in RFC 793 and RFC 1122 > with regard to > this point, and thus an errata is not required. --- From touch@isi.edu Wed May 2 13:54:38 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B7611E80B2 for ; Wed, 2 May 2012 13:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbDCKljuLmVF for ; Wed, 2 May 2012 13:54:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE211E8080 for ; Wed, 2 May 2012 13:54:37 -0700 (PDT) Received: from [207.151.142.82] ([207.151.142.82]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q42KsEmU014806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2012 13:54:27 -0700 (PDT) Message-ID: <4FA19EF5.2050203@isi.edu> Date: Wed, 02 May 2012 13:54:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: <4FA1726B.9040500@isi.edu> <4FA195F6.7080507@isi.edu> In-Reply-To: <4FA195F6.7080507@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 20:54:38 -0000 Hi, Yoshifumi, On 5/2/2012 12:53 PM, Yoshifumi Nishida wrote: > Hi Joe, > > Thanks for the comments. I think you are quite right if producing new > RFCs is our consensus. > But, I'm wondering rejecting by just potential needs is proper approach. The process is a bit unclear on this. AFAICT, it seems to indicate that items are "hold for document update" when that's the intended outcome - a document update. Since that's unlikely - esp. for the items found - putting things in that category doesn't seem useful. Errata should not be a cache for pending TCP clarifications that are intended for separate docs, IMO. Joe From michael.scharf@alcatel-lucent.com Wed May 2 14:21:40 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BAD11E809A for ; Wed, 2 May 2012 14:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.476 X-Spam-Level: X-Spam-Status: No, score=-7.476 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dydAKM1tS7d for ; Wed, 2 May 2012 14:21:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1611E808F for ; Wed, 2 May 2012 14:21:38 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q42LLYUd021189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 May 2012 23:21:37 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 2 May 2012 23:21:36 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch Date: Wed, 2 May 2012 23:21:34 +0200 Thread-Topic: [tcpm] errata on RFC793 Thread-Index: Ac0opfKotgvmTKwCRGSsUzBNIlu9mgAAM16w Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A1F4ED9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <4FA1726B.9040500@isi.edu> <4FA195F6.7080507@isi.edu> <4FA19EF5.2050203@isi.edu> In-Reply-To: <4FA19EF5.2050203@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 21:21:40 -0000 Joe,=20 > Hi, Yoshifumi, >=20 > On 5/2/2012 12:53 PM, Yoshifumi Nishida wrote: > > Hi Joe, > > > > Thanks for the comments. I think you are quite right if=20 > producing new=20 > > RFCs is our consensus. > > But, I'm wondering rejecting by just potential needs is=20 > proper approach. >=20 > The process is a bit unclear on this. AFAICT, it seems to=20 > indicate that items are "hold for document update" when=20 > that's the intended outcome - a document update. > > Since that's unlikely - esp. for the items found - putting=20 > things in that category doesn't seem useful. Errata should=20 > not be a cache for pending TCP clarifications that are=20 > intended for separate docs, IMO. It would be important to get technical feedback on whether the erratas are = really invalid. If an errata addresses a valid issue, even if it is minor, = rejecting it might not be very useful neither. The chairs had some discussion most notably regarding the advancement of SN= D.NXT in the first errata (http://www.rfc-editor.org/errata_search.php?eid= =3D1567), and we'd be interested in additional insight on that. My personal= understanding right now is that RFC 793 has not fully specified that case.= But feel free to correct me - I might be wrong. Michael= From touch@isi.edu Thu May 3 06:50:44 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D3F21F84D5 for ; Thu, 3 May 2012 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.107 X-Spam-Level: X-Spam-Status: No, score=-104.107 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHHR7KALhLpO for ; Thu, 3 May 2012 06:50:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 82F8E21F84DC for ; Thu, 3 May 2012 06:50:43 -0700 (PDT) Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q43DnBRh028186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2012 06:49:20 -0700 (PDT) Message-ID: <4FA28CD7.3090300@isi.edu> Date: Thu, 03 May 2012 06:49:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" References: <4FA1726B.9040500@isi.edu> <4FA195F6.7080507@isi.edu> <4FA19EF5.2050203@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E891A1F4ED9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E891A1F4ED9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 13:50:44 -0000 Hi, Michael (et al.), On 5/2/2012 2:21 PM, Scharf, Michael (Michael) wrote: > Joe, > >> Hi, Yoshifumi, >> >> On 5/2/2012 12:53 PM, Yoshifumi Nishida wrote: >>> Hi Joe, >>> >>> Thanks for the comments. I think you are quite right if >> producing new >>> RFCs is our consensus. >>> But, I'm wondering rejecting by just potential needs is >> proper approach. >> >> The process is a bit unclear on this. AFAICT, it seems to >> indicate that items are "hold for document update" when >> that's the intended outcome - a document update. >> >> Since that's unlikely - esp. for the items found - putting >> things in that category doesn't seem useful. Errata should >> not be a cache for pending TCP clarifications that are >> intended for separate docs, IMO. > > It would be important to get technical feedback on whether the > erratasare really invalid. If an errata addresses a valid issue, > even if it is minor, rejecting it might not be very useful neither. The errata instructions here: http://www.rfc-editor.org/status_type_desc.html say that: Held for Document Update "The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update." - IESG statement on "IESG Processing of RFC Errata for the IETF Stream" Rejected "The erratum is in error, or proposes a change to the RFC that should be done by publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list." - IESG statement on "IESG Processing of RFC Errata for the IETF Stream" I think the SYN DATA issue and the other clearly falls into "Rejected" by these metrics. It's not merely a claim that the erratum is in error. Given a second consideration, the MSS issue is probably a "Held for Doc Update" as originally proposed, though. > The chairs had some discussion most notably regarding the > advancementof SND.NXT in the first errata > (http://www.rfc-editor.org/errata_search.php?eid=1567), and we'd be > interested in additional insight on that. My personal understanding > right now is that RFC 793 has not fully specified that case. But feel > free to correct me - I might be wrong. The error applies to more than the erratum notes. I.e., the same omission happens during the OPEN call processing during a LISTEN state: OPEN Call ... LISTEN STATE If active and the foreign socket is specified, then change the connection from passive to active, select an ISS. Send a SYN segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data associated with SEND may be sent with SYN segment or queued for transmission after entering ESTABLISHED state. The ^ [missing the update of SND.NXT] urgent bit if requested in the command must be sent with the data segments sent as a result of this command. If there is no room to queue the request, respond with "error: insufficient resources". If Foreign socket was not specified, then return "error: foreign socket unspecified". again on page 68: If SND.UNA > ISS (our SYN has been ACKed), change the connection state to ESTABLISHED, form an ACK segment and send it. Data or controls which were queued for ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ transmission may be included. If there are other controls or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [missing all details of this step] text in the segment then continue processing at the sixth step below where the URG bit is checked, otherwise return. In both of these additional cases, the details are omitted. Joe From wes@mti-systems.com Thu May 3 08:05:06 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629B221F8680 for ; Thu, 3 May 2012 08:05:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVhyRxZt1AXU for ; Thu, 3 May 2012 08:05:02 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8F95421F8683 for ; Thu, 3 May 2012 08:05:02 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q43F518x000992 for ; Thu, 3 May 2012 11:05:01 -0400 Authentication-Results: cm-omr8 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [68.246.15.133] ([68.246.15.133:5272] helo=[192.168.43.65]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F6/E7-01735-C9E92AF4; Thu, 03 May 2012 11:05:01 -0400 Message-ID: <4FA29E87.7040707@mti-systems.com> Date: Thu, 03 May 2012 11:04:39 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joe Touch References: <4FA1726B.9040500@isi.edu> <4FA195F6.7080507@isi.edu> <4FA19EF5.2050203@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E891A1F4ED9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <4FA28CD7.3090300@isi.edu> In-Reply-To: <4FA28CD7.3090300@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 15:05:06 -0000 On 5/3/2012 9:49 AM, Joe Touch wrote: > I think the SYN DATA issue and the other clearly falls into "Rejected" > by these metrics. It's not merely a claim that the erratum is in error. > > Given a second consideration, the MSS issue is probably a "Held for Doc > Update" as originally proposed, though. These look like the correct directions to take to me, and I am able to update the notes to indicate the reasoning discussed here behind the way we selected how to deal with them. -- Wes Eddy MTI Systems From touch@isi.edu Wed May 2 10:44:43 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCF011E8086 for ; Wed, 2 May 2012 10:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.594 X-Spam-Level: X-Spam-Status: No, score=-103.594 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxRn684o6J76 for ; Wed, 2 May 2012 10:44:42 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4511E8081 for ; Wed, 2 May 2012 10:44:42 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q42HiBeR002090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2012 10:44:11 -0700 (PDT) Message-ID: <4FA1726B.9040500@isi.edu> Date: Wed, 02 May 2012 10:44:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 03 May 2012 08:45:54 -0700 Cc: " " "@isi.edu Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 17:44:43 -0000 Hi, all, I'm not clear on the categories. "Rejected" means the erratum is incorrect. "Hold for document update" allows further scrutiny of the erratum, but appears to imply (IMO) some potential validity. My read of "Rejected" is more appropriate for the two errata indicated below - esp. given the indicated need for new RFCs on the specific issues. Joe On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote: > Hello, > > Michael, Pasi and I have checked the reported errata on RFC793 and the > below is the list of our current dispositions. > We've classified the errata based on the guideline in > http://www.ietf.org/iesg/statement/errata-processing.html > Please let us know if you have comments on these. > > > o http://www.rfc-editor.org/errata_search.php?eid=1567 > > Status: Held for Document Update > Type: Technical > > Technical clarification proposal on data on SYN segment. > According to the errata, there is some ambiguity in RFC 793 > regarding data in SYNs. > This might require changes beyond the suggested errata text, and > thus we believe > this issue should be held for a document update or a separate RFC on > data in SYNs. ... > o http://www.rfc-editor.org/errata_search.php?eid=1571 > > Status: Held for Document Update > Type: Technical > > Technical clarification proposals on sending MSS option with SYN. > We believe that there is not much ambiguity in RFC 793 and RFC 1122 > with regard to > this point, and thus an errata is not required. From touch@isi.edu Wed May 2 13:16:40 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30A021E80E7 for ; Wed, 2 May 2012 13:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhpX4j-aZMcA for ; Wed, 2 May 2012 13:16:40 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5555F21E80F7 for ; Wed, 2 May 2012 13:16:40 -0700 (PDT) Received: from [207.151.142.82] ([207.151.142.82]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q42KFpWX008424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 May 2012 13:16:04 -0700 (PDT) Message-ID: <4FA195F6.7080507@isi.edu> Date: Wed, 02 May 2012 13:15:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yoshifumi Nishida References: <4FA1726B.9040500@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 03 May 2012 08:45:54 -0700 Cc: " " "@isi.edu Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2012 20:16:40 -0000 Hi, Yoshifumi, On 5/2/2012 12:53 PM, Yoshifumi Nishida wrote: > Hi Joe, > > Thanks for the comments. I think you are quite right if producing new > RFCs is our consensus. > But, I'm wondering rejecting by just potential needs is proper approach. The process is a bit unclear on this. AFAICT, it seems to indicate that items are "hold for document update" when that's the intended outcome - a document update. Since that's unlikely - esp. for the items found - putting things in that category doesn't seem useful. Errata should not be a cache for pending TCP clarifications that are intended for separate docs, IMO. Joe > > -- > Yoshifumi > > On Wed, May 2, 2012 at 10:44 AM, Joe Touch > wrote: > > Hi, all, > > I'm not clear on the categories. "Rejected" means the erratum is > incorrect. "Hold for document update" allows further scrutiny of the > erratum, but appears to imply (IMO) some potential validity. > > My read of "Rejected" is more appropriate for the two errata > indicated below - esp. given the indicated need for new RFCs on the > specific issues. > > Joe > > > On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote: > > Hello, > > Michael, Pasi and I have checked the reported errata on RFC793 > and the > below is the list of our current dispositions. > We've classified the errata based on the guideline in > http://www.ietf.org/iesg/__statement/errata-processing.__html > > Please let us know if you have comments on these. > > > o http://www.rfc-editor.org/__errata_search.php?eid=1567 > > > Status: Held for Document Update > Type: Technical > > Technical clarification proposal on data on SYN segment. > According to the errata, there is some ambiguity in RFC 793 > regarding data in SYNs. > This might require changes beyond the suggested errata text, and > thus we believe > this issue should be held for a document update or a > separate RFC on > data in SYNs. > > ... > > > o http://www.rfc-editor.org/__errata_search.php?eid=1571 > > > Status: Held for Document Update > Type: Technical > > Technical clarification proposals on sending MSS option with > SYN. > We believe that there is not much ambiguity in RFC 793 and > RFC 1122 > with regard to > this point, and thus an errata is not required. > > > > > From michael.scharf@alcatel-lucent.com Thu May 3 13:17:09 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2B21F864F for ; Thu, 3 May 2012 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.19 X-Spam-Level: X-Spam-Status: No, score=-8.19 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, SARE_URGBIZ=0.725, URG_BIZ=1.585] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBysKjCYo3A6 for ; Thu, 3 May 2012 13:17:09 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5F21F861D for ; Thu, 3 May 2012 13:17:08 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q43KH5He021765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 May 2012 22:17:06 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.56]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 3 May 2012 22:17:05 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch Date: Thu, 3 May 2012 22:17:01 +0200 Thread-Topic: [tcpm] errata on RFC793 Thread-Index: Ac0pM6Rwpvh/owirSXacL0ZcUitV3QANHXHw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A1F4F0D@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <4FA1726B.9040500@isi.edu> <4FA195F6.7080507@isi.edu> <4FA19EF5.2050203@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E891A1F4ED9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <4FA28CD7.3090300@isi.edu> In-Reply-To: <4FA28CD7.3090300@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] errata on RFC793 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 03 May 2012 20:17:10 -0000 Joe,=20 > Given a second consideration, the MSS issue is probably a=20 > "Held for Doc Update" as originally proposed, though. Fine > > The chairs had some discussion most notably regarding the=20 > > advancementof SND.NXT in the first errata=20 > > (http://www.rfc-editor.org/errata_search.php?eid=3D1567), and we'd be=20 > > interested in additional insight on that. My personal understanding=20 > > right now is that RFC 793 has not fully specified that=20 > case. But feel=20 > > free to correct me - I might be wrong. >=20 > The error applies to more than the erratum notes. >=20 > I.e., the same omission happens during the OPEN call=20 > processing during a LISTEN state: >=20 > OPEN Call > ... > LISTEN STATE >=20 > If active and the foreign socket is specified, then change the > connection from passive to active, select an ISS. Send a SYN > segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT > state. Data associated with SEND may be sent with SYN=20 > segment or > queued for transmission after entering ESTABLISHED state. The > =20 > ^ [missing the update of SND.NXT] > urgent bit if requested in the command must be sent=20 > with the data > segments sent as a result of this command. If there=20 > is no room to > queue the request, respond with "error: insufficient=20 > resources". > If Foreign socket was not specified, then return=20 > "error: foreign > socket unspecified". >=20 > again on page 68: >=20 > If SND.UNA > ISS (our SYN has been ACKed), change=20 > the connection > state to ESTABLISHED, form an ACK segment >=20 > >=20 > and send it. Data or controls which were queued for > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > transmission may be included. If there are other controls or > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [missing all details of this step] > text in the segment then continue processing at the=20 > sixth step > below where the URG bit is checked, otherwise return. >=20 >=20 > In both of these additional cases, the details are omitted. Fixing this would apparently need an RFC. In that sense it might be fine to= reject the errata as it is. Thanks Michael PS: Sorry, I apparently made an error when approving some stale e-mails tha= t got queued in mailman. From gettysjim@gmail.com Tue May 8 05:15:58 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D757B21F8473 for ; Tue, 8 May 2012 05:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsv6MEWWTQ71 for ; Tue, 8 May 2012 05:15:58 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3CA721F8470 for ; Tue, 8 May 2012 05:15:56 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1673062qcs.31 for ; Tue, 08 May 2012 05:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=8kuyapO9xq7TG156Yr0XJY/VD4oRtqWGXc2uFp7iAPw=; b=H1/MvZvOah71uvmsRQcUfpouK9eg6BF4l1V4+LlSDi1dCwYlWr4h8P2VgD/4edzSQF jqiA8FxKKxNh/CCjgx178ExEhn+ae23PSJ4GUmuBo3gVYEjqfHuNjBNKvOfAZ/FuB2Tc s6dAi5OncrXH+FMHj/LBY4SEy3+aeaZnTSkHj8jPfeMpMROtVdMvASIDxQlz0h2WIC8R yax4QoakqSP+7y3HKro9+tn50bLbhPcWlklPOzv5yrnoOHvdq0UHXGoe5TQYyO5q63aS ZFtidqar2MReRUOJGsRmZohNb4RlagHoOb4nlKvv02X/UeIYyodKunRGWjJRzuQyG7vr 6sXw== Received: by 10.224.190.68 with SMTP id dh4mr30963472qab.5.1336479356194; Tue, 08 May 2012 05:15:56 -0700 (PDT) Received: from [192.168.1.81] (c-50-138-162-108.hsd1.ma.comcast.net. [50.138.162.108]) by mx.google.com with ESMTPS id hs1sm3544273qab.21.2012.05.08.05.15.54 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 05:15:55 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FA90E7A.5020203@freedesktop.org> Date: Tue, 08 May 2012 08:15:54 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "'tcpm@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tcpm] "Controlling Queue Delay" published. X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2012 12:15:59 -0000 Kathie Nichols and Van Jacobson published a new adaptive AQM algorithm today, which, we think, provides the missing piece to solve bufferbloat (rather than just mitigate the problem). See: http://queue.acm.org/detail.cfm?id=2209336 I wrote a blog article to set a bit more context for a more general audience than tcpm at: http://gettys.wordpress.com/2012/05/08/fundamental-progress-solving-bufferbloat/ Patches for Linux are available. - Jim From michael.scharf@alcatel-lucent.com Wed May 9 04:28:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDFC21F8528; Wed, 9 May 2012 04:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.411 X-Spam-Level: X-Spam-Status: No, score=-7.411 tagged_above=-999 required=5 tests=[AWL=-1.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sys7qMc-SHaO; Wed, 9 May 2012 04:28:23 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6F21F8523; Wed, 9 May 2012 04:28:22 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q49BQRLx019326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 May 2012 13:28:17 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 May 2012 13:28:09 +0200 From: "Scharf, Michael (Michael)" To: "iesg-secretary@ietf.org" , Wesley Eddy Date: Wed, 9 May 2012 13:28:07 +0200 Thread-Topic: Publication request for draft-ietf-tcpm-tcpmss-04 Thread-Index: Ac0t1s5nzWVVdP7lTBeZzFp14LiDDg== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB0C9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "tcpm@ietf.org" , "david.borman@quantum.com" Subject: [tcpm] Publication request for draft-ietf-tcpm-tcpmss-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 11:28:24 -0000 The TCPM working group requests to publish draft-ietf-tcpm-tcpmss-04 as Inf= ormational RFC.=20 The Document Shepherd is Michael Scharf = . The write-up is attached below. Thanks Michael (TCPM co-chair) ***************************************************************************= ********** (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The intended status is Informational, and this is indicated on the title page. The document clarifies statements in the current TCP standards-track specifications (most notably, RFC 1122) that are correct, but that lead to some confusion amongst implementors. The document also corrects two RFCs (879 and 2385, the latter is obsoleted by 5925), which contain wrong statements, but which are not part of the set of current TCP standards-track RFCs. Given that limited scope, Informational seems appropriate. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. There has been some confusion as to what value should be filled in the TCP MSS option when using IP and TCP options. When calculating the value to put in the TCP MSS option, the MTU value SHOULD be decreased by only the size of the fixed IP and TCP headers, and SHOULD NOT be decreased to account for any possible IP or TCP options; conversely, the sender MUST reduce=20 the TCP data length to account for any IP or TCP options that it=20 is including in the packets that it sends. =20 Working Group Summary This document was written to clarify statements in the TCP standards, given that implementors asked for better guidance of what is already known for many years. The document represents the consensus of the TCPM working group and addresses all feedback in the working group and during/after the last call. Document Quality This is a short document that can be summarized by a single sentence (in section 2). The rest of this document just explains the rationale of what is implied by the TCP standard documents. The MSS option is implemented in all known TCP stacks. It has been reported=20 in the past that some implementations handled the MSS option differently. Due to the resulting risk of packet fragmentation it can be assumed that all modern TCP stacks comply to what the document clarifies. Personnel The Document Shepherd is Michael Scharf = . The Resposible Area Director is Wesley Eddy . (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd has searched in the working group archives for comments received before, during, and after the working group last call. The Document Shepherd has reviewed the current version and he confirms that all known comments are addressed. The document is considered ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? =20 The issue and the document have been discussed in the working group several times. After these discussions and after the working group last call, some minor changes have been made to address comments from several contributors. Given that the document is short and just clarifies what has already been mandated by the TCP standards, this amount of review is considered sufficient for publication. The Document Shepherd was not active in the working group when the discussion of the document started, but he believes that there has always been strong consensus about the content of the document. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No such review is required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepherd is not aware of any concerns. This is a straightforward document that provides useful guidance to implementors. It should be noted there has been some delay between completion of the working group last call and submission of the current version, due to other obligations of the author. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. There are no known IPR issues with this draft. Given that this document just explains what is already required by RFC 1122 and described therein (although misunderstood by some implementors), IPR issues have not been discussed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures. (9) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? =20 The document represents consensus of the TCPM working group. It can be assumed that everybody in the WG understands the document. The Document Shepherd believes that there has always been strong consensus on what is clarified by the document. The TCPM working group has discussed whether there is actually a need for this document at all, given that it just clarifies what is already implied by TCP standards. The document was finally written because implementors asked for a better explanation. The document has been reviewed by some few individuals in the TCPM working group, it has passed the WGLC, and it has been updated accordingly.=20 (10) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 There is no known discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The draft passes ID nits without any errors or issues that would have to be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes. The document classifies all references as informative. The document could have classified RFC 793 and RFC 1122 as normative, but it is self-contained since it surveys the key recommendations in RFC 793 and RFC 1122 in appendix A. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. The document only references to published RFCs, and one e-mail from 199= 3 related to the topic. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.=20 No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document updates RFC 879 and RFC 2385, which is mentioned on the title page and in the abstract. The introduction explains the rationale for the update. RFC 879 has no known state, and RFC 2385 is obsoleted by RFC 5925. The document explains what is implied by RFC 1122 (and RFC 793), and given that the the statements therein are correct, no update is required. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document has no actions for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document has no actions for IANA. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no such content in the document.= From michael.scharf@alcatel-lucent.com Wed May 9 05:10:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2B821F859E for ; Wed, 9 May 2012 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.538 X-Spam-Level: X-Spam-Status: No, score=-9.538 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id surWDBwdTEKB for ; Wed, 9 May 2012 05:10:29 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id AE76221F8567 for ; Wed, 9 May 2012 05:10:28 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q49C7ism006802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 May 2012 14:10:23 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 9 May 2012 14:10:13 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Wed, 9 May 2012 14:10:12 +0200 Thread-Topic: Additional author for 1323bis Thread-Index: Ac0t3K9fKF34w+5FRQ6HDJj58WBEHg== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB0CF@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "van@parc.com" , "Braden@ISI.EDU" , "david.borman@quantum.com" Subject: [tcpm] Additional author for 1323bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2012 12:10:29 -0000 Dear all, there have been suggestions to add an additional author to draft-ietf-tcpm-= 1323bis-01 in past TCPM meetings. As a consequence, the chairs suggest to add Richard as an additional author= in order the help with the completion of this WG item. Please let us know = if this should result in any issue. The understanding of the chairs is that the 1323bis document should really = focus on fixing corner cases in RFC 1323, and we think that this document s= hould be finished as soon as possible. The recent discussion has shown that TCP timestamps could be further improv= ed, e. g., by late activiation of options. However, this is a new concept t= hat seems to require further studies and experiments. Our recommendation is= therefore to address such new, interesting use of timestamps in a separate= document. Thanks Michael (TCPM co-chair) From iesg-secretary@ietf.org Thu May 10 04:03:33 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3112421F8663; Thu, 10 May 2012 04:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0dXE6B7A4lL; Thu, 10 May 2012 04:03:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4F921F867D; Thu, 10 May 2012 04:03:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510110332.18984.92641.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 04:03:32 -0700 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Protocol Action: 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' to Proposed Standard (draft-ietf-tcpm-3517bis-02.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 10 May 2012 11:03:33 -0000 The IESG has approved the following document: - 'A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP' (draft-ietf-tcpm-3517bis-02.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-3517bis/ Technical Summary This document specifies a loss recovery algorithm based on the use of TCP SACK option that conforms to the current TCP congestion control requirements. It is a revision of Proposed Standard RFC 3517, to provide clarifications and certain performance enhancements to the earlier specified algorithm. Working Group Summary The document was accepted for publication by the TCPM working group by clear consensus. The working group has extensively reviewed the earlier versions of the document, and the result represents the working group consensus. During the working group last call, there were no requests for changes and only comments were supportive of publication. Document Quality The document has employed the long-standing experience of various people working closely with simulated and native TCP SACK implementations. The current TCP SACK implementations are believed to apply closely similar algorithm than what described in this document, even though there may be implementation-specific variations. Personnel Document Shepherd is Pasi Sarolahti . Responsible Area Director is Wesley Eddy . RFC Editor Note (1) Please append to the abstract: "This document obsoletes RFC 3517 and describes changes from it." (2) Please generate a table of contents for the document; the authors did not use XML2RFC and have not attempted to generate one. (3) In Section 2's definition of "pipe", please change "The algorithm" to the "The algorithm for computing the value of pipe" (4) Please insert at the beginning of Section 4, two paragraphs that say: "This section describes a specific structure and control flow for implementing the TCP behavior described by this standard. The behavior is what is standardized, and this particular collection of functions is the strongly recommended means of implementing that behavior, though other approaches to achieving that behavior are feasible." "The definition of Sender Maximum Segment Size (SMSS) used in this section is provided in [RFC5681]." From iesg-secretary@ietf.org Wed May 16 06:56:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F315E21F85D4; Wed, 16 May 2012 06:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCGlJlWe6tXn; Wed, 16 May 2012 06:56:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668A821F85CD; Wed, 16 May 2012 06:56:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120516135623.1460.76801.idtracker@ietfa.amsl.com> Date: Wed, 16 May 2012 06:56:23 -0700 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (TCP Options and MSS) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.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, 16 May 2012 13:56:24 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Options and MSS' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-05-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcpmss/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcpmss/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Fri May 18 09:14:24 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF4821F8622; Fri, 18 May 2012 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHopy9PS4xmW; Fri, 18 May 2012 09:14:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CDD21F85DD; Fri, 18 May 2012 09:14:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 09:14:23 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 16:14:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : TCP Extensions for High Performance Author(s) : David Borman Bob Braden Van Jacobson Richard Scheffenegger Filename : draft-ietf-tcpm-1323bis-02.txt Pages : 45 Date : 2012-05-18 This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms: RTTM (Round Trip Time Measurement) and PAWS (Protection Against Wrapped Sequences). Selective acknowledgments are not included in this memo. This memo updates and obsoletes RFC 1323. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ From rs@netapp.com Fri May 18 09:57:03 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CEB21F864A for ; Fri, 18 May 2012 09:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iNJWlVmCUri for ; Fri, 18 May 2012 09:57:02 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC0FF21F863E for ; Fri, 18 May 2012 09:57:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,618,1330934400"; d="scan'208";a="648562082" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 18 May 2012 09:57:01 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4IGv11h007474; Fri, 18 May 2012 09:57:01 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.17]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0298.004; Fri, 18 May 2012 09:57:00 -0700 From: "Scheffenegger, Richard" To: "Alexander Zimmermann (zimmermann@nets.rwth-aachen.de)" , "tcpm@ietf.org" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt Thread-Index: AQHNNRFn7BAJ03SJbUqZxWzli7XL3ZbPuKaQ Date: Fri, 18 May 2012 16:56:59 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1F5AD6@SACEXCMBX02-PRD.hq.netapp.com> References: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> In-Reply-To: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 16:57:03 -0000 Hi, I have been asked by the chairs to act as editor on this draft, to shepard = it and help finalize it. The main differences between the last version published in March 2009 are s= ummarized here: Moved from nroff to xml2rfc.=20 This changed the layout (indentation, TOC, pagination) somewhat. The content changed in these three aspects, after hallway discussions at th= e last IETF and email discussions: RTTM update processing explicitly excludes packets containing SACK options. This addresses inflation of the RTT during episodes of packet loss in both directions. (This really addresses an omission in all known implementations on the spir= it of RTTM). In Section 3.2 the if-clause allowing sending of timestamps only when received in a or was removed, to allow for late timestamp negotiation. (to continue the ongoing WG discussion on TCP Option space exhaustion and p= ossible (if temporary) mitigations) Section 2.4 was added describing the unavoidable window retraction issue, and explicitly describing the mitigation steps necessary.=20 (-01 already had a pointer to RFC1122 in here, but it may be helpful to imp= lementers to have the proper action described once more explicitly in this = document too). Note: I submitted a version without the Nits-fix from Alexander (http://www= .ietf.org/mail-archive/web/tcpm/current/msg04477.html) for some reason; thi= s is fixed. Also, the issue brought up here may need more discussion, espec= ially if Timestamps should become useful for more than just PAWS and coarse= RTTM: http://www.ietf.org/mail-archive/web/tcpm/current/msg04706.html Best regards, Richard -----Original Message----- From: Scharf, Michael (Michael) Sent: Mittwoch, 09. Mai 2012 14:10 To: tcpm@ietf.org Dear all, there have been suggestions to add an additional author to draft-ietf-tcpm-= 1323bis-01 in past TCPM meetings. As a consequence, the chairs suggest to add Richard as an additional author= in order the help with the completion of this WG item. Please let us know = if this should result in any issue. The understanding of the chairs is that the 1323bis document should really = focus on fixing corner cases in RFC 1323, and we think that this document s= hould be finished as soon as possible. The recent discussion has shown that TCP timestamps could be further improv= ed, e. g., by late activiation of options. However, this is a new concept t= hat seems to require further studies and experiments. Our recommendation is= therefore to address such new, interesting use of timestamps in a separate= document. Thanks Michael (TCPM co-chair) From dab@weston.borman.com Fri May 18 11:07:57 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9B21F8554 for ; Fri, 18 May 2012 11:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09dLJcxdBllo for ; Fri, 18 May 2012 11:07:57 -0700 (PDT) Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2BB21F8650 for ; Fri, 18 May 2012 11:07:53 -0700 (PDT) Received: from [192.168.1.2] (local-2.weston.borman.com [192.168.1.2]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id q4IHcCkD017732; Fri, 18 May 2012 12:38:16 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Borman In-Reply-To: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> Date: Fri, 18 May 2012 12:38:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1F26BC48-6FBE-41F2-9720-5CBF6329EC62@weston.borman.com> References: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> To: Richard Scheffenegger X-Mailer: Apple Mail (2.1278) Cc: "tcpm@ietf.org Extensions WG" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2012 18:07:57 -0000 Hi Richard, Thanks for doing the legwork on bringing this document into the modern = age, the original nroff code was getting a bit old. :-) The pseudo code needs to be updated to match the main body of the = document. Specifically, it has: Check whether the segment contains a Timestamps option and bit Snd.TS.OK is on. If so: If SEG.TSval < TS.Recent and the RST bit is off, then test whether connection has been idle less than 24 days; if all are true, then the segment is not acceptable; follow steps below for an unacceptable segment. If SEG.SEQ is equal to Last.ACK.sent, then save SEG.TSval in variable TS.Recent. There are four cases for the acceptability test for an incoming segment: The second case needs to be changed to: If SEG.SEQ is less than or equal to Last.ACK.sent, then = save SEG.TSval in variable TS.Recent. -David Borman =09 On May 18, 2012, at 11:14 AM, Internet-Drafts@ietf.org wrote: >=20 > 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 > Title : TCP Extensions for High Performance > Author(s) : David Borman > Bob Braden > Van Jacobson > Richard Scheffenegger > Filename : draft-ietf-tcpm-1323bis-02.txt > Pages : 45 > Date : 2012-05-18 >=20 > This memo presents a set of TCP extensions to improve performance > over large bandwidth*delay product paths and to provide reliable > operation over very high-speed paths. It defines TCP options for > scaled windows and timestamps, which are designed to provide > compatible interworking with TCP's that do not implement the > extensions. The timestamps are used for two distinct mechanisms: > RTTM (Round Trip Time Measurement) and PAWS (Protection Against > Wrapped Sequences). Selective acknowledgments are not included in > this memo. >=20 > This memo updates and obsoletes RFC 1323. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Sat May 19 03:22:44 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5330321F8593 for ; Sat, 19 May 2012 03:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAocchLkkOee for ; Sat, 19 May 2012 03:22:43 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22A21F857D for ; Sat, 19 May 2012 03:22:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,621,1330934400"; d="scan'208";a="648700386" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 19 May 2012 03:22:42 -0700 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4JAMf08024891; Sat, 19 May 2012 03:22:42 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.17]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0298.004; Sat, 19 May 2012 03:22:41 -0700 From: "Scheffenegger, Richard" To: David Borman Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt Thread-Index: AQHNNRFn7BAJ03SJbUqZxWzli7XL3ZbQRTQAgACgBwA= Date: Sat, 19 May 2012 10:22:40 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1F7305@SACEXCMBX02-PRD.hq.netapp.com> References: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> <1F26BC48-6FBE-41F2-9720-5CBF6329EC62@weston.borman.com> In-Reply-To: <1F26BC48-6FBE-41F2-9720-5CBF6329EC62@weston.borman.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org Extensions WG" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2012 10:22:44 -0000 Thanks David, I believe that change was in the Nits provided by Alex already (and I forgo= t to apply before re-posting the draft); The other issue mentioned by Alex, the failing PAWS test when ACKs get reor= dered (and the timestamp clock granularity is fine enough to have almost "i= ndividual" timestamps per data packet), is still something that I would lik= e to work out.=20 But I need to dig into this some more (if this can be addressed in a effici= ent way), before I can post some meaningful updates to that aspect. IMHO, making timestamps resilient in the face of fast timestamp clocks and/= or high ACK reordering would be good properties to allow future extensions.= But I would like to learn if this is just a minority opinion in this WG... To quote you: > Also, for this issue that Alexander brings up, the=20 > timestamp has to be changing between ACKs. If the=20 > timestamp hasn't changed between the re- ordered=20 > ACKs, then the "SEG.TSval >=3D TS.recent" check will=20 > succeed. Generally, the TS clock shouldn't be=20 > ticking that often, if it is changing with every=20 > ACK then it might be going faster than it needs to. > > So, this issue only occurs when ACKs are re-ordered,=20 > *and* the Timestamp clock has ticked between the=20 > reordered ACKs. I'm thinking that 1323bis should=20 > just note that this situation does exist. > > What does everyone else think? Shall we leave the=20 > text as is and just document this edge case, or do=20 > people disagree with me and feel that this is a > real problem that needs to be addressed, and is > more important than the problems that the original > change fixes? > > -David Richard Scheffenegger NetApp rs@netapp.com +43 1 3676811 3146 Office (2143 3146 - internal) +43 676 654 3146 Mobile www.netapp.com=A0=A0 EURO PLAZA Geb=E4ude G, Stiege 7, 3.OG Am Euro Platz 2 A-1120 Wien > -----Original Message----- > From: David Borman [mailto:dab@weston.borman.com] > Sent: Freitag, 18. Mai 2012 19:38 > To: Scheffenegger, Richard > Cc: tcpm@ietf.org Extensions WG > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt >=20 > Hi Richard, > Thanks for doing the legwork on bringing this document into the modern > age, the original nroff code was getting a bit old. :-) >=20 > The pseudo code needs to be updated to match the main body of the > document. Specifically, it has: >=20 > Check whether the segment contains a Timestamps option and > bit Snd.TS.OK is on. If so: >=20 > If SEG.TSval < TS.Recent and the RST bit is off, then > test whether connection has been idle less than 24 days; > if all are true, then the segment is not acceptable; > follow steps below for an unacceptable segment. >=20 > If SEG.SEQ is equal to Last.ACK.sent, then save SEG.TSval > in variable TS.Recent. >=20 > There are four cases for the acceptability test for an > incoming segment: >=20 > The second case needs to be changed to: >=20 > If SEG.SEQ is less than or equal to Last.ACK.sent, then sa= ve SEG.TSval > in variable TS.Recent. >=20 > -David Borman >=20 >=20 > On May 18, 2012, at 11:14 AM, Internet-Drafts@ietf.org wrote: >=20 > > > > 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 : TCP Extensions for High Performance > > Author(s) : David Borman > > Bob Braden > > Van Jacobson > > Richard Scheffenegger > > Filename : draft-ietf-tcpm-1323bis-02.txt > > Pages : 45 > > Date : 2012-05-18 > > > > This memo presents a set of TCP extensions to improve performance > > over large bandwidth*delay product paths and to provide reliable > > operation over very high-speed paths. It defines TCP options for > > scaled windows and timestamps, which are designed to provide > > compatible interworking with TCP's that do not implement the > > extensions. The timestamps are used for two distinct mechanisms: > > RTTM (Round Trip Time Measurement) and PAWS (Protection Against > > Wrapped Sequences). Selective acknowledgments are not included in > > this memo. > > > > This memo updates and obsoletes RFC 1323. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-1323bis-02.txt > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/ > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From rs@netapp.com Sat May 19 09:11:04 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FE721F85B1 for ; Sat, 19 May 2012 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.701 X-Spam-Level: X-Spam-Status: No, score=-8.701 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LuvYCW7-43Y for ; Sat, 19 May 2012 09:11:03 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8969621F85A8 for ; Sat, 19 May 2012 09:11:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,621,1330934400"; d="scan'208";a="648737076" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 19 May 2012 09:10:48 -0700 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4JGAmkv005610; Sat, 19 May 2012 09:10:48 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.17]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0298.004; Sat, 19 May 2012 09:10:47 -0700 From: "Scheffenegger, Richard" To: David Borman , "Alexander Zimmermann (zimmermann@nets.rwth-aachen.de)" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt Thread-Index: AQHNNRFn7BAJ03SJbUqZxWzli7XL3ZbQRTQAgAD4gfCAAAAtYA== Date: Sat, 19 May 2012 16:10:47 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F1F76FE@SACEXCMBX02-PRD.hq.netapp.com> References: <20120518161423.10126.35485.idtracker@ietfa.amsl.com> <1F26BC48-6FBE-41F2-9720-5CBF6329EC62@weston.borman.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm \(tcpm@ietf.org\)" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 19 May 2012 16:11:04 -0000 Sorry.=20 I'm trying to wrap my head around the implications of a reordered, and then= discarded, pure ACK as mentioned by Alex (http://www.ietf.org/mail-archiv= e/web/tcpm/current/msg04478.html) In the example given, the main issues appear to be that=20 a) TCP A would not process RTTM updates b) TCP A would send out an updated TS.ecr c) TCP A would not be able to detect reordering d) TCP A would not process any TCP information (options) in the discarded = delayed ACK provided that the PAWS check is performed prior to discarding the delayed A= CK, correct? >From a TCP flow and CC perspective, the later ACK (X+2 in the example) woul= d however give the proper indication to update pipe; only pure NewReno with= out ABC would potentially misbehave during SS - slower than otherwise - but= not during CA). Point a) above wouldn't be done with RFC1323 either (as the reordered ACK d= oesn't ACK any new data anymore) - so ACK reordering would not increase the= RTTM. This may lead to spurious RTOs because of that - but this is status = quo. Point b) may be an issue, but is effectively also covered by a) - as no dat= a flows from B to A, B doesn't update its RTTM anyway, using TS.ecr... Which leaves c) (detection of ACK reordering) and d) (processing of out-ban= d TCP information). But that too is not defined, if I'm not mistaken. c) and d) are basically sub-themes of the unreliable side-channels in TCP s= ignaling... If RTTM processing is seen important, it could be done prior to PAWS, with = a time-based acceptance test (ie. TS.val >=3D TS.recent - 2 * RTO ) when TS= .val < TS.recent... What am I missing? Best regards, Richard=20 From lars@netapp.com Tue May 22 06:59:46 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7420D21F85B9 for ; Tue, 22 May 2012 06:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXQjzR6CGmjS for ; Tue, 22 May 2012 06:59:45 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id C803621F8593 for ; Tue, 22 May 2012 06:59:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,637,1330934400"; d="p7s'?scan'208";a="649412156" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 22 May 2012 06:59:45 -0700 Received: from vmwexceht04-prd.hq.netapp.com (vmwexceht04-prd.hq.netapp.com [10.106.77.34]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q4MDxipp028779 for ; Tue, 22 May 2012 06:59:44 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.15]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.02.0298.004; Tue, 22 May 2012 06:59:44 -0700 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: off-path TCP sequence number inference Thread-Index: AQHNOCMjuYqx9H2s7UKZ8tlGNg0ZnA== Date: Tue, 22 May 2012 13:59:43 +0000 Message-ID: <4C336B55-9235-494E-933C-1F32D3744403@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_2383AC40-705C-46F5-9E7D-B6B5C51287D8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [tcpm] off-path TCP sequence number inference X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 13:59:46 -0000 --Apple-Mail=_2383AC40-705C-46F5-9E7D-B6B5C51287D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FYI: Abstract=97In this paper, we report a newly discovered =93off-path TCP = sequence number inference=94 attack enabled by firewall middleboxes. It = allows an off-path (i.e., not man-in- the-middle) attacker to hijack a = TCP connection and inject malicious content, effectively granting the = attacker write-only permission on the connection. For instance, with the = help of unprivileged malware, we demonstrate that a successful attack = can hijack an HTTP session and return a phishing Facebook login page = issued by a browser. With the same mechanisms, it is also possible to = inject malicious Javascript to post tweets or follow other people on = behalf of the victim. The TCP sequence number inference attack is mainly = enabled by the sequence-number-checking firewall middleboxes. Through = carefully-designed and well-timed probing, the TCP sequence number state = kept on the firewall middlebox can be leaked to an off-path attacker. We = found such firewall middleboxes to be very popular in cellular networks = =97 at least 31.5% of the 149 measured networks deploy such firewalls. = Finally, since the sequence-number-checking feature is enabled by = design, it is unclear how to mitigate the problem easily. http://web.eecs.umich.edu/~zhiyunq/tcp_sequence_number_inference/ = http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_infer= ence.pdf Lars= --Apple-Mail=_2383AC40-705C-46F5-9E7D-B6B5C51287D8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDUyMjEzNTk0NFowIwYJKoZIhvcNAQkEMRYEFC7E a7/44v8Db3+bbyTV2FLhtgBDMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAGc8UE63 eHQR2JJMCO2ajSRLISB8IHa7l9Qx/YSOIfH84xwZjZC8/NOsOka7ZBSoA3WpirKFUEaP44x8ivp2 TQBe6koqM/M60mpLTVs54Do0+b5ykfyTkm23DSKR/wovMeAWYMY3p+YK0A3tTXGPps0rSC/0Do8R oF2afKvei32w/dRXGlFpAj5Wg1xo5rRqHkxpt3+c5y6pIVjH0FmWMbFmSVMYRqWmwaPAZo6Uwdto nI+MuepeFbiDLUGzkFYQXfKwbWVzAc2mks4MqXwrs3hc4TNGMpGOQXSD3cBOB6ge8TJJRoKiWk2X f/ZhQX8hllK6BSmWOI0HsGIOTkP7SX8AAAAAAAA= --Apple-Mail=_2383AC40-705C-46F5-9E7D-B6B5C51287D8-- From touch@isi.edu Tue May 22 10:01:08 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0232F21F8645 for ; Tue, 22 May 2012 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GksInumZmblT for ; Tue, 22 May 2012 10:01:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 72BA021F863D for ; Tue, 22 May 2012 10:01:03 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4MH0hG2013370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 May 2012 10:00:43 -0700 (PDT) Message-ID: <4FBBC63B.8080607@isi.edu> Date: Tue, 22 May 2012 10:00:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <4C336B55-9235-494E-933C-1F32D3744403@netapp.com> In-Reply-To: <4C336B55-9235-494E-933C-1F32D3744403@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tcpm@ietf.org" Subject: Re: [tcpm] off-path TCP sequence number inference X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2012 17:01:08 -0000 On 5/22/2012 6:59 AM, Eggert, Lars wrote: > FYI: > > Abstract—In this paper, we report a newly discovered “off-path TCP sequence number inference” attack enabled by firewall middleboxes. It allows an off-path (i.e., not man-in- the-middle) attacker to hijack a TCP connection and inject malicious content, effectively granting the attacker write-only permission on the connection. For instance, with the help of unprivileged malware, we demonstrate that a successful attack can hijack an HTTP session and return a phishing Facebook login page issued by a browser. With the same mechanisms, it is also possible to inject malicious Javascript to post tweets or follow other people on behalf of the victim. The TCP sequence number inference attack is mainly enabled by the sequence-number-checking firewall middleboxes. Through carefully-designed and well-timed probing, the TCP sequence number state kept on the firewall middlebox can be leaked to an off-path attacker. We found such firewall middleboxes to be very popular in cellular networ! ks — at least 31.5% of the 149 measured networks deploy such firewalls. Finally, since the sequence-number-checking feature is enabled by design, it is unclear how to mitigate the problem easily. > > http://web.eecs.umich.edu/~zhiyunq/tcp_sequence_number_inference/ > http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf > > Lars Hi, Lars (et al.), I don't know anyone who considers "off-path" attacks to include malware *on the device being attacked*, as this does. That's not only on-path, that's on-device. The details require: - guessing the 4-tuple by either spoofing the IP address of the destination, tracking packets from/on the device using malware, or "guessing" properly - guessing the sequence number, either using on-device malware or scanning the 32-bit window range The on-path vulnerability is having any device on-path - including on-device - that can see the 4-tuple and sequence numbers of existing connections. The key insight here appears to be that non-privileged malware can see the 4-tuples of connections on a device -- but that doesn't help much unless the ISNs are *predictable* or the attacker probes the sequence window - which can be easily be used as an indication of attack. The true off-path vulnerability here - without on-path assistance - is guessing the 4-tuple *and* guessing the sequence number correctly. The traffic generated to create such an attack itself could easily be tracked to raise flags on a device (e.g., large number of packets to nonexistent connections). To misquote recent news, seems like a "tempest in a TCP pot" Joe From michael.scharf@alcatel-lucent.com Fri May 25 09:16:41 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6121F870E for ; Fri, 25 May 2012 09:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.45 X-Spam-Level: X-Spam-Status: No, score=-9.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RPX5-ijeKLu for ; Fri, 25 May 2012 09:16:40 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1E95421F870B for ; Fri, 25 May 2012 09:16:39 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4PGGavR020372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 25 May 2012 18:16:36 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 25 May 2012 18:16:36 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Fri, 25 May 2012 18:16:35 +0200 Thread-Topic: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada Thread-Index: Ac06kTx8gIC7azzpTBqD7T3hMmzhigAAD8Sw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB335@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [tcpm] FW: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2012 16:16:41 -0000 This workshop could be related to TCPM... Michael IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada =20 The IAB and IRTF will hold a workshop on Congestion Control for Interactiv= e Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 201= 2 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.ht= ml ). Participation at the wor= kshop is free of charge. There is no requirement to either register with or= attend the IETF-84 meeting that follows the workshop. =20 The workshop organizers would like to foster a discussion on: 1. What are appropriate congestion signals to use for interactive media an= d data? 2. What existing congestion control algorithms are appropriate for interac= tive media and data? What properties would be desirable in new congestion c= ontrol algorithms? 3. Measurement and/or simulations of new congestion signals (e.g., delay-b= ased) and their interaction with existing congestion control mechanisms. 4. What are good available techniques for adjusting sending rates for inte= ractive media and data? What are the limits of those techniques? What prope= rties would be desirable in new techniques? 5. What application-specific considerations have to be taken into account? 6. How can we ensure that real-time communications are well-behaved with r= espect to other Internet applications while still providing good quality? 7. What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well= as other topics related to congestion control for interactive realtime med= ia. =20 Every prospective workshop participant must submit a position paper contai= ning a name and an email address. Authors of accepted papers will be invite= d to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain t= ext (for example, as a submitted Internet-Draft) are ideal. Accepted positi= on papers will be published. Additional details about the meeting venue wi= ll be provided to authors of accepted papers. Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Additional Details Additional details on the workshop as well as the submission process is av= ailable at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better inter= active media congestion control mechanisms on the Internet (such as by maki= ng a contribution towards catering costs and room rental), please contact u= s! In case of questions please send email to mary.ietf.barnes at gmail.com . =20 From internet-drafts@ietf.org Wed May 30 15:40:29 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7A611E810C; Wed, 30 May 2012 15:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCoz4CkanQkl; Wed, 30 May 2012 15:40:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5BB11E8117; Wed, 30 May 2012 15:40:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120530224029.12692.80401.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2012 15:40:29 -0700 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-experimental-options-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 22:40:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. Title : Shared Use of Experimental TCP Options Author(s) : Joe Touch Filename : draft-ietf-tcpm-experimental-options-01.txt Pages : 8 Date : 2012-05-30 This document describes how TCP option codepoints can support concurrent experiments using a magic number field. This mechanism avoids the need for a coordinated registry, and is backward- compatible with currently known uses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01.= txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ From touch@isi.edu Wed May 30 15:46:21 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9B11E8133; Wed, 30 May 2012 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT62PYO1h+m7; Wed, 30 May 2012 15:46:21 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58811E8073; Wed, 30 May 2012 15:46:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4UMjhju000264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2012 15:45:44 -0700 (PDT) Message-ID: <4FC6A317.3010604@isi.edu> Date: Wed, 30 May 2012 15:45:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20120530224029.12692.80401.idtracker@ietfa.amsl.com> In-Reply-To: <20120530224029.12692.80401.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-experimental-options-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 22:46:22 -0000 Hi, all, This version incorporates feedback from the list. In specific: - minimum magic number length is not specified There are minor reorganization and revisions as well. Joe On 5/30/2012 3:40 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. > > Title : Shared Use of Experimental TCP Options > Author(s) : Joe Touch > Filename : draft-ietf-tcpm-experimental-options-01.txt > Pages : 8 > Date : 2012-05-30 > > This document describes how TCP option codepoints can support > concurrent experiments using a magic number field. This mechanism > avoids the need for a coordinated registry, and is backward- > compatible with currently known uses. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-experimental-options-01.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From touch@isi.edu Wed May 30 16:05:30 2012 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9821F8615 for ; Wed, 30 May 2012 16:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx9+wnUGhwse for ; Wed, 30 May 2012 16:05:29 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6588E21F860F for ; Wed, 30 May 2012 16:05:29 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q4UN4W39006934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 May 2012 16:04:32 -0700 (PDT) Message-ID: <4FC6A780.3000701@isi.edu> Date: Wed, 30 May 2012 16:04:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tcpm@ietf.org" References: <20120530224553.13541.213.idtracker@ietfa.amsl.com> In-Reply-To: <20120530224553.13541.213.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120530224553.13541.213.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-nat-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2012 23:05:30 -0000 Hi, all, I have submitted an updated version of TCP-AO NAT. It was updated with a new date and more recent citations. As per discussions on this list, since there was insufficient interest in this WG, this document has been submitted for publication as an individual submission. FYI. Joe -------- Original Message -------- Subject: New Version Notification for draft-touch-tcp-ao-nat-03.txt Date: Wed, 30 May 2012 15:45:53 -0700 From: internet-drafts@ietf.org To: touch@isi.edu A new version of I-D, draft-touch-tcp-ao-nat-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Filename: draft-touch-tcp-ao-nat Revision: 03 Title: A TCP Authentication Option NAT Extension Creation date: 2012-05-30 WG ID: Individual Submission Number of pages: 6 Abstract: This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but does not alter TCP-AO's packet processing or key generation algorithms. The IETF Secretariat