From internet-drafts@ietf.org Sun Dec 4 22:42:07 2011 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 3258C11E809C; Sun, 4 Dec 2011 22:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 5MBVSvOfZqzb; Sun, 4 Dec 2011 22:42:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FE511E80A4; Sun, 4 Dec 2011 22:42:06 -0800 (PST) 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: 3.64 Message-ID: <20111205064206.14083.44914.idtracker@ietfa.amsl.com> Date: Sun, 04 Dec 2011 22:42:06 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc3782-bis-04.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: Mon, 05 Dec 2011 06:42:07 -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 : The NewReno Modification to TCP's Fast Recovery Algorithm Author(s) : Tom Henderson Sally Floyd Andrei Gurtov Yoshifumi Nishida Filename : draft-ietf-tcpm-rfc3782-bis-04.txt Pages : 13 Date : 2011-12-04 RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc3782-bis-04.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-rfc3782-bis-04.txt From hkchu@google.com Thu Dec 8 00:17:50 2011 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 59C0221F8B0E for ; Thu, 8 Dec 2011 00:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 qdEs8oeHBol9 for ; Thu, 8 Dec 2011 00:17:49 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9225021F8B04 for ; Thu, 8 Dec 2011 00:17:49 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so2316670wgb.13 for ; Thu, 08 Dec 2011 00:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=GNgcSEEjgadaq9rjuweKCu2Jmu7PWy46vyj/MbTVbAc=; b=ZKzIsZr+7B9z9ktCJX4qukSJDrAvaSgn2pJw+L2BeT0bReKVQkZ/x2k1clh7uZqQwe LIiYSsBakrNdwnaAs2Xw== Received: by 10.180.0.100 with SMTP id 4mr3140841wid.48.1323332268603; Thu, 08 Dec 2011 00:17:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.0.100 with SMTP id 4mr3140832wid.48.1323332268516; Thu, 08 Dec 2011 00:17:48 -0800 (PST) Received: by 10.227.195.142 with HTTP; Thu, 8 Dec 2011 00:17:48 -0800 (PST) In-Reply-To: <20111208080728.20148.13791.idtracker@ietfa.amsl.com> References: <20111208080728.20148.13791.idtracker@ietfa.amsl.com> Date: Thu, 8 Dec 2011 00:17:48 -0800 Message-ID: From: Jerry Chu To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=bcaec52c6233c8e62404b3904d3e X-System-Of-Record: true Subject: [tcpm] Fwd: New Version Notification for draft-cheng-tcpm-fastopen-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, 08 Dec 2011 08:17:50 -0000 --bcaec52c6233c8e62404b3904d3e Content-Type: text/plain; charset=ISO-8859-1 The main change is a new section 8 discussing TFO's Applicability. This hopefully answers some questions raised by Joe Touch and others on TFO vs P-HTTP, short vs long lived connections, TFO's potential benefit and its limitation,..., etc. Comments are welcome. Thanks, Jerry ---------- Forwarded message ---------- From: Date: Thu, Dec 8, 2011 at 12:07 AM Subject: New Version Notification for draft-cheng-tcpm-fastopen-02.txt To: hkchu@google.com Cc: hkchu@google.com, ycheng@google.com, sivasankar@cs.ucsd.edu, arvind@google.com A new version of I-D, draft-cheng-tcpm-fastopen-02.txt has been successfully submitted by Jerry Chu and posted to the IETF repository. Filename: draft-cheng-tcpm-fastopen Revision: 02 Title: TCP Fast Open Creation date: 2011-12-08 WG ID: Individual Submission Number of pages: 21 Abstract: TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology The IETF Secretariat --bcaec52c6233c8e62404b3904d3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The main change is a new section 8 discussing TFO's Applicability. This= hopefully=A0answers some questions raised by Joe Touch and others on
T= FO vs P-HTTP, short vs long lived connections, TFO's potential benefit<= /div>
and its limitation,..., etc.=A0Comments=A0are welcome.

<= /div>
Thanks,

Jerry

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Dec 8, 2011 at 12:07 AM
Subject: New Version Notification for= draft-cheng-tcpm-fastopen-02.txt
To: hkchu@google.com
Cc: hkchu@goo= gle.com, ycheng@google.com, sivasankar@cs.ucsd.edu, arvind@google.com


A new version of I-D, draft-cheng-tcpm-fastopen-02.txt has been suc= cessfully submitted by Jerry Chu and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-cheng-tcpm-fastopen
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 TCP Fast Open
Creation date: =A0 2011-12-08
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 21

Abstract:
=A0 TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK =A0 packets and consumed by the receiving end during the initial
=A0 connection handshake, thus providing a saving of up to one full round<= br> =A0 trip time (RTT) compared to standard TCP requiring a three-way
=A0 handshake (3WHS) to complete before data can be exchanged.

Terminology



The IETF Secretariat

--bcaec52c6233c8e62404b3904d3e-- From wwwrun@rfc-editor.org Thu Dec 8 12:08:51 2011 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 39E7921F8B24; Thu, 8 Dec 2011 12:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, NO_RELAYS=-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 AsdJhprtV8aH; Thu, 8 Dec 2011 12:08:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1C79E21F84C9; Thu, 8 Dec 2011 12:08:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2DF61B1E002; Thu, 8 Dec 2011 12:08:11 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111208200811.2DF61B1E002@rfc-editor.org> Date: Thu, 8 Dec 2011 12:08:11 -0800 (PST) Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] RFC 6429 on TCP Sender Clarification for Persist Condition 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, 08 Dec 2011 20:08:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6429 Title: TCP Sender Clarification for Persist Condition Author: M. Bashyam, M. Jethanandani, A. Ramaiah Status: Informational Stream: IETF Date: December 2011 Mailbox: mbashyam@ocarinanetworks.com, mjethanandani@gmail.com, ananth@cisco.com Pages: 7 Characters: 14280 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-persist-07.txt URL: http://www.rfc-editor.org/rfc/rfc6429.txt This document clarifies the Zero Window Probes (ZWPs) described in RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified in RFC 1122. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Fri Dec 16 13:49:11 2011 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 C8BBA11E80AB; Fri, 16 Dec 2011 13:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 eGRxKchlXCVo; Fri, 16 Dec 2011 13:49:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487211E8089; Fri, 16 Dec 2011 13:49:11 -0800 (PST) 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: 3.64p1 Message-ID: <20111216214911.16065.94022.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2011 13:49:11 -0800 Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc1948bis-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, 16 Dec 2011 21:49:11 -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 : Defending Against Sequence Number Attacks Author(s) : Fernando Gont Steven M. Bellovin Filename : draft-ietf-tcpm-rfc1948bis-02.txt Pages : 13 Date : 2011-12-16 This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc1948bis-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-rfc1948bis-02.txt From mattmathis@google.com Mon Dec 19 15:07:02 2011 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 3900321F8469 for ; Mon, 19 Dec 2011 15:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 RUb9scqwDwqr for ; Mon, 19 Dec 2011 15:07:01 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E03A21F8468 for ; Mon, 19 Dec 2011 15:07:01 -0800 (PST) Received: by eekc14 with SMTP id c14so4587402eek.31 for ; Mon, 19 Dec 2011 15:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=9HEHim2/M9lpWPiwJLxVbonaMc7Qhy27Aju+3EH08I0=; b=RpP7EvVCh3RlF3QO9B5hksHJNtpCVwxSQOn+5721xFKFocy52dvuHNKk5/55WEuLP1 qsuVMfHfJoZtG0wuCL1g== Received: by 10.213.19.9 with SMTP id y9mr3006154eba.54.1324336020300; Mon, 19 Dec 2011 15:07:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.19.9 with SMTP id y9mr3006146eba.54.1324336020037; Mon, 19 Dec 2011 15:07:00 -0800 (PST) Received: by 10.213.11.19 with HTTP; Mon, 19 Dec 2011 15:06:59 -0800 (PST) In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F03AEDD@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> <4EC5C44E.1070000@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> <012C3117EDDB3C4781FD802A8C27DD4F03AEDD@SACEXCMBX02-PRD.hq.netapp.com> Date: Mon, 19 Dec 2011 15:06:59 -0800 Message-ID: From: Matt Mathis To: "Scheffenegger, Richard" X-System-Of-Record: true Content-Type: multipart/alternative; boundary=0015174bdf0a09a1f704b47a021d Cc: David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] Timestamp semantic change 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: Mon, 19 Dec 2011 23:07:02 -0000 --0015174bdf0a09a1f704b47a021d Content-Type: text/plain; charset=ISO-8859-1 NO - this is not correct! Sorry I did not catch this sooner. On Fri, Nov 25, 2011 at 12:59 AM, Scheffenegger, Richard wrote: > > Hi Michael, > > You are absolutely correct. In the context of RFC1323,the sole purpose of > Timestamps (to the sender) is to deliver a conservative lower bound of the > RTT. This is again used for the single purpose of calculating the RTO on > the sender side. > The sole purpose of 1323 timestamps was the Protection Against Wrapped Sequence (PAWS) algorithm, which essentially treats the timestamps as an extension to the MSB of the sequence number. Other uses are secondary. (Furthermore it was known at the time that the PAWS requirements reduce the usefulness for RTT measurement, and that this was implicit from the requirements). My mental model of PAWS is to compute longseq = 4294967296*timestamp+seg.seq and enforce the standard in window checks on both seq and longseq. This requires the hard constraint that longseq be absolutely monotonic, which in turn causes constraints on when you are permitted to (or must) update the echoed timestamp. I admit that I have never worked through the details of PAWS myself, so your algorithm might still be ok. However failing to meet the constraints imposed by PAWS will cause odd TCP failures... I believe that one of the important fixes in 1323bis was about some corner case in exactly this area. Dave, do you care to comment? Also, as far as I know, nobody has worked though possible interactions (or opportunities) between PAWS/timestamps and SACK (or FACK). Or perhaps you are the first! :-) Thanks, --MM-- --0015174bdf0a09a1f704b47a021d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable NO - this is not correct! =A0 Sorry I did not catch this sooner.

On Fri, Nov 25, 2011 at 12:59 AM, Scheffenegger, R= ichard <rs@netapp.com= > wrote:

Hi Michael,

You are absolutely correct. In the context of RFC1323,the sole purpose of T= imestamps (to the sender) is to deliver a conservative lower bound of the R= TT. This is again used for the single purpose of calculating the RTO on the= sender side.

The sole purpose of 1323 timestamps was th= e Protection Against=A0Wrapped=A0Sequence (PAWS) algorithm, which=A0essenti= ally=A0treats the timestamps as an=A0extension=A0to the MSB of the sequence= number. =A0Other uses are secondary. =A0(Furthermore it was known at the t= ime that the PAWS requirements reduce the usefulness for RTT measurement, a= nd that this was implicit from the requirements).=A0

My mental model of PAWS is to compute longseq =3D=A0429= 4967296*timestamp+seg.seq and enforce the standard in window checks on both= seq and longseq. =A0This requires the hard constraint that longseq be abso= lutely monotonic,=A0which=A0in turn causes constraints on when you are perm= itted to (or must) update the echoed timestamp.

I admit that I have never worked through the details of= PAWS myself, so your algorithm might still be ok. =A0However failing to me= et the constraints imposed by PAWS will cause odd TCP failures...

I believe that one of the important fixes in 1323bis was abo= ut some corner case in exactly this area.

Dave, do= you care to comment?

Also, as far as I know, nobo= dy has worked though possible interactions (or=A0opportunities)=A0between P= AWS/timestamps and SACK (or FACK). =A0Or perhaps you are the first! =A0:-)<= /div>

Thanks,
--MM--

=A0
--0015174bdf0a09a1f704b47a021d-- From L.Wood@surrey.ac.uk Mon Dec 19 20:09:46 2011 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 6BD8421F8669 for ; Mon, 19 Dec 2011 20:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] 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 vBkviMSKZBVn for ; Mon, 19 Dec 2011 20:09:45 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7869F21F85C7 for ; Mon, 19 Dec 2011 20:09:44 -0800 (PST) Received: from [195.245.230.131:39878] by server-6.bemta-3.messagelabs.com id 41/3B-29222-68A00FE4; Tue, 20 Dec 2011 04:09:42 +0000 X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-78.messagelabs.com!1324354181!7095565!1 X-Originating-IP: [131.227.200.39] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14723 invoked from network); 20 Dec 2011 04:09:42 -0000 Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-5.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 20 Dec 2011 04:09:42 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.208]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Tue, 20 Dec 2011 04:09:41 +0000 From: To: Date: Tue, 20 Dec 2011 04:09:39 +0000 Thread-Topic: [tcpm] Timestamp semantic change Thread-Index: Acy+zTJdHWmmR8m2TsCIGx3omrKvtg== Message-ID: References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> <4EC5C44E.1070000@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> <012C3117EDDB3C4781FD802A8C27DD4F03AEDD@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dab@weston.borman.com, tcpm@ietf.org, L.Wood@surrey.ac.uk Subject: Re: [tcpm] Timestamp semantic change 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, 20 Dec 2011 04:09:46 -0000 Sigh, You're both wrong. It's both. > The sole purpose of 1323 timestamps was the Protection Against Wrapped Se= quence (PAWS) algorithm, >=20 Read the expired RFC1323bis internet-draft: http://www.kohala.com/start/tcplw-extensions.txt "However, as RFC-1323 implied but did not clearly state, the RTTM mechanism replaces Karn's algorithm." [..] Overriding the Karn algorithm was implied by the following statement on page 14 of RFC-1323, which was independent of whether or not the new data being acknowledged has been retransmitted: "A TSecr value received in a segment is used to update the averaged RTT measurement only if the segment acknowledges some new data, i.e., only if it advances the left edge of the send window." On 19 Dec 2011, at 23:06, Matt Mathis wrote: > NO - this is not correct! Sorry I did not catch this sooner. >=20 > On Fri, Nov 25, 2011 at 12:59 AM, Scheffenegger, Richard = wrote: >=20 > Hi Michael, >=20 > * You are absolutely correct. In the context of RFC1323,the sole purpose = of Timestamps (to the sender) > * is to deliver a conservative lower bound of the RTT. This is again used= for the single purpose of > * calculating the RTO on the sender side. >=20 > The sole purpose of 1323 timestamps was the Protection Against Wrapped Se= quence (PAWS) algorithm, which essentially treats the timestamps as an exte= nsion to the MSB of the sequence number. Other uses are secondary. (Furth= ermore it was known at the time that the PAWS requirements reduce the usefu= lness for RTT measurement, and that this was implicit from the requirements= ).=20 >=20 > My mental model of PAWS is to compute longseq =3D 4294967296*timestamp+se= g.seq and enforce the standard in window checks on both seq and longseq. T= his requires the hard constraint that longseq be absolutely monotonic, whic= h in turn causes constraints on when you are permitted to (or must) update = the echoed timestamp. >=20 > I admit that I have never worked through the details of PAWS myself, so y= our algorithm might still be ok. However failing to meet the constraints i= mposed by PAWS will cause odd TCP failures... >=20 > I believe that one of the important fixes in 1323bis was about some corne= r case in exactly this area. >=20 > Dave, do you care to comment? >=20 > Also, as far as I know, nobody has worked though possible interactions (o= r opportunities) between PAWS/timestamps and SACK (or FACK). Or perhaps yo= u are the first! :-) >=20 > Thanks, > --MM-- >=20 From rs@netapp.com Tue Dec 20 05:00:06 2011 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 C226F21F8B04 for ; Tue, 20 Dec 2011 05:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 WCatHslHxwha for ; Tue, 20 Dec 2011 05:00:05 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B02AC21F84A7 for ; Tue, 20 Dec 2011 05:00:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.71,382,1320652800"; d="scan'208";a="609045359" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Dec 2011 04:59:50 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id pBKCxmC1016090; Tue, 20 Dec 2011 04:59:48 -0800 (PST) Received: from VMWEXCEHT01-PRD.hq.netapp.com ([10.106.76.239]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 04:59:44 -0800 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.211]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.01.0355.002; Tue, 20 Dec 2011 04:59:38 -0800 From: "Scheffenegger, Richard" To: "L.Wood@surrey.ac.uk" , "mattmathis@google.com" Thread-Topic: [tcpm] Timestamp semantic change Thread-Index: AcyliOMl3xGQqdUxSpiQkPNjMRBQtgAVNJ0AAVgsewAAA4YioATmXcWAAAqSDYAAAKdfoA== Date: Tue, 20 Dec 2011 12:59:37 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F057D88@SACEXCMBX02-PRD.hq.netapp.com> References: <012C3117EDDB3C4781FD802A8C27DD4F036D2E@SACEXCMBX02-PRD.hq.netapp.com> <4EC5C44E.1070000@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C0693AF0C@SLFSNX.rcs.alcatel-research.de> <012C3117EDDB3C4781FD802A8C27DD4F03AEDD@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: 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 X-OriginalArrivalTime: 20 Dec 2011 12:59:44.0139 (UTC) FILETIME=[3E8B95B0:01CCBF17] Cc: "dab@weston.borman.com" , "tcpm@ietf.org" Subject: Re: [tcpm] Timestamp semantic change 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, 20 Dec 2011 13:00:06 -0000 Thanks Matt and Lloyd for continuing the discussion! I believe my proposal still addresses both PAWS and RTTM (or more specifica= lly, conservative RTO calculation). The monotonic increase of the (unmaske= d part) of the timestamps will be maintained. The main change is, that if a= sender may choose to flag some bits masked, the effective "extended" seque= nce number will have fewer bits (32 - mask) + 32 bits instead of 64 bits...= =20 The sender must never send a timestamp value that is smaller (excluding the= masked portion) than any previously sent timestamp. Therefore, the PAWS al= gorithm would continue to work as it works now... The only exception of course being all timestamp bits masked, but that real= ly makes the timestamp field a (unprotected) 2-byte side channel to TCP wit= hout yet-another-option :) (Not negotiating timestamps would have the same = effect on PAWS / RTO calculation. And there are still a lot of sessions run= ning without timestamps.) For the conservative RTO calculation - I really would like to separate RTO= calculation from RTT measurement in this context, as these two are really = not the same - the proposal "gates" the RTO calculation updates with the (n= on-)existence of a SACK block, provided SACK was negotiated. If SACK is not= negotiated, the receiver would not change the semantic of which timestamps= to reflect over RFC1323. This allows to still maintain a conservative RTO estimate, but also to extr= act additional data from the network which is currently masked by the speci= fic way how timestamps has to be reflected. However, reflected timestamps (the TSecr field) is not relevant for PAWS, o= nly TSval is, correct? The suggestion made by Joe, about which timestamp to put into unsolicited s= egments (ie. bidirectional data segments ) even advanced this idea, so that= the RTTM update could be gated to whenever the seq.ack is different from t= he previous received segment, or for any received segment... But again, with the exception of delayed ACK (one ACK every other data segm= ent, or even fewer), the proposal can be used as direct feed into the curre= nt algorithms. I believe the mentioned difference with delayed ACKs would only become rele= vant, at small window sizes (<4 frames in flight), or when TCP processing o= n the receiver side has very high variability (in the same order of magnitu= de, or higher, than the delay in the network itself. I'm not entirely clear= myself as to how to reconcile that particular aspect with RTO calculation.= For RTO, the sender should - at least when the send window is very small -= take the delayed ACK timeout into consideration, in order to be packet con= serving.=20 On the other hand, the worst case scenario appears to be that RTO does not = take the delayed ACK timeout of the receiver into consideration, and re-tra= nsmits the last frame of a session sooner than strictly necessary. This wou= ld only happen if that last frame itself doesn't trigger an ACK... Now, in = some environments, such a behavior may be acceptable (slightly higher dupli= cate frames, but lower latency when the last frame of a stream is lost). Then again, as pointed out by Per Hurtig recently, most stacks are already = more conservative than required, by restarting the RTO timer with every rec= eived ACK rather than with the sending of the particular data frame... Some guidance from the group as to how to approach these different aspects = and reconcile them in the proposal would be very welcome! Season's greetings, Richard Scheffenegger > -----Original Message----- > From: L.Wood@surrey.ac.uk [mailto:L.Wood@surrey.ac.uk] > Sent: Dienstag, 20. Dezember 2011 05:10 > To: mattmathis@google.com > Cc: L.Wood@surrey.ac.uk; Scheffenegger, Richard; > dab@weston.borman.com; tcpm@ietf.org > Subject: Re: [tcpm] Timestamp semantic change >=20 > Sigh, You're both wrong. It's both. >=20 > > The sole purpose of 1323 timestamps was the Protection Against Wrapped > Sequence (PAWS) algorithm, > > >=20 >=20 > Read the expired RFC1323bis internet-draft: > http://www.kohala.com/start/tcplw-extensions.txt > "However, as RFC-1323 implied but did not clearly state, the RTTM > mechanism replaces Karn's algorithm." > [..] > Overriding the Karn algorithm was implied by the following > statement on page 14 of RFC-1323, which was independent of whether > or not the new data being acknowledged has been retransmitted: >=20 > "A TSecr value received in a segment is used to update the > averaged RTT measurement only if the segment acknowledges > some new data, i.e., only if it advances the left edge of the > send window." >=20 >=20 >=20 > On 19 Dec 2011, at 23:06, Matt Mathis wrote: >=20 > > NO - this is not correct! Sorry I did not catch this sooner. > > > > On Fri, Nov 25, 2011 at 12:59 AM, Scheffenegger, Richard > wrote: > > > > Hi Michael, > > > > * You are absolutely correct. In the context of RFC1323,the sole purpos= e of > Timestamps (to the sender) > > * is to deliver a conservative lower bound of the RTT. This is again us= ed for > the single purpose of > > * calculating the RTO on the sender side. > > > > The sole purpose of 1323 timestamps was the Protection Against Wrapped > Sequence (PAWS) algorithm, which essentially treats the timestamps as an > extension to the MSB of the sequence number. Other uses are secondary. > (Furthermore it was known at the time that the PAWS requirements reduce > the usefulness for RTT measurement, and that this was implicit from the > requirements). > > > > My mental model of PAWS is to compute longseq =3D > 4294967296*timestamp+seg.seq and enforce the standard in window checks > on both seq and longseq. This requires the hard constraint that longseq = be > absolutely monotonic, which in turn causes constraints on when you are > permitted to (or must) update the echoed timestamp. > > > > I admit that I have never worked through the details of PAWS myself, so > your algorithm might still be ok. However failing to meet the constraint= s > imposed by PAWS will cause odd TCP failures... > > > > I believe that one of the important fixes in 1323bis was about some cor= ner > case in exactly this area. > > > > Dave, do you care to comment? > > > > Also, as far as I know, nobody has worked though possible interactions = (or > opportunities) between PAWS/timestamps and SACK (or FACK). Or perhaps > you are the first! :-) > > > > Thanks, > > --MM-- > > >=20 >=20 From iesg-secretary@ietf.org Wed Dec 21 08:02:50 2011 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 2B6BE11E80A0; Wed, 21 Dec 2011 08:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 ikggy36jufJm; Wed, 21 Dec 2011 08:02:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD8111E80A1; Wed, 21 Dec 2011 08:02:49 -0800 (PST) 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: 3.64p1 Message-ID: <20111221160249.1725.77826.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2011 08:02:49 -0800 Cc: tcpm chair , tcpm mailing list , RFC Editor Subject: [tcpm] Protocol Action: 'Defending Against Sequence Number Attacks' to Proposed Standard (draft-ietf-tcpm-rfc1948bis-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: Wed, 21 Dec 2011 16:02:50 -0000 The IESG has approved the following document: - 'Defending Against Sequence Number Attacks' (draft-ietf-tcpm-rfc1948bis-02.txt) as a Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Wesley Eddy and David Harrington. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc1948bis/ Technical Summary This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. Working Group Summary Nothing exceptional occurred during the working group process for this document. Document Quality The algorithm described in this document is widely used, and has been for a number of years. This document is aimed at decreasing the predictability of the TCP ISN, to reduce the probability that an off-path attacker can guess the ISN, which would allow it to compromise the TCP connection. It does not change how TCP operates, just how the implementation chooses the ISN for each connection. Personnel David Borman (david.borman@windriver.com) is the document shepherd. He has personally reviewed this version and believes it is ready for forwarding to the IESG for publication. Wesley Eddy is the responsible Area Director.