From mallman@icir.org Mon May 3 12:21:57 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC28E3A684B for ; Mon, 3 May 2010 12:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.478 X-Spam-Level: X-Spam-Status: No, score=-5.478 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHl0z-HBaqWX for ; Mon, 3 May 2010 12:21:56 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 097B63A6AD6 for ; Mon, 3 May 2010 12:20:47 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o43JKVCp015871; Mon, 3 May 2010 12:20:31 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 193F2FD528B; Mon, 3 May 2010 15:20:31 -0400 (EDT) To: David Borman From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Smoke MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma8702-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 03 May 2010 15:20:31 -0400 Sender: mallman@icir.org Message-Id: <20100503192031.193F2FD528B@lawyers.icir.org> Cc: "tcpm@ietf.org WG" , L.Wood@surrey.ac.uk, Joe Touch Subject: Re: [tcpm] WGLC for MSS document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 19:21:58 -0000 ----------ma8702-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > I'd appreciate it of those on the To: list of this message, who made > comments on the previous version of the MSS document, could reply to > the mailing list whether or not you feel your comments are adequately > addressed, so that we have a record of consensus. Thanks. Sorry for being late on this. The rev addresses my comments. The document looks good to me. allman ----------ma8702-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkvfIf4ACgkQWyrrWs4yIs7s5wCgnd1g6DgVF7ie0xMRj/LnelGH L/UAnjZ1nNfIdxYyvmhXGUs5AQbEAUPe =PXfu -----END PGP SIGNATURE----- ----------ma8702-1-- From root@core3.amsl.com Tue May 4 00:30:02 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0CF623A6877; Tue, 4 May 2010 00:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100504073002.0CF623A6877@core3.amsl.com> Date: Tue, 4 May 2010 00:30:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 07:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Improving TCP's Robustness to Blind In-Window Attacks Author(s) : A. Ramaiah, et al. Filename : draft-ietf-tcpm-tcpsecure-13.txt Pages : 26 Date : 2010-05-04 TCP has historically been considered protected against spoofed off- path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32 bit sequence number(s). A combination of increasing window sizes and applications using longer term connections (e.g. H-323 or Border Gateway Protocol [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks. Many of these long term TCP applications tend to have predictable IP addresses and ports which makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be guessed. Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-tcpsecure-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-04001824.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue May 18 09:50:51 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E5723A6C65; Tue, 18 May 2010 09:50:51 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100518165051.7E5723A6C65@core3.amsl.com> Date: Tue, 18 May 2010 09:50:51 -0700 (PDT) Cc: tcpm chair , tcpm mailing list , Internet Architecture Board , RFC Editor Subject: [tcpm] Protocol Action: 'Improving TCP's Robustness to Blind In-Window Attacks' to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:50:51 -0000 The IESG has approved the following document: - 'Improving TCP's Robustness to Blind In-Window Attacks ' as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact person is Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-13.txt Technical Summary: This document examines the fact that long term TCP connections that have well known source and destination addresses are vulnerable to attack by the injection of bogus RST, SYN or data packets by guessing sequence numbers that fall into the current window of the connection. It provides three mitigation strategies that can be used to reduce the chance that an attacker can be successful with these spoofed segments. Working Group Summary The working group saw that there was a fair amount of experience with these mitigation strategies; two of them are very simple, and one is a bit more involved. The WG felt that this document is a SHOULD for devices that are susceptible to these types of attacks, and a MAY for other implementations. These changes are not needed for correct TCP operation, but reduce the chance that a spoofed packet will be accepted as valid. Document Quality The document was reviewed for quality by a fair number of TCPM WG members. There already exist several implementations of these strategies, and there are not any known interoperability issues with TCP implementations that do not have these changes. Personnel David Borman (david.borman@windriver.com) is the document shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG. From wesley.m.eddy@nasa.gov Tue May 18 10:03:01 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5D43A6A50 for ; Tue, 18 May 2010 10:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I++O0B3Gciax for ; Tue, 18 May 2010 10:02:59 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id A08B63A68B9 for ; Tue, 18 May 2010 10:02:48 -0700 (PDT) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id F1591108425; Tue, 18 May 2010 12:02:40 -0500 (CDT) Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o4IH2eRu014740; Tue, 18 May 2010 12:02:40 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Tue, 18 May 2010 12:02:40 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" , "ietfdbh@comcast.net" , "lars.eggert@nokia.com" Date: Tue, 18 May 2010 12:02:39 -0500 Thread-Topic: [Technical Errata Reported] RFC5681 (2269) Thread-Index: Acr2py7Pe6TOLK8nTz2FQLeyA6BtUAAA+mRA Message-ID: References: <20100518162738.29C0AE065C@rfc-editor.org> In-Reply-To: <20100518162738.29C0AE065C@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-18_02:2010-02-06, 2010-05-18, 2010-05-18 signatures=0 Cc: "nmalykh@protocols.ru" , "tcpm@ietf.org" Subject: Re: [tcpm] [Technical Errata Reported] RFC5681 (2269) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:03:01 -0000 I think this errata should be rejected, as 3042 behavior is referenced as a SHOULD on page 9, when implementing fast retransmit + fast recovery, and this material is new for 5681 (it was not part of 2581), but I think we need to discuss this on the TCPM list and let our ADs know how to handle it. -- Wes Eddy MTI Systems >-----Original Message----- >From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >Sent: Tuesday, May 18, 2010 12:28 PM >To: mallman@icir.org; vern@icir.org; eblanton@cs.purdue.edu; >ietfdbh@comcast.net; lars.eggert@nokia.com; weddy@grc.nasa.gov; >david.borman@windriver.com >Cc: nmalykh@protocols.ru; tcpm@ietf.org; rfc-editor@rfc-editor.org >Subject: [Technical Errata Reported] RFC5681 (2269) > > >The following errata report has been submitted for RFC5681, >"TCP Congestion Control". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D5681&eid=3D2269 > >-------------------------------------- >Type: Technical >Reported by: Nikolai Malykh > >Section: 7 > >Original Text >------------- > The description of fast retransmit and fast recovery has been > clarified, and the use of Limited Transmit [RFC3042] is now > recommended. > > >Corrected Text >-------------- > The description of fast retransmit and fast recovery has been > clarified. > > >Notes >----- >Really using of Limited Transmit [RFC3042] is not recommended anywhere >in RFC 5681. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC5681 (draft-ietf-tcpm-rfc2581bis-07) >-------------------------------------- >Title : TCP Congestion Control >Publication Date : September 2009 >Author(s) : M. Allman, V. Paxson, E. Blanton >Category : DRAFT STANDARD >Source : TCP Maintenance and Minor Extensions >Area : Transport >Stream : IETF >Verifying Party : IESG From Donald.Smith@qwest.com Tue May 18 12:19:04 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1607E3A68E8; Tue, 18 May 2010 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.256 X-Spam-Level: X-Spam-Status: No, score=-0.256 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_50=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlOTW2Dq6VQK; Tue, 18 May 2010 12:19:03 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by core3.amsl.com (Postfix) with ESMTP id E698F3A6AC0; Tue, 18 May 2010 12:18:17 -0700 (PDT) Received: from suomp60i.qintra.com (suomp60i.qintra.com [151.117.69.27]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id o4IJI9Ri016278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 14:18:09 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp60i.qintra.com (8.14.4/8.14.4) with ESMTP id o4IJI38t017976; Tue, 18 May 2010 14:18:03 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Tue, 18 May 2010 13:18:02 -0600 From: "Smith, Donald" To: "'tcpm@ietf.org WG'" , "'The IESG'" Date: Tue, 18 May 2010 13:18:00 -0600 Thread-Topic: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt Thread-Index: Acq5q9zzpcVWcYT4S5OmJS6FWMliJg9DCCyg Message-ID: References: <201003012159.WAA15069@TR-Sys.de> <4B8C70C0.8090708@gont.com.ar> In-Reply-To: <4B8C70C0.8090708@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:19:04 -0000 First throughout this draft the authors refer to sequence number checking w= here they really mean acknowledgement number checking:( You can't quite do = :g/sequence number/s//acknowledgement number/g as in a few places it is the= senders sequence number they are discussing. The authors also use "the exact expected sequence number" a lot. I think they mean: last sent sequence number + the data length sent This looks a LOT like gonts draft but may be an attempt to address just one= issue identified here. http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.4 This is slightly incorrect. In window would include an exact match for rcv.= net+rcv.wnd so the right side should be =3D<. The wording for how to do the challenge ack is a bit difficult to follow to= o. 3) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK): Ramaiah, et al. Expires November 4, 2010 [Page 9] Internet-Draft TCP Security May 2010 After sending the challenge ACK, TCP MUST drop the unacceptable segment and stop processing the incoming packet further. Further segments destined to this connection will be processed as normal. 3) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the current receive window (RCV.NXT < SEG.SEQ =3D< RCV.NXT+RCV.WND), TCP MUST send an acknowledgment (challenge ACK): Ramaiah, et al. Expires November 4, 2010 [Page 9] Internet-Draft TCP Security May 2010 After sending the challenge ACK, TCP MUST silently drop the in window but not exact match segment and stop processing it. Additional segments destined to this connection MUST be processed as normal. That last line is really extraneous. You don't say what happens to the pack= ets before this event I am not sure you have to say handle the next packet = per normal behavior;) The authors need to explain exactly what that challenge ACK looks like. I think it is the same 4 tuple, ack =3D last sent ack, seq =3D last sent se= q (no data). Still on page 9. In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields [sequence numbers]. A reset is valid if its sequence number exactly matches the next expected sequence number. If the RST arrives and its sequence number field does NOT match the next expected sequence number but is within the window, then the receiver should generate an ACK. In all other cases where the SEQ-field does not match and is outside the window, the receiver MUST silently discard the segment. Should be: In all states except SYN-SENT, all reset (RST) segments are validated by checking their ACK-fields [acknowledgement numbers]. A reset is vali= d if its acknowledgement number exactly matches the last sent sequence number= + the data length sent. If the RST arrives and its acknowledgement number field does NOT match the last sent sequence number + the data length sent but is within= the window, then the receiver SHOULD (or MUST?) generate an ACK. In all other cases= where the ACK-field does not match and is outside the window, the receiver MUST silently discard the segment. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From ananth@cisco.com Tue May 18 13:32:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3153A6954; Tue, 18 May 2010 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vEGpweb9p8h; Tue, 18 May 2010 13:32:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CFEAF3A696C; Tue, 18 May 2010 13:32:25 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB+W8kurR7Ht/2dsb2JhbACeBHGlEJluhRAEg0A X-IronPort-AV: E=Sophos;i="4.53,257,1272844800"; d="scan'208";a="199181216" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 May 2010 20:32:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4IKWHHp028477; Tue, 18 May 2010 20:32:18 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 13:32:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 13:32:16 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt Thread-Index: Acq5q9zzpcVWcYT4S5OmJS6FWMliJg9DCCygAAH3UGA= References: <201003012159.WAA15069@TR-Sys.de><4B8C70C0.8090708@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Smith, Donald" , , "The IESG" X-OriginalArrivalTime: 18 May 2010 20:32:18.0171 (UTC) FILETIME=[359B4CB0:01CAF6C9] Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 20:32:30 -0000 Smith, Comments inline..=20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Smith, Donald > Sent: Tuesday, May 18, 2010 12:18 PM > To: 'tcpm@ietf.org WG'; 'The IESG' > Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt >=20 > First throughout this draft the authors refer to sequence=20 > number checking where they really mean acknowledgement number=20 > checking:( You can't quite do :g/sequence=20 Incorrect. RST and SYN mitigtations talk about the sequence number checking. The ACK number is not relevant as far as the mitigation themselves are cocnerned. Data mitigation talks about the ACK number. We had added more text to make sure such ambiguity was removed when the data mitigation was discussed in response to WG comments. > number/s//acknowledgement number/g as in a few places it is=20 > the senders sequence number they are discussing. > The authors also use "the exact expected sequence number" a lot. > I think they mean: last sent sequence number + the data length sent Nope, exact sequence number is RCV.NXT (which is the exact sequence number) RCV.NXT + RCV.WND -1 is the right edge. Any sequence number which falls in this window is considered valid. These are all terminology borrowed from RFC 793 and we are not changing those. >=20 > This looks a LOT like gonts draft but may be an attempt to=20 > address just one issue identified here. >=20 > http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.4 What? TCP secure draft was first published in 2004/2005 after which followed informational RFC on "TCP spoofing attacks" , ICMP attacks, port randomization and then Gont's draft. TCP secure, FWIW, was an inspiration to all these drafts (with due acknowledgements to Watson's "slipping in the window" paper) Probably Gont's draft should refer this draft if not already doing so. Were you not really following this document, this has been floating around for the last 5+ years in the IETF ? >=20 >=20 > This is slightly incorrect. In window would include an exact=20 > match for rcv.net+rcv.wnd so the right side should be =3D<. > The wording for how to do the challenge ack is a bit=20 > difficult to follow too. Why? This has been reviewed by many folks and the way it is : i.e, quoting the RFC 793 text FIRST and then quoting the mitigations NEXT was easier to follow. I don't plan to change the WG decision. >=20 >=20 >=20 > 3) If the RST bit is set and the sequence number does not exactly > match the next expected sequence value, yet is within=20 > the current > receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST > send an acknowledgment (challenge ACK): >=20 > >=20 > Ramaiah, et al. Expires November 4, 2010 =20 > [Page 9] > Internet-Draft TCP Security =20 > May 2010 >=20 > After sending the challenge ACK, TCP MUST drop the unacceptable > segment and stop processing the incoming packet=20 > further. Further > segments destined to this connection will be processed=20 > as normal. >=20 >=20 >=20 >=20 >=20 >=20 > 3) If the RST bit is set and the sequence number does not exactly > match the next expected sequence value, yet is within=20 > the current > receive window (RCV.NXT < SEG.SEQ =3D< RCV.NXT+RCV.WND), TCP = MUST > send an acknowledgment (challenge ACK): Again this is the RFC 793 language, we haven't changed it. (Pl see RFC 793 page 69, acceptability checks) >=20 > The challenge ACK is what matters and you should be looking into. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ramaiah, et al. Expires November 4, 2010 =20 > [Page 9] >=20 > Internet-Draft TCP Security =20 > May 2010 >=20 >=20 > After sending the challenge ACK, TCP MUST silently drop=20 > the in window > but not exact match segment and stop processing it. Additional > segments destined to this connection MUST be processed=20 > as normal. >=20 > That last line is really extraneous. You don't say what=20 > happens to the packets before this event I am not sure you=20 > have to say handle the next packet per normal behavior;) The=20 > authors need to explain exactly what that challenge ACK looks like. > I think it is the same 4 tuple, ack =3D last sent ack, seq =3D=20 > last sent seq (no data). Well, you can go on explaining each and everything, we had chosen to stick to the RFC 793 language, in other words, the intention is affect only the portion of RFC 793 and rest is exactly what RFC 793 says. If we add additional text that would really add to the confusion. This was atleast the rationale and WG had agreed to such thinking w.r.t this draft. >=20 >=20 >=20 >=20 > Still on page 9. > In all states except SYN-SENT, all reset (RST) segments are validated > by checking their SEQ-fields [sequence numbers]. A reset=20 > is valid if > its sequence number exactly matches the next expected sequence > number. If the RST arrives and its sequence number field does NOT > match the next expected sequence number but is within the window, > then the receiver should generate an ACK. In all other cases where > the SEQ-field does not match and is outside the window,=20 > the receiver > MUST silently discard the segment. >=20 >=20 > Should be: > In all states except SYN-SENT, all reset (RST) segments are validated > by checking their ACK-fields [acknowledgement numbers]. A=20 Incorrect. It is the sequence number that needs to be validated first, please read RFC 793. (Page 37 RFC 793) > reset is valid if > its acknowledgement number exactly matches the last sent=20 > sequence number + the data length sent. > If the RST arrives and its acknowledgement number field does NOT > match the last sent sequence number + the data length sent=20 > but is within the window, > then the receiver SHOULD (or MUST?) generate an ACK. In=20 > all other cases where > the ACK-field does not match and is outside the window,=20 > the receiver > MUST silently discard the segment. >=20 >=20 >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) Not sure which of the above caused confusion ;-) -Anantha From Donald.Smith@qwest.com Tue May 18 14:35:29 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383BB3A6A7B; Tue, 18 May 2010 14:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_50=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5D-WPJsUAX0; Tue, 18 May 2010 14:35:27 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id CC7683A69BD; Tue, 18 May 2010 14:35:27 -0700 (PDT) Received: from suomp61i.qintra.com (suomp61i.qintra.com [151.117.69.28]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o4ILZIC0018703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 15:35:19 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id o4ILZC31025652; Tue, 18 May 2010 16:35:13 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 18 May 2010 15:35:12 -0600 From: "Smith, Donald" To: "'Anantha Ramaiah (ananth)'" , "'tcpm@ietf.org'" , "'The IESG'" Date: Tue, 18 May 2010 15:35:11 -0600 Thread-Topic: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt Thread-Index: Acq5q9zzpcVWcYT4S5OmJS6FWMliJg9DCCygAAH3UGAAA2Qx4A== Message-ID: References: <201003012159.WAA15069@TR-Sys.de><4B8C70C0.8090708@gont.com.ar> <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 21:35:29 -0000 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > Sent: Tuesday, May 18, 2010 2:32 PM > To: Smith, Donald; tcpm@ietf.org; The IESG > Subject: RE: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt > > Smith, > Comments inline.. > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Smith, Donald > > Sent: Tuesday, May 18, 2010 12:18 PM > > To: 'tcpm@ietf.org WG'; 'The IESG' > > Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt > > > > First throughout this draft the authors refer to sequence > > number checking where they really mean acknowledgement number > > checking:( You can't quite do :g/sequence > > Incorrect. RST and SYN mitigtations talk about the sequence number > checking. > The ACK number is not relevant as far as the mitigation > themselves are cocnerned. Data mitigation talks about the ACK > number. We > had added more text to make sure such ambiguity was removed when the > data mitigation was discussed in response to WG comments. > > > > number/s//acknowledgement number/g as in a few places it is > > the senders sequence number they are discussing. > > The authors also use "the exact expected sequence number" a lot. > > I think they mean: last sent sequence number + the data length sent > > Nope, exact sequence number is RCV.NXT (which is the exact sequence > number) RCV.NXT + RCV.WND -1 is the right edge. Any sequence number > which falls in this window is considered valid. These are all > terminology borrowed from RFC 793 and we are not changing those. ok. > > > > > This looks a LOT like gonts draft but may be an attempt to > > address just one issue identified here. > > > > http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.4 > > What? TCP secure draft was first published in 2004/2005 after which > followed informational RFC on "TCP spoofing attacks" , ICMP attacks, > port randomization and then Gont's draft. TCP secure, FWIW, was an > inspiration to all these drafts (with due acknowledgements to Watson's > "slipping in the window" paper) Ok > > Probably Gont's draft should refer this draft if not already doing so. It references the 10th version of the draft. > > Were you not really following this document, this has been floating > around for the last 5+ years in the IETF ? I only joined this group a a year or so ago so no I haven't following this = draft. > > > > > > > This is slightly incorrect. In window would include an exact > > match for rcv.net+rcv.wnd so the right side should be =3D<. > > The wording for how to do the challenge ack is a bit > > difficult to follow too. > > Why? This has been reviewed by many folks and the way it is : i.e, > quoting the RFC 793 text FIRST and then quoting the > mitigations NEXT was > easier to follow. I don't plan to change the WG decision. > > > > > > > > > 3) If the RST bit is set and the sequence number does not exactly > > match the next expected sequence value, yet is within > > the current > > receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST > > send an acknowledgment (challenge ACK): > > > > > > > > Ramaiah, et al. Expires November 4, 2010 > > [Page 9] > > Internet-Draft TCP Security > > May 2010 > > > > After sending the challenge ACK, TCP MUST drop the > unacceptable > > segment and stop processing the incoming packet > > further. Further > > segments destined to this connection will be processed > > as normal. > > > > > > > > > > > > > > 3) If the RST bit is set and the sequence number does not exactly > > match the next expected sequence value, yet is within > > the current > > receive window (RCV.NXT < SEG.SEQ =3D< > RCV.NXT+RCV.WND), TCP MUST > > send an acknowledgment (challenge ACK): > > Again this is the RFC 793 language, we haven't changed it. (Pl see RFC > 793 page 69, acceptability checks) Ok. Reviewed (again) your correct the language is consistent. > > > > > > > The challenge ACK is what matters and you should be looking into. > > > > > > > > > > > > > > > > > Ramaiah, et al. Expires November 4, 2010 > > [Page 9] > > > > Internet-Draft TCP Security > > May 2010 > > > > > > After sending the challenge ACK, TCP MUST silently drop > > the in window > > but not exact match segment and stop processing it. > Additional > > segments destined to this connection MUST be processed > > as normal. > > > > That last line is really extraneous. You don't say what > > happens to the packets before this event I am not sure you > > have to say handle the next packet per normal behavior;) The > > authors need to explain exactly what that challenge ACK looks like. > > I think it is the same 4 tuple, ack =3D last sent ack, seq =3D > > last sent seq (no data). > > Well, you can go on explaining each and everything, we had chosen to > stick to the RFC 793 language, in other words, the intention is affect > only the portion of RFC 793 and rest is exactly what RFC 793 > says. If we > add additional text that would really add to the confusion. This was > atleast the rationale and WG had agreed to such thinking w.r.t this > draft. People wrote books about rfc793 because it was a bit difficult to follow bu= t if that was the decision of the WG I withdraw my suggestions. > > > > > > > > > > > Still on page 9. > > In all states except SYN-SENT, all reset (RST) segments are > validated > > by checking their SEQ-fields [sequence numbers]. A reset > > is valid if > > its sequence number exactly matches the next expected sequence > > number. If the RST arrives and its sequence number > field does NOT > > match the next expected sequence number but is within the window, > > then the receiver should generate an ACK. In all other > cases where > > the SEQ-field does not match and is outside the window, > > the receiver > > MUST silently discard the segment. > > > > > > Should be: > > In all states except SYN-SENT, all reset (RST) segments are > validated > > by checking their ACK-fields [acknowledgement numbers]. A > > Incorrect. It is the sequence number that needs to be validated first, > please read RFC 793. (Page 37 RFC 793) > > > reset is valid if > > its acknowledgement number exactly matches the last sent > > sequence number + the data length sent. > > If the RST arrives and its acknowledgement number field does NOT > > match the last sent sequence number + the data length sent > > but is within the window, > > then the receiver SHOULD (or MUST?) generate an ACK. In > > all other cases where > > the ACK-field does not match and is outside the window, > > the receiver > > MUST silently discard the segment. > > > > > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > Not sure which of the above caused confusion ;-) Perhaps a lack of coffee (or sleep:) > > -Anantha > > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Donald.Smith@qwest.com Tue May 18 14:39:37 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566203A68FC; Tue, 18 May 2010 14:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.006 X-Spam-Level: X-Spam-Status: No, score=-0.006 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_40=-0.185, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kypva4JkrqId; Tue, 18 May 2010 14:39:36 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by core3.amsl.com (Postfix) with ESMTP id 3CD633A67F5; Tue, 18 May 2010 14:39:31 -0700 (PDT) Received: from sudnp796.qintra.com (sudnp796.qintra.com [151.116.2.212]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id o4ILdM8R020782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 May 2010 15:39:22 -0600 (MDT) Received: from qtdenexhtm22.AD.QINTRA.COM (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id o4ILdGRW029920; Tue, 18 May 2010 15:39:17 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm22.AD.QINTRA.COM ([151.119.91.231]) with mapi; Tue, 18 May 2010 15:39:17 -0600 From: "Smith, Donald" To: "'Anantha Ramaiah (ananth)'" , "'tcpm@ietf.org'" , "'The IESG'" Date: Tue, 18 May 2010 15:39:16 -0600 Thread-Topic: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt Thread-Index: Acq5q9zzpcVWcYT4S5OmJS6FWMliJg9DCCygAAH3UGAABKS9MA== Message-ID: References: <201003012159.WAA15069@TR-Sys.de><4B8C70C0.8090708@gont.com.ar> <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 21:39:37 -0000 Won't this break syn cookies since the server doesn't keep state on the ori= ginal syn's sequence number? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@qwest.com gcia > -----Original Message----- > From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > Sent: Tuesday, May 18, 2010 2:32 PM > To: Smith, Donald; tcpm@ietf.org; The IESG > Subject: RE: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt > > Smith, > Comments inline.. > > > -----Original Message----- > > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > > Behalf Of Smith, Donald > > Sent: Tuesday, May 18, 2010 12:18 PM > > To: 'tcpm@ietf.org WG'; 'The IESG' > > Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt > > > > First throughout this draft the authors refer to sequence > > number checking where they really mean acknowledgement number > > checking:( You can't quite do :g/sequence > > Incorrect. RST and SYN mitigtations talk about the sequence number > checking. The ACK number is not relevant as far as the mitigation > themselves are cocnerned. Data mitigation talks about the ACK > number. We > had added more text to make sure such ambiguity was removed when the > data mitigation was discussed in response to WG comments. > > > > number/s//acknowledgement number/g as in a few places it is > > the senders sequence number they are discussing. > > The authors also use "the exact expected sequence number" a lot. > > I think they mean: last sent sequence number + the data length sent > > Nope, exact sequence number is RCV.NXT (which is the exact sequence > number) RCV.NXT + RCV.WND -1 is the right edge. Any sequence number > which falls in this window is considered valid. These are all > terminology borrowed from RFC 793 and we are not changing those. > > > > > This looks a LOT like gonts draft but may be an attempt to > > address just one issue identified here. > > > > http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.4 > > What? TCP secure draft was first published in 2004/2005 after which > followed informational RFC on "TCP spoofing attacks" , ICMP attacks, > port randomization and then Gont's draft. TCP secure, FWIW, was an > inspiration to all these drafts (with due acknowledgements to Watson's > "slipping in the window" paper) > > Probably Gont's draft should refer this draft if not already doing so. > > Were you not really following this document, this has been floating > around for the last 5+ years in the IETF ? > > > > > > > This is slightly incorrect. In window would include an exact > > match for rcv.net+rcv.wnd so the right side should be =3D<. > > The wording for how to do the challenge ack is a bit > > difficult to follow too. > > Why? This has been reviewed by many folks and the way it is : i.e, > quoting the RFC 793 text FIRST and then quoting the > mitigations NEXT was > easier to follow. I don't plan to change the WG decision. > > > > > > > > > 3) If the RST bit is set and the sequence number does not exactly > > match the next expected sequence value, yet is within > > the current > > receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST > > send an acknowledgment (challenge ACK): > > > > > > > > Ramaiah, et al. Expires November 4, 2010 > > [Page 9] > > Internet-Draft TCP Security > > May 2010 > > > > After sending the challenge ACK, TCP MUST drop the > unacceptable > > segment and stop processing the incoming packet > > further. Further > > segments destined to this connection will be processed > > as normal. > > > > > > > > > > > > > > 3) If the RST bit is set and the sequence number does not exactly > > match the next expected sequence value, yet is within > > the current > > receive window (RCV.NXT < SEG.SEQ =3D< > RCV.NXT+RCV.WND), TCP MUST > > send an acknowledgment (challenge ACK): > > Again this is the RFC 793 language, we haven't changed it. (Pl see RFC > 793 page 69, acceptability checks) > > > > > > > The challenge ACK is what matters and you should be looking into. > > > > > > > > > > > > > > > > > Ramaiah, et al. Expires November 4, 2010 > > [Page 9] > > > > Internet-Draft TCP Security > > May 2010 > > > > > > After sending the challenge ACK, TCP MUST silently drop > > the in window > > but not exact match segment and stop processing it. > Additional > > segments destined to this connection MUST be processed > > as normal. > > > > That last line is really extraneous. You don't say what > > happens to the packets before this event I am not sure you > > have to say handle the next packet per normal behavior;) The > > authors need to explain exactly what that challenge ACK looks like. > > I think it is the same 4 tuple, ack =3D last sent ack, seq =3D > > last sent seq (no data). > > Well, you can go on explaining each and everything, we had chosen to > stick to the RFC 793 language, in other words, the intention is affect > only the portion of RFC 793 and rest is exactly what RFC 793 > says. If we > add additional text that would really add to the confusion. This was > atleast the rationale and WG had agreed to such thinking w.r.t this > draft. > > > > > > > > > > > Still on page 9. > > In all states except SYN-SENT, all reset (RST) segments are > validated > > by checking their SEQ-fields [sequence numbers]. A reset > > is valid if > > its sequence number exactly matches the next expected sequence > > number. If the RST arrives and its sequence number > field does NOT > > match the next expected sequence number but is within the window, > > then the receiver should generate an ACK. In all other > cases where > > the SEQ-field does not match and is outside the window, > > the receiver > > MUST silently discard the segment. > > > > > > Should be: > > In all states except SYN-SENT, all reset (RST) segments are > validated > > by checking their ACK-fields [acknowledgement numbers]. A > > Incorrect. It is the sequence number that needs to be validated first, > please read RFC 793. (Page 37 RFC 793) > > > reset is valid if > > its acknowledgement number exactly matches the last sent > > sequence number + the data length sent. > > If the RST arrives and its acknowledgement number field does NOT > > match the last sent sequence number + the data length sent > > but is within the window, > > then the receiver SHOULD (or MUST?) generate an ACK. In > > all other cases where > > the ACK-field does not match and is outside the window, > > the receiver > > MUST silently discard the segment. > > > > > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > > Not sure which of the above caused confusion ;-) > > -Anantha > > This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From ananth@cisco.com Tue May 18 14:49:40 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730B93A69BD; Tue, 18 May 2010 14:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Mpspnrbtrt; Tue, 18 May 2010 14:49:39 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 77C983A698F; Tue, 18 May 2010 14:49:39 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACqo8kurR7Ht/2dsb2JhbACeBXGkbpluhRAEg0A X-IronPort-AV: E=Sophos;i="4.53,257,1272844800"; d="scan'208";a="256615717" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 18 May 2010 21:49:31 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4ILnV87007601; Tue, 18 May 2010 21:49:32 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 May 2010 14:49:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 May 2010 14:49:30 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5809AB7A5B@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt Thread-Index: Acq5q9zzpcVWcYT4S5OmJS6FWMliJg9DCCygAAH3UGAABKS9MAAARewQ References: <201003012159.WAA15069@TR-Sys.de><4B8C70C0.8090708@gont.com.ar> <0C53DCFB700D144284A584F54711EC5809AB79BB@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Smith, Donald" , , "The IESG" X-OriginalArrivalTime: 18 May 2010 21:49:31.0613 (UTC) FILETIME=[FF5A70D0:01CAF6D3] Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 21:49:40 -0000 =20 > -----Original Message----- > From: Smith, Donald [mailto:Donald.Smith@qwest.com]=20 > Sent: Tuesday, May 18, 2010 2:39 PM > To: Anantha Ramaiah (ananth); 'tcpm@ietf.org'; 'The IESG' > Subject: RE: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt >=20 > Won't this break syn cookies since the server doesn't keep=20 > state on the original syn's sequence number? Which mitigation are you referring to ? IMO, none of them should have any *new* problems with SYN cookies. For example take the case of SYN mitigation, it increases the scope iof RFC 793 i.e, earlier RFC 793 was sending RST if in window else send ACK, here we are saying send ACK in all cases, this way you challenge the SYN in both the cases. -Anantha From wwwrun@rfc-editor.org Tue May 18 09:33:36 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557023A6A40 for ; Tue, 18 May 2010 09:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_50=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Upi8yNfrjfj for ; Tue, 18 May 2010 09:33:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 5EBB93A6A9A for ; Tue, 18 May 2010 09:27:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 29C0AE065C; Tue, 18 May 2010 09:27:38 -0700 (PDT) To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu, ietfdbh@comcast.net, lars.eggert@nokia.com, weddy@grc.nasa.gov, david.borman@windriver.com From: RFC Errata System Message-Id: <20100518162738.29C0AE065C@rfc-editor.org> Date: Tue, 18 May 2010 09:27:38 -0700 (PDT) X-Mailman-Approved-At: Thu, 20 May 2010 08:38:11 -0700 Cc: nmalykh@protocols.ru, tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Technical Errata Reported] RFC5681 (2269) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 16:33:36 -0000 The following errata report has been submitted for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5681&eid=2269 -------------------------------------- Type: Technical Reported by: Nikolai Malykh Section: 7 Original Text ------------- The description of fast retransmit and fast recovery has been clarified, and the use of Limited Transmit [RFC3042] is now recommended. Corrected Text -------------- The description of fast retransmit and fast recovery has been clarified. Notes ----- Really using of Limited Transmit [RFC3042] is not recommended anywhere in RFC 5681. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From mallman@icir.org Thu May 20 12:59:15 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18CD3A6A51 for ; Thu, 20 May 2010 12:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.735 X-Spam-Level: X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y60WBiX8gmvP for ; Thu, 20 May 2010 12:59:15 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id 158CF3A6846 for ; Thu, 20 May 2010 12:59:15 -0700 (PDT) Received: from lawyers.icir.org (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o4KJvJlu003204; Thu, 20 May 2010 12:57:19 -0700 (PDT) Received: from lawyers.icir.org (www.obdev.at [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1C0B311C9435; Thu, 20 May 2010 15:57:19 -0400 (EDT) To: RFC Errata System From: Mark Allman In-Reply-To: <20100518162738.29C0AE065C@rfc-editor.org> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Lawyers, Guns and Money MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37918-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 20 May 2010 15:57:19 -0400 Sender: mallman@icir.org Message-Id: <20100520195719.1C0B311C9435@lawyers.icir.org> Cc: nmalykh@protocols.ru, tcpm@ietf.org, david.borman@windriver.com, vern@icir.org, eblanton@cs.purdue.edu, weddy@grc.nasa.gov Subject: Re: [tcpm] [Technical Errata Reported] RFC5681 (2269) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 19:59:15 -0000 ----------ma37918-1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I request this report be rejected. It is simply wrong. On page 9 of RFC 5681: 1. On the first and second duplicate ACKs received at a sender, a TCP SHOULD send a segment of previously unsent data per [RFC3042] provided that the receiver's advertised window allows, the total [...] That, in effect, says we recommend using Limited Transmit by saying you SHOULD do what [RFC3042] says to do (send on the first and second dups). SHOULD and RECOMMENDED are basically equivalent. Even if the words "we recommend Limited Transmit" don't appear in the document this has the same effect. Further, the note in question is in a non-normative list of changes so this is at best needless nit picking. allman ----------ma37918-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkv1lB4ACgkQWyrrWs4yIs4ZGACeP5nHOZqWGWv48PEBeyx2Df4O n6wAoJtOZmKfiZGI3eBCZJqKsXs81YYa =KWib -----END PGP SIGNATURE----- ----------ma37918-1-- From lars.eggert@nokia.com Fri May 21 01:29:25 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D60E3A6D39 for ; Fri, 21 May 2010 01:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAY5tSkTbKlU for ; Fri, 21 May 2010 01:29:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 587943A7F50 for ; Thu, 20 May 2010 22:58:34 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4L5wAmO017552; Fri, 21 May 2010 00:58:22 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 08:58:07 +0300 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 May 2010 08:58:07 +0300 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4L5w67s001019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 08:58:06 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/signed; boundary=Apple-Mail-25--238469446; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Fri, 21 May 2010 08:57:53 +0300 Message-Id: <3DD98545-6C59-489B-957F-C97B87B32FF7@nokia.com> References: <20100518162738.29C0AE065C@rfc-editor.org> To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" X-Mailer: Apple Mail (2.1078) X-OriginalArrivalTime: 21 May 2010 05:58:07.0096 (UTC) FILETIME=[9591A780:01CAF8AA] X-Nokia-AV: Clean Cc: "nmalykh@protocols.ru" , "tcpm@ietf.org" Subject: Re: [tcpm] [Technical Errata Reported] RFC5681 (2269) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 08:29:25 -0000 --Apple-Mail-25--238469446 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It looks like we have consensus. I rejected the errata. Thanks for the = quick resolution. Lars On 2010-5-18, at 20:02, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] = wrote: > I think this errata should be rejected, as 3042 behavior > is referenced as a SHOULD on page 9, when implementing > fast retransmit + fast recovery, and this material is > new for 5681 (it was not part of 2581), but I think we > need to discuss this on the TCPM list and let our ADs > know how to handle it. >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Tuesday, May 18, 2010 12:28 PM >> To: mallman@icir.org; vern@icir.org; eblanton@cs.purdue.edu; >> ietfdbh@comcast.net; lars.eggert@nokia.com; weddy@grc.nasa.gov; >> david.borman@windriver.com >> Cc: nmalykh@protocols.ru; tcpm@ietf.org; rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC5681 (2269) >>=20 >>=20 >> The following errata report has been submitted for RFC5681, >> "TCP Congestion Control". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5681&eid=3D2269 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Nikolai Malykh >>=20 >> Section: 7 >>=20 >> Original Text >> ------------- >> The description of fast retransmit and fast recovery has been >> clarified, and the use of Limited Transmit [RFC3042] is now >> recommended. >>=20 >>=20 >> Corrected Text >> -------------- >> The description of fast retransmit and fast recovery has been >> clarified. >>=20 >>=20 >> Notes >> ----- >> Really using of Limited Transmit [RFC3042] is not recommended = anywhere >> in RFC 5681. >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC5681 (draft-ietf-tcpm-rfc2581bis-07) >> -------------------------------------- >> Title : TCP Congestion Control >> Publication Date : September 2009 >> Author(s) : M. Allman, V. Paxson, E. Blanton >> Category : DRAFT STANDARD >> Source : TCP Maintenance and Minor Extensions >> Area : Transport >> Stream : IETF >> Verifying Party : IESG --Apple-Mail-25--238469446 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDUyMTA1NTc1NFowIwYJKoZIhvcNAQkEMRYEFECjKqoZsJWRRCYPHTqYMEXDX5kbMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCmPyG8MrssebpDym0cf8VniNNAgCxN7KV1+yEvREKbYPJAuy4xtzdPUKBRJ5uGZBmtsZXx TOX88yNqWxEQr5c98ZALB91wa75A0qbj34WjEmL/3p63u9l8UmMX9yoeLKo+3RsAl4M7728yn5v4 8Wl868tThDp4aKi9uSa3WAuJHKcNnFl7ECXkESmdvSpWWfI6P26NfSBRGDuFHzIBdydgHygZDo0B xgG2BTTwdIx/kMor7wE735tdDIWOosi/vU3Cmk4bQ+RfBw6vEMb9B1XkM6D/9CRJXzoBO9xEF/zJ Rettch76s9Ue8F5mGg2/+nsTmoeLQsz1GXOU1YHdQl4nAAAAAAAA --Apple-Mail-25--238469446-- From vern@icir.org Thu May 20 21:08:03 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90D83A7E91 for ; Thu, 20 May 2010 21:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXcqFXtiYdtA for ; Thu, 20 May 2010 21:08:02 -0700 (PDT) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id E4A0C3A74BA for ; Thu, 20 May 2010 20:02:13 -0700 (PDT) Received: from akane.icir.org (akane.icir.org [192.150.187.87]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id o4L316vE007048; Thu, 20 May 2010 20:01:06 -0700 Message-Id: <201005210301.o4L316vE007048@pork.ICSI.Berkeley.EDU> To: mallman@icir.org In-Reply-To: <20100520195719.1C0B311C9435@lawyers.icir.org> (Thu, 20 May 2010 15:57:19 EDT). Date: Thu, 20 May 2010 20:01:06 -0700 From: Vern Paxson X-Mailman-Approved-At: Fri, 21 May 2010 08:09:15 -0700 Cc: nmalykh@protocols.ru, tcpm@ietf.org, david.borman@windriver.com, eblanton@cs.purdue.edu, weddy@grc.nasa.gov, RFC Errata System Subject: Re: [tcpm] [Technical Errata Reported] RFC5681 (2269) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 04:08:04 -0000 > I request this report be rejected. > > It is simply wrong. On page 9 of RFC 5681: (I read this independently and came to the exact same conclusion.) Vern From root@core3.amsl.com Tue May 25 16:15:07 2010 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1EC6A3A6E00; Tue, 25 May 2010 16:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100525231506.1EC6A3A6E00@core3.amsl.com> Date: Tue, 25 May 2010 16:15:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 23:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Support for Stronger Error Detection Codes in TCP for Jumbo Frames Author(s) : A. Biswas Filename : draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt Pages : 10 Date : 2010-05-25 There is a class of data serving protocols and applications that cannot tolerate undetected data corruption on the wire. Data corruption could occur at the source in software, in the network interface card, out on the link, on intermediate routers or at the destination network interface card or node. The Ethernet CRC and the 16-bit checksum in the TCP/UDP headers are used to detect data errors. Most applications rely on these checksums to detect data corruptions and do not use any checksums or CRC checks at their level. Research has shown that the TCP/UDP checksums are catching a significant number of errors, however, the research suggests that one packet in 10 billion will have an error that goes undetected for Ethernet MTU frames (MTU of 1500). Under certain situations, "bad" hosts can introduce undetected errors at a much higher frequency and order. With the use of Jumbo frames on the rise, and therefore more data bits on the wire that could be corrupted, the current 16-bit TCP/UDP checksum, or the Ethernet 32-bit CRC are simply not sufficient for detecting errors. This document specifies a proposal to use stronger checksum algorithms for TCP Jumbo Frames for IPv4 and IPv6 networks. The Castagnoli CRC 32C algorithm used in iSCSI and SCTP is proposed as the error detection code of choice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-25160418.I-D@ietf.org> --NextPart-- From wesley.m.eddy@nasa.gov Tue May 25 19:20:39 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6861F3A67B7 for ; Tue, 25 May 2010 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm+tz53pc--s for ; Tue, 25 May 2010 19:19:56 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id E601A3A67A3 for ; Tue, 25 May 2010 19:19:54 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 5C1C910838F for ; Tue, 25 May 2010 21:19:46 -0500 (CDT) Received: from ndjshub01.ndc.nasa.gov (ndjshub01-pub.ndc.nasa.gov [198.117.1.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id o4Q2JkuC017582 for ; Tue, 25 May 2010 21:19:46 -0500 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.1.160]) with mapi; Tue, 25 May 2010 21:19:46 -0500 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "tcpm@ietf.org" Date: Tue, 25 May 2010 21:17:29 -0500 Thread-Topic: [tcpm] I-D Action:draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt Thread-Index: Acr8YDCU69f7609eRNOe85xLgVDwaQAGWb4s Message-ID: References: <20100525231506.1EC6A3A6E00@core3.amsl.com> In-Reply-To: <20100525231506.1EC6A3A6E00@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-05-25_02:2010-02-06, 2010-05-25, 2010-05-25 signatures=0 Subject: Re: [tcpm] I-D Action:draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 02:20:40 -0000 FYI - This I-D was accidentally posted as a WG document rather than an indi= vidual submission. We are working to have the posting corrected. Thanks f= or bearing with this :). ________________________________________ From: tcpm-bounces@ietf.org [tcpm-bounces@ietf.org] On Behalf Of Internet-D= rafts@ietf.org [Internet-Drafts@ietf.org] Sent: Tuesday, May 25, 2010 7:15 PM To: i-d-announce@ietf.org Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-anumita-tcp-stronger-checksu= m-00.txt 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 Worki= ng Group of the IETF. Title : Support for Stronger Error Detection Codes in TCP= for Jumbo Frames Author(s) : A. Biswas Filename : draft-ietf-tcpm-anumita-tcp-stronger-checksum-00.= txt Pages : 10 Date : 2010-05-25 There is a class of data serving protocols and applications that cannot tolerate undetected data corruption on the wire. Data corruption could occur at the source in software, in the network interface card, out on the link, on intermediate routers or at the destination network interface card or node. The Ethernet CRC and the 16-bit checksum in the TCP/UDP headers are used to detect data errors. Most applications rely on these checksums to detect data corruptions and do not use any checksums or CRC checks at their level. Research has shown that the TCP/UDP checksums are catching a significant number of errors, however, the research suggests that one packet in 10 billion will have an error that goes undetected for Ethernet MTU frames (MTU of 1500). Under certain situations, "bad" hosts can introduce undetected errors at a much higher frequency and order. With the use of Jumbo frames on the rise, and therefore more data bits on the wire that could be corrupted, the current 16-bit TCP/UDP checksum, or the Ethernet 32-bit CRC are simply not sufficient for detecting errors. This document specifies a proposal to use stronger checksum algorithms for TCP Jumbo Frames for IPv4 and IPv6 networks. The Castagnoli CRC 32C algorithm used in iSCSI and SCTP is proposed as the error detection code of choice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-anumita-tcp-stronger-ch= ecksum-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.= From Anumita.Biswas@netapp.com Wed May 26 16:07:12 2010 Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 927C93A6A56 for ; Wed, 26 May 2010 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6cQr2xCKSpF for ; Wed, 26 May 2010 16:07:11 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 877023A6A55 for ; Wed, 26 May 2010 16:07:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,307,1272870000"; d="scan'208,217";a="368219007" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 26 May 2010 16:07:02 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o4QN72n5008439 for ; Wed, 26 May 2010 16:07:02 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 May 2010 16:07:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAFD28.266BF0F2" Date: Wed, 26 May 2010 16:07:01 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Adding Support for Stronger Error Detection Codes in TCP for Jumbo Frames Thread-Index: Acr9KCZ0o2Y9QNsfRSuLRUX6CzqqWQ== From: "Biswas, Anumita" To: X-OriginalArrivalTime: 26 May 2010 23:07:02.0555 (UTC) FILETIME=[26D5DEB0:01CAFD28] Subject: [tcpm] Adding Support for Stronger Error Detection Codes in TCP for Jumbo Frames X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 23:07:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAFD28.266BF0F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 An internet-draft on "Support for Stronger Error Detection Codes in TCP for Jumbo Frames" has been submitted.=20 =20 It can be found at http://www.ietf.org/id/draft-anumita-tcpm-stronger-checksum-00.txt =20 =20 Any feedback, discussion and comments would be highly appreciated. =20 Many thanks, Anumita Biswas Abstract: There is a class of data serving protocols and applications that cannot tolerate undetected data corruption on the wire. Data corruption could occur at the source in software, in the network interface card, out on the link, on intermediate routers or at the destination network interface card or node. The Ethernet CRC and the 16-bit checksum in the TCP/UDP headers are used to detect data errors. Most applications rely on these checksums to detect data corruptions and do not use any checksums or CRC checks at their level. Research has shown that the TCP/UDP checksums are catching a significant number of errors, however, the research suggests that one packet in 10 billion will have an error that goes undetected for Ethernet MTU frames (MTU of 1500). Under certain situations, "bad" hosts can introduce undetected errors at a much higher frequency and order. With the use of Jumbo frames on the rise, and therefore more data bits on the wire that could be corrupted, the current 16-bit TCP/UDP checksum, or the Ethernet 32-bit CRC are simply not sufficient for detecting errors. This document specifies a proposal to use stronger checksum algorithms for TCP Jumbo Frames for IPv4 and IPv6 networks. The Castagnoli CRC 32C algorithm used in iSCSI and SCTP is proposed as the error detection code of choice. ------_=_NextPart_001_01CAFD28.266BF0F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hello,
 
An = internet-draft on=20 "Support for Stronger Error Detection Codes in TCP for Jumbo Frames" has = been=20 submitted.
 
It can = be found at=20 http://www.ietf.org/id/draft-anumita-tcpm-stronger-checksum-00.t= xt
 
Any=20 feedback, discussion and comments would be highly=20 appreciated.
 
Many=20 thanks,
Anumita=20 Biswas
Abstract:
   There is a class of =
data serving protocols and applications that
   cannot tolerate undetected data corruption on the wire.  Data
   corruption could occur at the source in software, in the network
   interface card, out on the link, on intermediate routers or at the
   destination network interface card or node.  The Ethernet CRC and the
   16-bit checksum in the TCP/UDP headers are used to detect data
   errors.  Most applications rely on these checksums to detect data
   corruptions and do not use any checksums or CRC checks at their
   level.  Research has shown that the TCP/UDP checksums are catching a
   significant number of errors, however, the research suggests that one
   packet in 10 billion will have an error that goes undetected for
   Ethernet MTU frames (MTU of 1500).  Under certain situations, "bad"
   hosts can introduce undetected errors at a much higher frequency and
   order.  With the use of Jumbo frames on the rise, and therefore more
   data bits on the wire that could be corrupted, the current 16-bit
   TCP/UDP checksum, or the Ethernet 32-bit CRC are simply not
   sufficient for detecting errors.  This document specifies a proposal
   to use stronger checksum algorithms for TCP Jumbo Frames for IPv4 and
   IPv6 networks.  The Castagnoli CRC 32C algorithm used in iSCSI and
   SCTP is proposed as the error detection code of choice.
------_=_NextPart_001_01CAFD28.266BF0F2--