From nobody Mon Jun 2 01:55:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388FF1A0105 for ; Mon, 2 Jun 2014 01:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOtcAbCJ0WyD for ; Mon, 2 Jun 2014 01:55:34 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0F11A0192 for ; Mon, 2 Jun 2014 01:55:34 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 73F53278227 for ; Mon, 2 Jun 2014 17:55:27 +0900 (JST) Received: by mail-we0-f177.google.com with SMTP id x48so4621771wes.8 for ; Mon, 02 Jun 2014 01:55:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.19.161 with SMTP id g1mr46139923wje.20.1401699325364; Mon, 02 Jun 2014 01:55:25 -0700 (PDT) Received: by 10.194.88.102 with HTTP; Mon, 2 Jun 2014 01:55:25 -0700 (PDT) In-Reply-To: <53892921.2040301@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> <53892921.2040301@isi.edu> Date: Mon, 2 Jun 2014 01:55:25 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b5d28585ed3a604fad68e71 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lYq7TDVN7ALTMEU9-byKj_jDtMs Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 08:55:36 -0000 --047d7b5d28585ed3a604fad68e71 Content-Type: text/plain; charset=UTF-8 Hi Joe, On Fri, May 30, 2014 at 5:58 PM, Joe Touch wrote: > > > Suppose If we use new code point, do we still have problems you >> mentioned below? >> > > It depends: > > - I don't think it matters vs. using the existing codepoint with a > different length (e.g., as a flag in the SYN); they are equivalent in being > uniquely identifiable. > OK. > > - I don't like the idea of setting new TCP flags or changing the meaning > of flags in the middle of a connection. That undermines the notion of a > connection IMO. > > To do so, the source would have to keep track of the last byte of the > segment in which the change occurs, and wait for a confirmation in the ACK > of that byte; ditto for the other end. > > They'd need to resend things if lost *with the same flags* to indicate the > change. I.e., you'd need to implement a new TWHS per option that changes state. > That's a mess. And I don't even want to think about what happens when you > have multiple options that change state at the same time. > I.e., you'd need to implement a new TWHS per option that changes state. > That's a mess. And I don't even want to think about what happens when you > have multiple options that change state at the same time. > With regard to A-PAWS draft, you don't need tight synchronization between sender and receiver necessarily. It is the receiver to send a signal that "BTW, I support A-PAWS, so you don't have to send TS in every segments" Then, the sender can omit TS segments from time to time, or it can just ignore the signal. -- Yoshi --047d7b5d28585ed3a604fad68e71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Fri, May 30, 2014 at 5:58 PM, Joe Touch <touch@isi.edu> wrote:


Suppose If we use new code point, do we still have problems you
mentioned below?

It depends:

- I don't think it matters vs. using the existing codepoint with a diff= erent length (e.g., as a flag in the SYN); they are equivalent in being uni= quely identifiable.

OK.=C2=A0

- I don't like the idea of setting new TCP flags or changing the meanin= g of flags in the middle of a connection. That undermines the notion of a c= onnection IMO.

To do so, the source would have to keep track of the last byte of the segme= nt in which the change occurs, and wait for a confirmation in the ACK of th= at byte; ditto for the other end.

They'd need to resend things if lost *with the same flags* to indicate = the change.=C2=A0
I.e., you'd need to implement a new TWHS per option that changes state.= That's a mess. And I don't even want to think about what happens w= hen you have multiple options that change state at the same time.

I.e., you'd need to implement a new TWH= S per option that changes state. That's a mess. And I don't even wa= nt to think about what happens when you have multiple options that change s= tate at the same time.
=C2=A0
With regard to A-PAWS draft, you don'= ;t need tight synchronization between sender and receiver necessarily.
It is the receiver to send a signal that "BTW, I support A-PAWS,= so you don't have to send TS in every segments"
Then, the sender can omit TS segments from time to time, or it can jus= t ignore the signal.
--
Yoshi
--047d7b5d28585ed3a604fad68e71-- From nobody Mon Jun 2 09:36:00 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135321A0253 for ; Mon, 2 Jun 2014 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCk5bu3Qs7mI for ; Mon, 2 Jun 2014 09:35:57 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19BF1A023A for ; Mon, 2 Jun 2014 09:35:57 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s52GZcK9023836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 09:35:42 -0700 (PDT) Message-ID: <538CA7DD.9040103@isi.edu> Date: Mon, 02 Jun 2014 09:35:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> <53892921.2040301@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/c3y6Fm9fkH6lecQNdscQjwIxkbE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 16:35:59 -0000 On 6/2/2014 1:55 AM, Yoshifumi Nishida wrote: > Hi Joe, > > On Fri, May 30, 2014 at 5:58 PM, Joe Touch > wrote: ... > I.e., you'd need to implement a new TWHS per option that changes > state. That's a mess. And I don't even want to think about what > happens when you have multiple options that change state at the same > time. > > With regard to A-PAWS draft, you don't need tight synchronization > between sender and receiver necessarily. > It is the receiver to send a signal that "BTW, I support A-PAWS, so you > don't have to send TS in every segments" > Then, the sender can omit TS segments from time to time, or it can just > ignore the signal. First, you definitely need to negotiate TS-support during SYN exchange IMO. Second, if you decide to turn on TS use in mid-stream, you have to decide what to do with non-TS packets - do you just always accept them? Let's say you declare all non-TS packets that come before TS-use to be "before" all TS-use packets (the non-TS to TS-use transition provides a a distributed systems "consistent cut") - we'll look at the other case below. In that case - which, AFAICT is the best you can do - you still have: - no PAWS protection within the non-TS set within a connection - no PAWS protection between different streams (that reuse the port-pair) during non-TS use The most dangerous time is when a connection starts - that's when you really need to avoid having things leak from previous connections that could have persisted beyond the expected MSL. So that's when you'd want to start using TS, but then you have no gain because (again, AFAICT) once you start using TS you should never turn it off. -------------- In the case where you CAN continue to flip back and forth between TS-use and non-TS, then *very non-TS packet* becomes a time-bomb for both this connection and future connections. That's what PAWS was supposed to avoid, but you're stepping right into it. ----- My conclusion is that if you turn on TS you have to do it at the beginning of a connection, or you might as well not use TS at all. Joe From nobody Mon Jun 2 10:50:57 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826C11A0337 for ; Mon, 2 Jun 2014 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4vHN0bi-iHF for ; Mon, 2 Jun 2014 10:50:55 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2FC1A0332 for ; Mon, 2 Jun 2014 10:50:55 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s52HomYV028887; Mon, 2 Jun 2014 10:50:49 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8FF69780B6B; Mon, 2 Jun 2014 13:50:48 -0400 (EDT) To: "Eggert, Lars" From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blow Up the Outside World X-URL-0: http://www.icir.org/mallman-files/Document89972.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47480-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Jun 2014 13:50:48 -0400 Sender: mallman@icir.org Message-Id: <20140602175048.8FF69780B6B@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Cve0YCP6FpcHAiR5pKFt3bXgo6o Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 17:50:56 -0000 ----------ma47480-1 Content-Type: text/plain Content-Disposition: inline > I think it was Mark Allman who questioned a while ago whether the > benefits of the timestamp option are worth spending 10 bytes in every > packet. (But I can't find the email now.) Just to be clear ... - The RTTM scheme for getting a better RTO seems generally dubious to me (based on an old paper I wrote with Vern). It does not seem worthwhile to spend 10 bytes / packet to get more RTT samples per RTT from the perspective of getting a better RTO (because we don't). - However, if you're sending fast then you still have a sequence wrap issue. The only standard way that I am aware of that we deal with that issue is timestamps in every packet. So, for this I certainly think there is value in having the TS option there. That said, there is ample opportunity to turn TS on in the midst of a connection before we need it for PAWS, but allowing the vast majority of the connections to save the bytes. allman ----------ma47480-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlOMuXgACgkQWyrrWs4yIs6pJwCfb+g9aUw7k9iv0AnRWSPGfABJ qRsAn0EpY/PoZJmQib8A+GlsZUKViqj1 =O1mZ -----END PGP SIGNATURE----- ----------ma47480-1-- From nobody Mon Jun 2 10:51:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221B91A03A3 for ; Mon, 2 Jun 2014 10:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTIQYzuYI4V5 for ; Mon, 2 Jun 2014 10:51:44 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4E31A03D2 for ; Mon, 2 Jun 2014 10:51:42 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s52HouD2028992; Mon, 2 Jun 2014 10:50:56 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1216F780B80; Mon, 2 Jun 2014 13:50:57 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <5384EFC3.50803@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blow Up the Outside World X-URL-0: http://www.icir.org/mallman-files/Document1388.pdf X-URL-1: http://www.icir.org/mallman-files/Document22155.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma47489-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Jun 2014 13:50:57 -0400 Sender: mallman@icir.org Message-Id: <20140602175057.1216F780B80@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YZ-nL2Tqfr-sPC3JpV3I_u21Srw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 17:51:53 -0000 ----------ma47489-1 Content-Type: text/plain Content-Disposition: inline > Late negotiation has too many problems, as have been repeatedly > raised on this list: > > - prevents use of the timestamp to help address PAWS for > the initial SYN In the limit you're right that it is better to have a stronger indication that the arriving SYN / SYN+ACK is not way old. It is hard to argue against such an ideal. But, we run a whole bunch of connections without timestamps today and it doesn't seem to have caused us a whole bunch of problems. So, while I can see your point I think it is pretty esoteric. Also, I'd like to know if OSes actually do consult the TS value in the 3WHS to try to hunt for old packets. I have no idea. Does anyone know? (Either answer wouldn't surprise me, actually.) > - a new connection that either avoids TS in SYN or > uses just "use TS" (two-byte) flag can't know when > to engage the timestamp and what initial value to use This is just bogus. On both counts. (1) A TCP can in fact know when it should engage because it can in fact gauge its sending rate and relate that to the MSL. And, if that is too complicated for a TCP to do---and it strikes me as such---then the TCP can turn it on when it approaches sequence wrap for the first time (i.e., sending 4GB of data). (2) I don't see how the initial value we use here is different from the initial value we use at the beginning of a connection. Do we have to account for sending a TS mid-stream and it not being supported by the other end? Sure. It seems the answer is to ensure the sending rate is less than 4GB/MSL. Is that extra work? Sure. Is it worth it to save a wad of useless bytes in lots of packets on the Internet? That is a judgment call where reasonable people could disagree, I guess. allman ----------ma47489-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlOMuYEACgkQWyrrWs4yIs5DRgCfVz3MJBYLMvOAZ3zfR3501hmY 2OwAn2a1Rl0lftCOkax4lcFxPpkUE92c =7RqE -----END PGP SIGNATURE----- ----------ma47489-1-- From nobody Mon Jun 2 11:09:11 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC381A037F for ; Mon, 2 Jun 2014 11:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LktMq5eqvnZf for ; Mon, 2 Jun 2014 11:09:09 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531721A034E for ; Mon, 2 Jun 2014 11:09:09 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s52I8vQC025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jun 2014 13:08:59 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s52I8uNv026396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 20:08:56 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 2 Jun 2014 20:08:56 +0200 From: "Scharf, Michael (Michael)" To: "mallman@icir.org" , Joe Touch Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPfotSctUOJKEko0unkfd/+aCl9pteG1oQ Date: Mon, 2 Jun 2014 18:08:54 +0000 Message-ID: <655C07320163294895BBADA28372AF5D31326E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5384EFC3.50803@isi.edu> <20140602175057.1216F780B80@lawyers.icir.org> In-Reply-To: <20140602175057.1216F780B80@lawyers.icir.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ge5ZEmCZ_ra7WWVm5Afj5z_0P84 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 18:09:11 -0000 > Also, I'd like to know if OSes actually do consult the TS value in the > 3WHS to try to hunt for old packets. I have no idea. Does anyone > know? > (Either answer wouldn't surprise me, actually.) Well, I don't know. But a related thought: In 1323bis we actually mention a random, per-connect= ion offset. Such a logic in the 3WHS would have to take different offsets i= nto account, right? Michael From nobody Mon Jun 2 11:09:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8720B1A034E for ; Mon, 2 Jun 2014 11:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD_0brdkJ7D7 for ; Mon, 2 Jun 2014 11:09:43 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D581A0341 for ; Mon, 2 Jun 2014 11:09:43 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s52I7BbY017185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 11:07:14 -0700 (PDT) Message-ID: <538CBD52.6050209@isi.edu> Date: Mon, 02 Jun 2014 11:07:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mallman@icir.org References: <20140602175057.1216F780B80@lawyers.icir.org> In-Reply-To: <20140602175057.1216F780B80@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Zy74XuNjPtDFZ0lHS8zvvyYEcvw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 18:09:44 -0000 On 6/2/2014 10:50 AM, Mark Allman wrote: > >> Late negotiation has too many problems, as have been repeatedly >> raised on this list: >> >> - prevents use of the timestamp to help address PAWS for >> the initial SYN > > In the limit you're right that it is better to have a stronger > indication that the arriving SYN / SYN+ACK is not way old. It is hard > to argue against such an ideal. But, we run a whole bunch of > connections without timestamps today and it doesn't seem to have caused > us a whole bunch of problems. So, while I can see your point I think it > is pretty esoteric. > > Also, I'd like to know if OSes actually do consult the TS value in the > 3WHS to try to hunt for old packets. I have no idea. Does anyone know? > (Either answer wouldn't surprise me, actually.) The TWHS establishes the TS for the new connection, which means old packets will be seen as old and discarded by TS processing. >> - a new connection that either avoids TS in SYN or >> uses just "use TS" (two-byte) flag can't know when >> to engage the timestamp and what initial value to use > > This is just bogus. On both counts. FWIW, I'm saying that receiver has these problems. You're correct that the first TS value in an *acked* segment should be the one used and that the sender can know when to turn it on. However, what if the receiver doesn't support TS at that point? How does it say so? At the least, TS-capable must be negotiated during the TWHS. One question is - how many connections use TS that don't expect to use long connections or large numbers of connections where the sequence number wrap is an issue? Joe From nobody Mon Jun 2 11:12:30 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C8A1A0380 for ; Mon, 2 Jun 2014 11:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEqS96MHnH0i for ; Mon, 2 Jun 2014 11:12:27 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8AC1A0337 for ; Mon, 2 Jun 2014 11:12:27 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s52IBsVB018224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 11:11:57 -0700 (PDT) Message-ID: <538CBE6C.2030700@isi.edu> Date: Mon, 02 Jun 2014 11:11:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Scharf, Michael (Michael)" , "mallman@icir.org" References: <5384EFC3.50803@isi.edu> <20140602175057.1216F780B80@lawyers.icir.org> <655C07320163294895BBADA28372AF5D31326E@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D31326E@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/kO_OgdkZZQkM19iwf1NsgIiRXzw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 18:12:28 -0000 On 6/2/2014 11:08 AM, Scharf, Michael (Michael) wrote: >> Also, I'd like to know if OSes actually do consult the TS value in the >> 3WHS to try to hunt for old packets. I have no idea. Does anyone >> know? >> (Either answer wouldn't surprise me, actually.) > > Well, I don't know. > > But a related thought: In 1323bis we actually mention a random, > per-connection offset. Such a logic in the 3WHS would have to take > different offsets into account, right? Offsets should always move the clock forward; if they don't - if one offset is smaller than another for the same port pair - then 1323bis got it wrong. Joe From nobody Mon Jun 2 11:26:07 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624831A032E for ; Mon, 2 Jun 2014 11:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjl7J0SUdVe7 for ; Mon, 2 Jun 2014 11:26:04 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C8C1A025F for ; Mon, 2 Jun 2014 11:26:03 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s52IPsPN012078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jun 2014 13:25:55 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s52IPr2m007751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 20:25:53 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 2 Jun 2014 20:25:53 +0200 From: "Scharf, Michael (Michael)" To: Joe Touch , "mallman@icir.org" Thread-Topic: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) Thread-Index: AQHPfo48smnn4VD+2U2bTCfpOGEospteH/3Q Date: Mon, 2 Jun 2014 18:25:52 +0000 Message-ID: <655C07320163294895BBADA28372AF5D3132B1@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <5384EFC3.50803@isi.edu> <20140602175057.1216F780B80@lawyers.icir.org> <655C07320163294895BBADA28372AF5D31326E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <538CBE6C.2030700@isi.edu> In-Reply-To: <538CBE6C.2030700@isi.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/KFyUhphYbiQg6hy9bMRqytEFtCU Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 18:26:05 -0000 > On 6/2/2014 11:08 AM, Scharf, Michael (Michael) wrote: > >> Also, I'd like to know if OSes actually do consult the TS value in > the > >> 3WHS to try to hunt for old packets. I have no idea. Does anyone > >> know? > >> (Either answer wouldn't surprise me, actually.) > > > > Well, I don't know. > > > > But a related thought: In 1323bis we actually mention a random, > > per-connection offset. Such a logic in the 3WHS would have to take > > different offsets into account, right? >=20 > Offsets should always move the clock forward; if they don't - if one > offset is smaller than another for the same port pair - then 1323bis > got > it wrong. As far as I can see, draft-ietf-tcpm-1323bis-21 indeed mentions this requir= ement in Section 5.4, but it is not stated in the specific sentence that ex= plains randomization. =20 Michael From nobody Mon Jun 2 12:49:45 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0451A0223 for ; Mon, 2 Jun 2014 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIrD-h75wxvR for ; Mon, 2 Jun 2014 12:49:42 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66EB1A0069 for ; Mon, 2 Jun 2014 12:49:42 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s52Jn6k1016763; Mon, 2 Jun 2014 12:49:06 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 2A40F781A45; Mon, 2 Jun 2014 15:49:06 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <538CBD52.6050209@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blow Up the Outside World X-URL-0: http://www.icir.org/mallman-files/Document88778.jpg X-URL-1: http://www.icir.org/mallman-files/Document52323.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma54576-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Jun 2014 15:49:06 -0400 Sender: mallman@icir.org Message-Id: <20140602194906.2A40F781A45@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DwGEU0MLL9cujGD6XPEMOjF-VYM Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 19:49:43 -0000 ----------ma54576-1 Content-Type: text/plain Content-Disposition: inline > The TWHS establishes the TS for the new connection, which means old > packets will be seen as old and discarded by TS processing. OK, sure, fair enough. But, again, we have plenty of non-timestamped connections seemingly running perfectly fine today. So, it is pretty hard for me to get worked up about this "problem" the timestamp option is "solving". > >> - a new connection that either avoids TS in SYN or > >> uses just "use TS" (two-byte) flag can't know when > >> to engage the timestamp and what initial value to use > > > > This is just bogus. On both counts. > > FWIW, I'm saying that receiver has these problems. You're correct > that the first TS value in an *acked* segment should be the one used > and that the sender can know when to turn it on. It doesn't matter if the receiver just follows the sender's lead. The sender can trigger things when they are needed and the receiver can follow. > However, what if the receiver doesn't support TS at that point? If only I had said something about that in the note you are responding to ... oh wait, I did! :-) Do we have to account for sending a TS mid-stream and it not being supported by the other end? Sure. It seems the answer is to ensure the sending rate is less than 4GB/MSL. Is that extra work? Sure. Is it worth it to save a wad of useless bytes in lots of packets on the Internet? That is a judgment call where reasonable people could disagree, I guess. This is pretty much a cwnd cap, so it isn't like it is rocket science here. > One question is - how many connections use TS that don't expect to > use long connections or large numbers of connections where the > sequence number wrap is an issue? I would say nearly all of them. I'd bet a beer that you go look in your favorite pile of traces and it'll be a Damn Long Time before you find even a potential problem that timestamps will solve. allman ----------ma54576-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlOM1TIACgkQWyrrWs4yIs5aqgCfWZnYpuFFWtXF7XEX6XCzwzaU ML4AniEJcmBCdHcfCuLQjAaXLtLgLzOf =1/Vd -----END PGP SIGNATURE----- ----------ma54576-1-- From nobody Mon Jun 2 13:14:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A701A042E for ; Mon, 2 Jun 2014 13:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb-p3M3isRBz for ; Mon, 2 Jun 2014 13:14:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB99B1A0404 for ; Mon, 2 Jun 2014 13:14:36 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s52KDw4a015609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 13:14:01 -0700 (PDT) Message-ID: <538CDB07.2090306@isi.edu> Date: Mon, 02 Jun 2014 13:13:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: mallman@icir.org References: <20140602194906.2A40F781A45@lawyers.icir.org> In-Reply-To: <20140602194906.2A40F781A45@lawyers.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4DtyFbMy56QtuSJkkIqhMKoDjwg Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 02 Jun 2014 20:14:39 -0000 On 6/2/2014 12:49 PM, Mark Allman wrote: > >> The TWHS establishes the TS for the new connection, which means old >> packets will be seen as old and discarded by TS processing. > > OK, sure, fair enough. But, again, we have plenty of non-timestamped > connections seemingly running perfectly fine today. So, it is pretty > hard for me to get worked up about this "problem" the timestamp option > is "solving". > >>>> - a new connection that either avoids TS in SYN or >>>> uses just "use TS" (two-byte) flag can't know when >>>> to engage the timestamp and what initial value to use >>> >>> This is just bogus. On both counts. >> >> FWIW, I'm saying that receiver has these problems. You're correct >> that the first TS value in an *acked* segment should be the one used >> and that the sender can know when to turn it on. > > It doesn't matter if the receiver just follows the sender's lead. The > sender can trigger things when they are needed and the receiver can > follow. > >> However, what if the receiver doesn't support TS at that point? > > If only I had said something about that in the note you are responding > to ... oh wait, I did! :-) You talk about limiting the rate; that doesn't help a connection that cannot proceed because packets with the TS option are being dropped, e.g., by a midbox. That's why I don't like new stuff that starts out of the blue mid-connection - you need to negotiate the capability in the SYN at a minimum. Further, what happens to the packets? When and how do you know when the TS isn't working? When do you give up? Your rate limit suggestion answers just one dimension of the problem; there are a lot of others that need to be addressed. >> One question is - how many connections use TS that don't expect to >> use long connections or large numbers of connections where the >> sequence number wrap is an issue? > > I would say nearly all of them. > > I'd bet a beer that you go look in your favorite pile of traces and > it'll be a Damn Long Time before you find even a potential problem that > timestamps will solve. 1323bis talks about a list of mechanisms that rely on timestamps, more than just PAWS. What happens to those when TS is optional or started late? Joe From nobody Mon Jun 2 13:35:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2E51A0439 for ; Mon, 2 Jun 2014 13:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezLQOeGkeAsT for ; Mon, 2 Jun 2014 13:35:50 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F14A1A0410 for ; Mon, 2 Jun 2014 13:35:50 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id s52KZeCZ023761; Mon, 2 Jun 2014 13:35:41 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C48727825A0; Mon, 2 Jun 2014 16:35:40 -0400 (EDT) To: Joe Touch From: Mark Allman In-Reply-To: <538CDB07.2090306@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Blow Up the Outside World X-URL-0: http://www.icir.org/mallman-files/Document96163.jpg X-URL-1: http://www.icir.org/mallman-files/Document28952.doc X-URL-2: http://www.icir.org/mallman-files/Document45466.docx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma57372-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Jun 2014 16:35:40 -0400 Sender: mallman@icir.org Message-Id: <20140602203540.C48727825A0@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0Agk6J14BuR1PTh9QajbsnDPwfw Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 20:35:51 -0000 ----------ma57372-1 Content-Type: text/plain Content-Disposition: inline > You talk about limiting the rate; that doesn't help a connection > that cannot proceed because packets with the TS option are being > dropped, e.g., by a midbox. Sure- in a spec you'd have to consider that. But, I am not going to pretend that it is difficult to detect and react to. > Further, what happens to the packets? When and how do you know when > the TS isn't working? When do you give up? One RTT later. Don't pretend this is difficult. I didn't fully specify it in an **email message**, but don't pretend this is some leap into the Great Protocol Engineering Unknown, Joe. > 1323bis talks about a list of mechanisms that rely on timestamps, more > than just PAWS. What happens to those when TS is optional or started > late? If you want to use something and that something needs the TS option to be on for the entire connection (e.g., Eifel) then you turn it on for the entire connection. Fine. I have no problem with that. But, then you're not simply wasting 10 bytes in every packet, but you're getting something for it. However, on its own 1323(bis) wastes 10 bytes in every packet because RTTM is not helpful and PAWS is nearly never needed. So, it seems to me that instead of dogmatically putting our foot down we could re-think providing the information for PAWS when we actually need PAWS. I guess that is radical engineering or something, I dunno ... allman ----------ma57372-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlOM4BwACgkQWyrrWs4yIs4aUwCbB7Tl4FNYkPcGCs/zwfcOm4cx xacAnAs6sIQd7yFXeE1JdfugsxeN7iCZ =AbY/ -----END PGP SIGNATURE----- ----------ma57372-1-- From nobody Mon Jun 2 18:58:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE76F1A0019 for ; Mon, 2 Jun 2014 18:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z8rQDNwlMDW for ; Mon, 2 Jun 2014 18:58:46 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7043A1A0009 for ; Mon, 2 Jun 2014 18:58:46 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s531wcjh029185 for ; Mon, 2 Jun 2014 21:58:38 -0400 Received: (qmail 22773 invoked by uid 0); 3 Jun 2014 01:58:38 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 3 Jun 2014 01:58:38 -0000 Message-ID: <538D2BCC.8030906@mti-systems.com> Date: Mon, 02 Jun 2014 21:58:36 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XX8ftFA1V7s3I-xqAVpbQujqO0s Subject: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 01:58:48 -0000 I was working on an issue with Nagle in a space system, and noticed that the Linux kernel actually implements the "Minshall" version of the Nagle algorithm, described nicely in: http://tools.ietf.org/html/draft-minshall-nagle-01 There are a couple later papers I was able to find also that describe this. To me, this looks like clearly a good thing that should be recommended in the RFCs where we currently just have discussion of "standard Nagle". Apparently it was adopted in Linux, but I wonder if it was picked up or not in other OSes as well. Does anyone have history on why this draft never progressed? Maybe someone has current contact information for Greg Minshall? -- Wes Eddy MTI Systems From nobody Mon Jun 2 23:05:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A841A00F5 for ; Mon, 2 Jun 2014 23:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrWpXEfwJ6mb for ; Mon, 2 Jun 2014 23:05:43 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB551A00F4 for ; Mon, 2 Jun 2014 23:05:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,963,1392192000"; d="asc'?scan'208";a="126539992" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx11-out.netapp.com with ESMTP; 02 Jun 2014 23:05:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 2 Jun 2014 23:05:21 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 2 Jun 2014 23:05:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::d865:b6fe:275f:ffef%21]) with mapi id 15.00.0847.030; Mon, 2 Jun 2014 23:05:20 -0700 From: "Eggert, Lars" To: Wesley Eddy Thread-Topic: [tcpm] draft-minshall-nagle Thread-Index: AQHPfs9muHqEDeGV2UCZZR2B3gsAk5tfW1AA Date: Tue, 3 Jun 2014 06:05:19 +0000 Message-ID: References: <538D2BCC.8030906@mti-systems.com> In-Reply-To: <538D2BCC.8030906@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_A03A3B14-16CA-4E81-A242-E06801F32A99"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hf5uhQADBqOkA45ItmwE5PB7jVw Cc: "tcpm@ietf.org" , "minshall@acm.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 06:05:45 -0000 --Apple-Mail=_A03A3B14-16CA-4E81-A242-E06801F32A99 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii CC'ing Greg at one address that used to work for him. On 2014-6-3, at 3:58, Wesley Eddy wrote: > I was working on an issue with Nagle in a space system, and > noticed that the Linux kernel actually implements the "Minshall" > version of the Nagle algorithm, described nicely in: > http://tools.ietf.org/html/draft-minshall-nagle-01 > > There are a couple later papers I was able to find also that > describe this. > > To me, this looks like clearly a good thing that should be > recommended in the RFCs where we currently just have discussion > of "standard Nagle". Apparently it was adopted in Linux, but I > wonder if it was picked up or not in other OSes as well. > > Does anyone have history on why this draft never progressed? > Maybe someone has current contact information for Greg Minshall? > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_A03A3B14-16CA-4E81-A242-E06801F32A99 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU41lntZcnpRveo1xAQKNwwP/ZWvs1E/9NeIxjFM7PTlHgtrvf4RgYyMk hmOOhgRo7MFAu3TmGDSxjgJEXjNAnr+6/NEOpALo6y0nYBs21rzPXdtZIU7ue0oE wxJazUrojlAtezMP8+IkrKN302auIJkqub4IecQSYEyiwPPvbZcNyOh51ZparHIv cuz3mWA6XLQ= =+wpw -----END PGP SIGNATURE----- --Apple-Mail=_A03A3B14-16CA-4E81-A242-E06801F32A99-- From nobody Mon Jun 2 23:18:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FAF1A00F8 for ; Mon, 2 Jun 2014 23:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.574 X-Spam-Level: * X-Spam-Status: No, score=1.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iUGF4ixifJJ for ; Mon, 2 Jun 2014 23:18:33 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F911A00F9 for ; Mon, 2 Jun 2014 23:18:33 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 64B1B2781BC for ; Tue, 3 Jun 2014 15:18:25 +0900 (JST) Received: by mail-we0-f173.google.com with SMTP id u57so6195057wes.4 for ; Mon, 02 Jun 2014 23:18:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.184.179 with SMTP id ev19mr12506943wjc.85.1401776303077; Mon, 02 Jun 2014 23:18:23 -0700 (PDT) Received: by 10.194.88.102 with HTTP; Mon, 2 Jun 2014 23:18:22 -0700 (PDT) In-Reply-To: <538CA7DD.9040103@isi.edu> References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <537E48CE.8040704@mti-systems.com> <537E66A7.4080907@isi.edu> <201405231003.s4NA3PAB005137@bagheera.jungle.bt.co.uk> <537F7D91.10802@isi.edu> <655C07320163294895BBADA28372AF5D305E00@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3DD808@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309C5D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <012C3117EDDB3C4781FD802A8C27DD4F6F3E09CF@SACEXCMBX06-PRD.hq.netapp.com> <655C07320163294895BBADA28372AF5D309CC7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <5384EFC3.50803@isi.edu> <53892921.2040301@isi.edu> <538CA7DD.9040103@isi.edu> Date: Mon, 2 Jun 2014 23:18:22 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7b87371e99854e04fae87a9f Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hqOcojZ0OH_kqe0OEU44VUa2O14 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 06:18:37 -0000 --047d7b87371e99854e04fae87a9f Content-Type: text/plain; charset=UTF-8 Hi Joe, On Mon, Jun 2, 2014 at 9:35 AM, Joe Touch wrote: > > > On 6/2/2014 1:55 AM, Yoshifumi Nishida wrote: > >> Hi Joe, >> >> On Fri, May 30, 2014 at 5:58 PM, Joe Touch > > wrote: >> > ... > > I.e., you'd need to implement a new TWHS per option that changes >> state. That's a mess. And I don't even want to think about what >> happens when you have multiple options that change state at the same >> time. >> >> With regard to A-PAWS draft, you don't need tight synchronization >> between sender and receiver necessarily. >> It is the receiver to send a signal that "BTW, I support A-PAWS, so you >> don't have to send TS in every segments" >> Then, the sender can omit TS segments from time to time, or it can just >> ignore the signal. >> > > First, you definitely need to negotiate TS-support during SYN exchange IMO. > > Second, if you decide to turn on TS use in mid-stream, you have to decide > what to do with non-TS packets - do you just always accept them? Let's say > you declare all non-TS packets that come before TS-use to be "before" all > TS-use packets (the non-TS to TS-use transition provides a a distributed > systems "consistent cut") - we'll look at the other case below. > > In that case - which, AFAICT is the best you can do - you still have: > > - no PAWS protection within the non-TS set within a connection > > - no PAWS protection between different streams (that reuse > the port-pair) during non-TS use > > The most dangerous time is when a connection starts - that's when you > really need to avoid having things leak from previous connections that > could have persisted beyond the expected MSL. So that's when you'd want to > start using TS, but then you have no gain because (again, AFAICT) once you > start using TS you should never turn it off. > Please let me explain my proposal a bit more. What I am thinking is something like this: 1: A-PAWS can be enabled in SYN exchange or in the middle of session. (I'm still thinking choosing one of them or both) 2: It presumes the use of TS at the beginning. If TS option is disabled, the connection never uses TS and there's no PAWS. Period. 3: If TCP receives non-TS packets before enabling A-PAWS, the behavior will be out-of-scope of the draft. It should follow the way described in 1323bis So, it starts using TS and tries to turn it off (unless it won't affect PAWS). But, I still think this might be possible. Please let me know if I miss something. Also, In order to address the issue in connection starts, I have added some texts in Section 4 in http://tools.ietf.org/html/draft-nishida-tcpm-apaws-00 In a nutshell, we cannot enable this feature under a certain conditions where there are risks for conflicts between previous connections. If I overlook some conditions, please let me know. Thanks, -- Yoshi --047d7b87371e99854e04fae87a9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,=C2=A0

On Mon, Jun 2, 2014 at 9:35 AM, Joe Touch <touch@isi.e= du> wrote:

On 6/2/2014 1:55 AM, Yoshifumi Nishida wrote:
Hi Joe,

On Fri, May 30, 2014 at 5:58 PM, Joe Touch <touch@isi.edu
<mailto:touch@isi.edu= >> wrote:
...

=C2=A0 =C2=A0 I.e., you'd need to implement a new TWHS per option that = changes
=C2=A0 =C2=A0 state. That's a mess. And I don't even want to think = about what
=C2=A0 =C2=A0 happens when you have multiple options that change state at t= he same
=C2=A0 =C2=A0 time.

With regard to A-PAWS draft, you don't need tight synchronization
between sender and receiver necessarily.
It is the receiver to send a signal that "BTW, I support A-PAWS, so yo= u
don't have to send TS in every segments"
Then, the sender can omit TS segments from time to time, or it can just
ignore the signal.

First, you definitely need to negotiate TS-support during SYN exchange IMO.=

Second, if you decide to turn on TS use in mid-stream, you have to decide w= hat to do with non-TS packets - do you just always accept them? Let's s= ay you declare all non-TS packets that come before TS-use to be "befor= e" all TS-use packets (the non-TS to TS-use transition provides a a di= stributed systems "consistent cut") - we'll look at the other= case below.

In that case - which, AFAICT is the best you can do - you still have:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - no PAWS protection within the non-TS set with= in a connection

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - no PAWS protection between different streams = (that reuse
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the port-pair) during non-TS use

The most dangerous time is when a connection starts - that's when y= ou really need to avoid having things leak from previous connections that c= ould have persisted beyond the expected MSL. So that's when you'd w= ant to start using TS, but then you have no gain because (again, AFAICT) on= ce you start using TS you should never turn it off.
=C2=A0
Please let me explain my proposal a bit = more.=C2=A0
What I am thinking is something like this:
= =C2=A0 1: A-PAWS can be enabled in SYN exchange or in the middle of session= . (I'm still thinking choosing one of them or both)
=C2=A0 2: It presumes the use of TS at the beginning. If TS option is = disabled, the connection never uses TS and there's no PAWS. Period.=C2= =A0
=C2=A0 3: If TCP receives non-TS packets before enabling A-PA= WS, the behavior will be out-of-scope of the draft. It should follow the wa= y described in 1323bis=C2=A0
So, it starts using TS and tries to turn it off (unless it won't a= ffect PAWS). But, I still think this might be possible. Please let me know = if I miss something.=C2=A0

Also, In order to addre= ss the issue in connection starts, I have added some texts in Section 4 in = http://t= ools.ietf.org/html/draft-nishida-tcpm-apaws-00
In a nutshell, we cannot enable this feature under a certain condition= s where there are risks for conflicts between previous connections. If I ov= erlook some conditions, please let me know.

Thanks= ,
--
Yoshi

--047d7b87371e99854e04fae87a9f-- From nobody Tue Jun 3 00:21:37 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF67A1A0114 for ; Tue, 3 Jun 2014 00:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1QG-c2eAjt1 for ; Tue, 3 Jun 2014 00:21:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2451A0043 for ; Tue, 3 Jun 2014 00:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1550; q=dns/txt; s=iport; t=1401780089; x=1402989689; h=from:to:cc:subject:date:message-id:mime-version; bh=z+GesEJmPV5BnKLwMGZITdeOUDNYwSju+m+M9L5tLnY=; b=Hq1fKZnnGXZZCA/s3O32OZJOi7lM9glP2m8CBec5TAfovy2Dsw1FxjEr 2EBfLUJfOg4wRAjlIv+qIipoKVLpg+zZrKY3RtnHw0LuaGNAPtNWjEaZX wwNEvu+dNC1LHySOLW4KpXKQ7PJdMbw1u5uCLRGRmrrYwacImMO59gIjs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqNMAOp2jVOtJV2T/2dsb2JhbABZgkJFUliECKYqAQIFAY8gEIhrgQwWdIIcEHkSAQsBdCcEDohHDdEXF4VViH2ERwSaAIE+kW+DOIIv X-IronPort-AV: E=Sophos;i="4.98,963,1392163200"; d="scan'208,217";a="330057915" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jun 2014 07:21:28 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s537LSeY023930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Jun 2014 07:21:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 3 Jun 2014 02:21:27 -0500 From: "Sujeet Nayak A (sua)" To: "tcpm@ietf.org" Thread-Topic: SHA-2 auth draft on TCP-AO Thread-Index: AQHPfvxv6weXQSw2CU2SLhVbOlzptQ== Date: Tue, 3 Jun 2014 07:21:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.21.74.160] Content-Type: multipart/alternative; boundary="_000_CFB372645CEF3suaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/q12PDLh09sln1ohveCQ3DZZWYRQ Cc: "Rohit M \(rrohit\)" Subject: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 07:21:36 -0000 --_000_CFB372645CEF3suaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In the last few months, we have been seeing a lot of customer interest for = SHA-2 based auth on TCP-AO enabled connections. In this regard, we (Brian W= eis and myself) have posted a draft for the same: http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 Pl. review and let me know your valuable comments. Regards, Sujeet Nayak A. --_000_CFB372645CEF3suaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9336C4DDDBDC9A4E98C695B230D8B406@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,
In the last few months, we have been seeing a lot of customer interest= for SHA-2 based auth on TCP-AO enabled connections. In this regard, we (Br= ian Weis and myself) have posted a draft for the same:

Pl. review and let me know your valuable comments.

Regards,

Sujeet Nayak A.
--_000_CFB372645CEF3suaciscocom_-- From nobody Tue Jun 3 08:05:35 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2D1A0171 for ; Tue, 3 Jun 2014 08:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP2u1jHmIGfp for ; Tue, 3 Jun 2014 08:05:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC161A02CF for ; Tue, 3 Jun 2014 08:05:03 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s53F48Qb011670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jun 2014 08:04:11 -0700 (PDT) Message-ID: <538DE3EA.2030104@isi.edu> Date: Tue, 03 Jun 2014 08:04:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wesley Eddy , "tcpm@ietf.org" References: <538D2BCC.8030906@mti-systems.com> In-Reply-To: <538D2BCC.8030906@mti-systems.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/WsX3LwfrGdUQGHSxwHLrCQVaTlU Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 15:05:22 -0000 Hi, Wes, Although I don't recall this and only scanned it briefly, I don't quite understand the problem. I thought it was widely known that Nagle was useful for single-character interactive traffic, but also widely known as something that should be disabled for any multi-character interactive traffic - including multi-character encodings, HTTP, etc. If Nagle is off - as it should be for interactive web traffic - then the optimizations in this draft won't have any impact. So what kind of traffic does this actually help? Or is this an optimization of a path that either isn't or shouldn't be used? Joe On 6/2/2014 6:58 PM, Wesley Eddy wrote: > I was working on an issue with Nagle in a space system, and > noticed that the Linux kernel actually implements the "Minshall" > version of the Nagle algorithm, described nicely in: > http://tools.ietf.org/html/draft-minshall-nagle-01 > > There are a couple later papers I was able to find also that > describe this. > > To me, this looks like clearly a good thing that should be > recommended in the RFCs where we currently just have discussion > of "standard Nagle". Apparently it was adopted in Linux, but I > wonder if it was picked up or not in other OSes as well. > > Does anyone have history on why this draft never progressed? > Maybe someone has current contact information for Greg Minshall? > From nobody Tue Jun 3 08:15:34 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5D1A02F9 for ; Tue, 3 Jun 2014 08:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fain8f15EYP for ; Tue, 3 Jun 2014 08:15:29 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5DB1A02F4 for ; Tue, 3 Jun 2014 08:15:28 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so6744110wib.5 for ; Tue, 03 Jun 2014 08:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SCvgyP0ja8axBzqwZG3XiECBx/HazT+yatqa/PT27Fs=; b=HkUU6bgAE9iPQVaqgldSfJ9GVBpbHunEAzecsYr4EHNvNFiIqafCgZITdgu0KFkPYe s7nUZKxnRH+Df9wIzhnn5Edjg7nlvw0YakrioXhbTML1ReXzvPSHR+qLdwMYSWwZrnqM bUTAYB9yiltNvSwjYi/lX6bblTjmp9bid9ftwgJI49n2ifMAMkrXy1JJYEt9K9hTXb0n /RzDc/GFvC/xdeQI4oGHd4YMmYsPMSeugS+HeuqO99776YRDjoX1CA+53dgdAdDNJ+v0 ZWOgJgxv6/SuqK2l0WXIFDpEWHOKkEvzOIr+nIylTkH+GaMn/MHDiU7MpJZRqqN4roMg V94Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SCvgyP0ja8axBzqwZG3XiECBx/HazT+yatqa/PT27Fs=; b=SP/JS8o5Je6V4rthdgHoUOZl2nTi1xAfmycsi5ym//Mkl5HG5SSWmmmilU7cDc3OeF 2vB2a2et3NOFnGOIZwjFe+Be90Uvl/1lgWQf0pkhHMfazgL0/EENU4WXD28DwrxDmiy2 SV7RbQMKzltirZDS9+NFZJ7RKPDj+efZl/9gq3hlA6cL9vhTDLH2fjBqevnAxWktRFNO /rV4A9OUR1ZouoKtMaiacYvIayDo2XyzpFfJaJIsGg8Ct13UKG7rpKykEBzcV9WnJyKG EBv8LLsVJFVGCUjP9uHeAhRgpMHXuEN9vrCljg5TDpE//oubyQOB7tI9lTEeE6QbOKJL /stw== X-Gm-Message-State: ALoCoQlsH/IEb2gX58dEbaBLAbGWhtgl4kJMQAjohvTCN7iZM4vWxB+i0GOsMo3bLfSHwRFrDSAi MIME-Version: 1.0 X-Received: by 10.180.19.201 with SMTP id h9mr33914928wie.17.1401808521387; Tue, 03 Jun 2014 08:15:21 -0700 (PDT) Received: by 10.194.36.166 with HTTP; Tue, 3 Jun 2014 08:15:21 -0700 (PDT) In-Reply-To: <538DE3EA.2030104@isi.edu> References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> Date: Tue, 3 Jun 2014 11:15:21 -0400 Message-ID: From: Neal Cardwell To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UTJJk65vkZTfWRRA8Lyqf7p281A Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 15:15:31 -0000 On Tue, Jun 3, 2014 at 11:04 AM, Joe Touch wrote: > Hi, Wes, > > Although I don't recall this and only scanned it briefly, I don't quite > understand the problem. > > I thought it was widely known that Nagle was useful for single-character > interactive traffic, but also widely known as something that should be > disabled for any multi-character interactive traffic - including > multi-character encodings, HTTP, etc. > > If Nagle is off - as it should be for interactive web traffic - then the > optimizations in this draft won't have any impact. > > So what kind of traffic does this actually help? Or is this an optimization > of a path that either isn't or shouldn't be used? The Minshall algorithm is a nice win for some workloads other than web traffic: Application performance pitfalls and TCP's Nagle algorithm http://dl.acm.org/citation.cfm?id=346012 neal > > Joe > > On 6/2/2014 6:58 PM, Wesley Eddy wrote: >> >> I was working on an issue with Nagle in a space system, and >> noticed that the Linux kernel actually implements the "Minshall" >> version of the Nagle algorithm, described nicely in: >> http://tools.ietf.org/html/draft-minshall-nagle-01 >> >> There are a couple later papers I was able to find also that >> describe this. >> >> To me, this looks like clearly a good thing that should be >> recommended in the RFCs where we currently just have discussion >> of "standard Nagle". Apparently it was adopted in Linux, but I >> wonder if it was picked up or not in other OSes as well. >> >> Does anyone have history on why this draft never progressed? >> Maybe someone has current contact information for Greg Minshall? >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jun 3 10:08:35 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C971A02F4 for ; Tue, 3 Jun 2014 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCMEJVf36AeH for ; Tue, 3 Jun 2014 10:08:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDD91A023D for ; Tue, 3 Jun 2014 10:08:26 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s53H7bO4015221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jun 2014 10:07:37 -0700 (PDT) Message-ID: <538E00D9.4030802@isi.edu> Date: Tue, 03 Jun 2014 10:07:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Neal Cardwell References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/hq5k6FjxDKWsZAwcvq1p1WrpYqE Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 17:08:32 -0000 On 6/3/2014 8:15 AM, Neal Cardwell wrote: > On Tue, Jun 3, 2014 at 11:04 AM, Joe Touch wrote: >> Hi, Wes, >> >> Although I don't recall this and only scanned it briefly, I don't quite >> understand the problem. >> >> I thought it was widely known that Nagle was useful for single-character >> interactive traffic, but also widely known as something that should be >> disabled for any multi-character interactive traffic - including >> multi-character encodings, HTTP, etc. >> >> If Nagle is off - as it should be for interactive web traffic - then the >> optimizations in this draft won't have any impact. >> >> So what kind of traffic does this actually help? Or is this an optimization >> of a path that either isn't or shouldn't be used? > > > The Minshall algorithm is a nice win for some workloads other than web traffic: > > Application performance pitfalls and TCP's Nagle algorithm > http://dl.acm.org/citation.cfm?id=346012 My point is that even by the time of this paper, it was well-understood that Nagle should not be used in these environments. The paper cites 1999 personal communication with Jim Gettys for this, but it was well-known long before it was recited as an issue in this 1996 paper: http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf The use case cited is quite dated - network news has been largely abandoned. Is there a currently relevant use case for this approach, and given that interactive apps already should be disabling Nagle, how much will it help? Joe From nobody Tue Jun 3 11:12:38 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1D61A025C for ; Tue, 3 Jun 2014 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WY852O6Q8sjf for ; Tue, 3 Jun 2014 11:12:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8551A0219 for ; Tue, 3 Jun 2014 11:12:33 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s53IBROR001102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jun 2014 11:11:27 -0700 (PDT) Message-ID: <538E0FCE.8030905@isi.edu> Date: Tue, 03 Jun 2014 11:11:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Sujeet Nayak A (sua)" , "tcpm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/X4PPmjbJE1WFvtXdkB8W6Y1kitM Cc: "Rohit M \(rrohit\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 03 Jun 2014 18:12:34 -0000 Hi, Sujeet, This doc should, AFAICT, update RFC 5926 It should also provide motivation for the need for SHA-2 - i.e., some of the discussion in the Security Considerations section should be mentioned in the abstract and explained in detail in the body (e.g., sections 1 or 2). Please scrub the use of RFC2119 language - I saw a couple of uses of the magic words that were not capitalized but should have been. IMO, the doc should also provide advice as to the necessity of these algorithms - are they MUST (likely not), SHOULD (probably not either), or MAY implement? Joe On 6/3/2014 12:21 AM, Sujeet Nayak A (sua) wrote: > Hi, > In the last few months, we have been seeing a lot of customer interest > for SHA-2 based auth on TCP-AO enabled connections. In this regard, we > (Brian Weis and myself) have posted a draft for the same: > http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 > > Pl. review and let me know your valuable comments. > > Regards, > > Sujeet Nayak A. > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jun 3 20:21:08 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322901A01CA for ; Tue, 3 Jun 2014 20:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzhtVDJDoED1 for ; Tue, 3 Jun 2014 20:21:04 -0700 (PDT) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4479B1A01CB for ; Tue, 3 Jun 2014 20:21:04 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s543KuIx022628 for ; Tue, 3 Jun 2014 23:20:56 -0400 Received: (qmail 4571 invoked by uid 0); 4 Jun 2014 03:20:56 -0000 X-TCPREMOTEIP: 69.81.143.143 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.108?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 4 Jun 2014 03:20:56 -0000 Message-ID: <538E9094.4020205@mti-systems.com> Date: Tue, 03 Jun 2014 23:20:52 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , Neal Cardwell References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> <538E00D9.4030802@isi.edu> In-Reply-To: <538E00D9.4030802@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/qQ_J0MLFMrYfftYExlWZPvDM_2o Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 03:21:06 -0000 On 6/3/2014 1:07 PM, Joe Touch wrote: > > > On 6/3/2014 8:15 AM, Neal Cardwell wrote: >> On Tue, Jun 3, 2014 at 11:04 AM, Joe Touch wrote: >>> Hi, Wes, >>> >>> Although I don't recall this and only scanned it briefly, I don't quite >>> understand the problem. >>> >>> I thought it was widely known that Nagle was useful for single-character >>> interactive traffic, but also widely known as something that should be >>> disabled for any multi-character interactive traffic - including >>> multi-character encodings, HTTP, etc. >>> >>> If Nagle is off - as it should be for interactive web traffic - then the >>> optimizations in this draft won't have any impact. >>> >>> So what kind of traffic does this actually help? Or is this an >>> optimization >>> of a path that either isn't or shouldn't be used? >> >> >> The Minshall algorithm is a nice win for some workloads other than web >> traffic: >> >> Application performance pitfalls and TCP's Nagle algorithm >> http://dl.acm.org/citation.cfm?id=346012 > > My point is that even by the time of this paper, it was well-understood > that Nagle should not be used in these environments. The paper cites > 1999 personal communication with Jim Gettys for this, but it was > well-known long before it was recited as an issue in this 1996 paper: > http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf Even before that! RFC 1122 (from 1989) says: Some applications (e.g., real-time display window updates) require that the Nagle algorithm be turned off, so small data segments can be streamed out at the maximum rate. > The use case cited is quite dated - network news has been largely > abandoned. Is there a currently relevant use case for this approach, and > given that interactive apps already should be disabling Nagle, how much > will it help? > I agree that disabling Nagle for "interactive" flows should be a recognized best current practice. (assuming they're aiming for a packets/segments per second rate that isn't absurd) I think this would be a part of the "TCP Usage Guidelines" analogue to RFC 5405 (for UDP) that Lars once thought about. Since Nagle is on by default in many OSes, and deciding to turn it off means a developer has to know what it is, and that it's even there to be turned off, the Minshall tweak to Nagle does seem to make it "more friendly" default to a diversity of application behaviors (small writes, or odd patterns of writes), while retaining the benefit of conserving packet count. I've noticed some people seem to have a tendency to disable Nagle automatically, whether or not that's really necessary, since maybe it bit them once in the distant past, and was difficult to debug or understand. The Minshall flavor stands a better chance of not indoctrinating people against Nagle this way. That said, this is not a burning problem. -- Wes Eddy MTI Systems From nobody Wed Jun 4 01:37:26 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4E41A010D for ; Wed, 4 Jun 2014 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lohFV_f2s5Bd for ; Wed, 4 Jun 2014 01:37:23 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E6AAB1A0109 for ; Wed, 4 Jun 2014 01:37:22 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E5D912B40B9; Wed, 4 Jun 2014 09:37:15 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 4 Jun 2014 09:37:16 +0100 Message-ID: <208ef728a25b85b5182fd557627ce3ea.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <538E9094.4020205@mti-systems.com> References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> <538E00D9.4030802@isi.edu> <538E9094.4020205@mti-systems.com> Date: Wed, 4 Jun 2014 09:37:16 +0100 From: gorry@erg.abdn.ac.uk To: "Wesley Eddy" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EVH529bHslwih_D5avUCIsa1xkw Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 08:37:25 -0000 And... In the old days programmers knew an app would nearly always send small packets and Nagle needed to be disabled. For many modern apps that is far less obvious - Nagle may be disabled simply because people think it is better to do so without really understanding the requirements, or they may simply not know what the network traffic will look like - Some TCP connections vary their traffic patterns over time. Gorry > On 6/3/2014 1:07 PM, Joe Touch wrote: >> >> >> On 6/3/2014 8:15 AM, Neal Cardwell wrote: >>> On Tue, Jun 3, 2014 at 11:04 AM, Joe Touch wrote: >>>> Hi, Wes, >>>> >>>> Although I don't recall this and only scanned it briefly, I don't >>>> quite >>>> understand the problem. >>>> >>>> I thought it was widely known that Nagle was useful for >>>> single-character >>>> interactive traffic, but also widely known as something that should be >>>> disabled for any multi-character interactive traffic - including >>>> multi-character encodings, HTTP, etc. >>>> >>>> If Nagle is off - as it should be for interactive web traffic - then >>>> the >>>> optimizations in this draft won't have any impact. >>>> >>>> So what kind of traffic does this actually help? Or is this an >>>> optimization >>>> of a path that either isn't or shouldn't be used? >>> >>> >>> The Minshall algorithm is a nice win for some workloads other than web >>> traffic: >>> >>> Application performance pitfalls and TCP's Nagle algorithm >>> http://dl.acm.org/citation.cfm?id=346012 >> >> My point is that even by the time of this paper, it was well-understood >> that Nagle should not be used in these environments. The paper cites >> 1999 personal communication with Jim Gettys for this, but it was >> well-known long before it was recited as an issue in this 1996 paper: >> http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf > > > Even before that! RFC 1122 (from 1989) says: > > Some applications (e.g., real-time display window > updates) require that the Nagle algorithm be turned > off, so small data segments can be streamed out at the > maximum rate. > > >> The use case cited is quite dated - network news has been largely >> abandoned. Is there a currently relevant use case for this approach, and >> given that interactive apps already should be disabling Nagle, how much >> will it help? >> > > > I agree that disabling Nagle for "interactive" flows should be a > recognized best current practice. (assuming they're aiming for > a packets/segments per second rate that isn't absurd) > > I think this would be a part of the "TCP Usage Guidelines" > analogue to RFC 5405 (for UDP) that Lars once thought about. > > Since Nagle is on by default in many OSes, and deciding to turn > it off means a developer has to know what it is, and that it's > even there to be turned off, the Minshall tweak to Nagle does > seem to make it "more friendly" default to a diversity of > application behaviors (small writes, or odd patterns of writes), > while retaining the benefit of conserving packet count. > > I've noticed some people seem to have a tendency to disable Nagle > automatically, whether or not that's really necessary, since > maybe it bit them once in the distant past, and was difficult to > debug or understand. The Minshall flavor stands a better chance > of not indoctrinating people against Nagle this way. > > That said, this is not a burning problem. > > -- > Wes Eddy > MTI Systems > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From minshall@acm.org Tue Jun 3 12:40:50 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799B21A035B for ; Tue, 3 Jun 2014 12:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNL7f3zU25ji for ; Tue, 3 Jun 2014 12:40:49 -0700 (PDT) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by ietfa.amsl.com (Postfix) with SMTP id 031BF1A034F for ; Tue, 3 Jun 2014 12:40:48 -0700 (PDT) Received: (qmail 97338 invoked by uid 0); 3 Jun 2014 19:40:41 -0000 Received: from 85.108.156.214 (HELO gregair.cliq.com) (85.108.156.214) by relay00.pair.com with SMTP; 3 Jun 2014 19:40:41 -0000 X-pair-Authenticated: 85.108.156.214 Received: from greg-minshalls-mbp.local (localhost [127.0.0.1]) by gregair.cliq.com (Postfix) with ESMTP id 18A63427AA5D8; Tue, 3 Jun 2014 22:40:41 +0300 (EEST) From: Greg Minshall To: "Eggert, Lars" In-reply-to: Your message of "Tue, 03 Jun 2014 06:05:19 -0000." X-Mailer: MH-E 8.5; nmh 1.5; GNU Emacs 24.3.1 Date: Tue, 03 Jun 2014 22:40:41 +0300 Message-ID: <76411.1401824441@greg-minshalls-mbp.local> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/8ZAlHtyr860yjkRzOmA-yeJX-dw X-Mailman-Approved-At: Wed, 04 Jun 2014 08:19:51 -0700 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 03:13:21 -0000 Lars, et al., i had heard that the Linux kernel implemented my proposed mods to Nagle's algorithm, but i haven't looked at that implementation. i don't have any memory of any similar modifications being released in, e.g., *BSD. (i did make some mods to FreeBSD, but i don't think i ever released them.) i also don't remember why the draft didn't progress, though probably i dropped the ball somewhere. hope that helps. cheers, Greg From nobody Wed Jun 4 09:56:49 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172E81A02E8 for ; Wed, 4 Jun 2014 09:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdQooojG1os0 for ; Wed, 4 Jun 2014 09:56:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643AB1A037D for ; Wed, 4 Jun 2014 09:56:44 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s54GtWN6003268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jun 2014 09:55:33 -0700 (PDT) Message-ID: <538F4F84.6040004@isi.edu> Date: Wed, 04 Jun 2014 09:55:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wesley Eddy , Neal Cardwell References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> <538E00D9.4030802@isi.edu> <538E9094.4020205@mti-systems.com> In-Reply-To: <538E9094.4020205@mti-systems.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nW-wKWNFAVfQDxL1ywEfEdOp_is Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 16:56:48 -0000 On 6/3/2014 8:20 PM, Wesley Eddy wrote: > On 6/3/2014 1:07 PM, Joe Touch wrote: ... >> My point is that even by the time of this paper, it was well-understood >> that Nagle should not be used in these environments. The paper cites >> 1999 personal communication with Jim Gettys for this, but it was >> well-known long before it was recited as an issue in this 1996 paper: >> http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf > > Even before that! RFC 1122 (from 1989) says: > > Some applications (e.g., real-time display window > updates) require that the Nagle algorithm be turned > off, so small data segments can be streamed out at the > maximum rate. I saw that, but it's more than for displays; it's actually anything *interactive* where the data unit is longer than one byte (e.g., Unicode telnet!). >> The use case cited is quite dated - network news has been largely >> abandoned. Is there a currently relevant use case for this approach, and >> given that interactive apps already should be disabling Nagle, how much >> will it help? > > > I agree that disabling Nagle for "interactive" flows should be a > recognized best current practice. (assuming they're aiming for > a packets/segments per second rate that isn't absurd) > > I think this would be a part of the "TCP Usage Guidelines" > analogue to RFC 5405 (for UDP) that Lars once thought about. > > Since Nagle is on by default in many OSes, and deciding to turn > it off means a developer has to know what it is, and that it's > even there to be turned off, I didn't think O_NODELAY was all that cryptic... > the Minshall tweak to Nagle does > seem to make it "more friendly" default to a diversity of > application behaviors (small writes, or odd patterns of writes), > while retaining the benefit of conserving packet count. > > I've noticed some people seem to have a tendency to disable Nagle > automatically, whether or not that's really necessary, since > maybe it bit them once in the distant past, and was difficult to > debug or understand. The Minshall flavor stands a better chance > of not indoctrinating people against Nagle this way. Nagle is useful in a very small use case that no longer exists - it's rare that we have interactive traffic that we know can be split at a byte boundary. > That said, this is not a burning problem. Agreed. Joe From nobody Wed Jun 4 10:34:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532491A0232 for ; Wed, 4 Jun 2014 10:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmc2VPRs1gLd for ; Wed, 4 Jun 2014 10:33:48 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B961A0141 for ; Wed, 4 Jun 2014 10:33:48 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so8026176obc.21 for ; Wed, 04 Jun 2014 10:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DIccZIEr8r+SimhTtJc4n1aC8my6a81JbkosoQQyS5M=; b=o6K+B73g3fahFv9RcmK6Svkn4nDJulK2X63p/6G1EQWP4ecxD4YPyVMTf/qMzhutCE WSEE8cXATnZhcqFZMkhOgTEesvytjxsvyCmEztj4LvfZ+f4WxVneqi5bwBiK/KIM8vaO 8cD+IsjlO/Lry+9ZedsoGQMsI6jlshftJsqwdul8XXK+xxO0/shouU+vIqMdJPMJyJ3x j32NwOCP27NzZpo/6G7ttw4S0TTPrrPaRgsPyiK8HnNnykMkZXxrUWwU0kkj4wJWrox+ /rFH2WTZkDMMCktebRtwye0m5VJzHM+7HXuPtMCVfuMt0wxgCASzN8E1Dz+Z/Rq/Pb+7 qw/Q== MIME-Version: 1.0 X-Received: by 10.60.44.243 with SMTP id h19mr59547993oem.46.1401903222401; Wed, 04 Jun 2014 10:33:42 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.76.73.100 with HTTP; Wed, 4 Jun 2014 10:33:42 -0700 (PDT) In-Reply-To: <538F4F84.6040004@isi.edu> References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> <538E00D9.4030802@isi.edu> <538E9094.4020205@mti-systems.com> <538F4F84.6040004@isi.edu> Date: Wed, 4 Jun 2014 13:33:42 -0400 X-Google-Sender-Auth: kR6cRCQFw162Epn9qFa4fhhG2gA Message-ID: From: Jim Gettys To: Joe Touch Content-Type: multipart/alternative; boundary=001a11331cb094b4af04fb06078b Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4G4Po0v7hRwennHlkbhICjG5k9g Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 17:33:51 -0000 --001a11331cb094b4af04fb06078b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2014 at 12:55 PM, Joe Touch wrote: > > > On 6/3/2014 8:20 PM, Wesley Eddy wrote: > >> On 6/3/2014 1:07 PM, Joe Touch wrote: >> > ... > > My point is that even by the time of this paper, it was well-understood >>> that Nagle should not be used in these environments. The paper cites >>> 1999 personal communication with Jim Gettys for this, but it was >>> well-known long before it was recited as an issue in this 1996 paper: >>> http://ccr.sigcomm.org/archive/1997/apr97/ccr-9704-heidemann.pdf >>> >> >> Even before that! RFC 1122 (from 1989) says: >> >> Some applications (e.g., real-time display window >> updates) require that the Nagle algorithm be turned >> off, so small data segments can be streamed out at the >> maximum rate. >> > > I saw that, but it's more than for displays; it's actually anything > *interactive* where the data unit is longer than one byte (e.g., Unicode > telnet!). =E2=80=8BThe history of the reference to me is the following: 1) Bob Scheifler and I had developed early versions of the X Window System. 2) when a new BSD release came out (or it may have been a new snapshot of the network stack, as there was the BSD vs. BBN TCP stack wars going on), performance of rubber band tracking got dramatically worse. We tracked it down to the addition of Nagle: and shortly thereafter, TCP_NODELAY was born: I don't remember whether Bob coded it up, or Mike Karels. Specifically, the delay of sending mouse event packets to applications over the X protocol was terrible to interactive performance. These mouse events were around 24 bytes at the time, IIRC (X11 the events are 32 bytes). As the X server and client library do various forms of buffering, having the OS get in the way is not good. And you *never* want to delay interactive traffic by anything on the timescale required to merge keystrokes, which, as I remember, was the original intent of the optimization. Unfortunately, I believe the default (being on) is wrong. But it's far too late to make that change. =E2=80=8B > > > The use case cited is quite dated - network news has been largely >>> abandoned. Is there a currently relevant use case for this approach, an= d >>> given that interactive apps already should be disabling Nagle, how much >>> will it help? >>> >> >> >> I agree that disabling Nagle for "interactive" flows should be a >> recognized best current practice. (assuming they're aiming for >> a packets/segments per second rate that isn't absurd) >> >> I think this would be a part of the "TCP Usage Guidelines" >> analogue to RFC 5405 (for UDP) that Lars once thought about. >> >> Since Nagle is on by default in many OSes, and deciding to turn >> it off means a developer has to know what it is, and that it's >> even there to be turned off, >> > > I didn't think O_NODELAY was all that cryptic... =E2=80=8BAnd many poor developers have been bit with it being on over the d= ecades. They naively think that data will be transmitted when you ask the operating system. It surprises them badly when it does not... - Jim =E2=80=8B > > > > the Minshall tweak to Nagle does >> seem to make it "more friendly" default to a diversity of >> application behaviors (small writes, or odd patterns of writes), >> while retaining the benefit of conserving packet count. >> >> I've noticed some people seem to have a tendency to disable Nagle >> automatically, whether or not that's really necessary, since >> maybe it bit them once in the distant past, and was difficult to >> debug or understand. The Minshall flavor stands a better chance >> of not indoctrinating people against Nagle this way. >> > > Nagle is useful in a very small use case that no longer exists - it's rar= e > that we have interactive traffic that we know can be split at a byte > boundary. > > > That said, this is not a burning problem. >> > > Agreed. > > Joe > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a11331cb094b4af04fb06078b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Jun 4, 2014 at 12:55 PM, Joe Touch <touch@isi.edu> wrote:


On 6/3/2014 8:20 PM, Wesley Eddy wrote:
On 6/3/2014 1:07 PM, Joe Touch wrote:
...

My point is that even by the time of this paper, it was well-understood
that Nagle should not be used in these environments. The paper cites
1999 personal communication with Jim Gettys for this, but it was
well-known long before it was recited as an issue in this 1996 paper:
http://ccr.sigcomm.org/archive/1997/apr97/ccr-97= 04-heidemann.pdf

Even before that! =C2=A0RFC 1122 (from 1989) says:

=C2=A0 =C2=A0 Some applications (e.g., real-time display window
=C2=A0 =C2=A0 updates) require that the Nagle algorithm be turned
=C2=A0 =C2=A0 off, so small data segments can be streamed out at the
=C2=A0 =C2=A0 maximum rate.

I saw that, but it's more than for displays; it's actually anything= *interactive* where the data unit is longer than one byte (e.g., Unicode t= elnet!).

=E2=80=8BThe history of the reference to me is the following:

1) Bob Scheifle= r and I had developed early versions of the X Window System.
2) when a new BSD release came out (or it may have been a new snapshot of t= he network stack, as there was the BSD vs. BBN TCP stack wars going on), pe= rformance of rubber band tracking got dramatically worse. =C2=A0

We trac= ked it down to the addition of Nagle: and shortly thereafter, TCP_NODELAY w= as born: I don't remember whether Bob coded it up, or Mike Karels.

Specifically, the delay of sending mouse event packet= s to applications over the X protocol was terrible to interactive performan= ce. =C2=A0These mouse events were around 24 bytes at the time, IIRC (X11 th= e events are 32 bytes). =C2=A0As the X server and client library do various= forms of buffering, having the OS get in the way is not good. =C2=A0And yo= u *never* want to delay interactive traffic by anything on the timescale re= quired to merge keystrokes, which, as I remember, was the original intent o= f the optimization.

U= nfortunately, I believe the default (being on) is wrong. =C2=A0But it's= far too late to make that change.
=E2=80=8B


The use case cited is quite dated - network news has been largely
abandoned. Is there a currently relevant use case for this approach, and given that interactive apps already should be disabling Nagle, how much
will it help?


I agree that disabling Nagle for "interactive" flows should be a<= br> recognized best current practice. =C2=A0(assuming they're aiming for a packets/segments per second rate that isn't absurd)

I think this would be a part of the "TCP Usage Guidelines"
analogue to RFC 5405 (for UDP) that Lars once thought about.

Since Nagle is on by default in many OSes, and deciding to turn
it off means a developer has to know what it is, and that it's
even there to be turned off,

I didn't think O_NODELAY was all that cryptic...

<= /div>
=E2=80=8BAnd ma= ny poor developers have been bit with it being on over the decades. They na= ively think that data will be transmitted when you ask the operating system= . =C2=A0It surprises them badly when it does not...
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Jim

=E2=80=8B



the Minshall tweak to Nagle does
seem to make it "more friendly" default to a diversity of
application behaviors (small writes, or odd patterns of writes),
while retaining the benefit of conserving packet count.

I've noticed some people seem to have a tendency to disable Nagle
automatically, whether or not that's really necessary, since
maybe it bit them once in the distant past, and was difficult to
debug or understand. =C2=A0The Minshall flavor stands a better chance
of not indoctrinating people against Nagle this way.

Nagle is useful in a very small use case that no longer exists - it's r= are that we have interactive traffic that we know can be split at a byte bo= undary.


That said, this is not a burning problem.

Agreed.

Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm

--001a11331cb094b4af04fb06078b-- From nobody Wed Jun 4 10:42:21 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB61A035C for ; Wed, 4 Jun 2014 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZT-fKs3cvfJ for ; Wed, 4 Jun 2014 10:42:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAF51A02D9 for ; Wed, 4 Jun 2014 10:42:18 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s54Henex014089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Jun 2014 10:40:49 -0700 (PDT) Message-ID: <538F5A20.8090005@isi.edu> Date: Wed, 04 Jun 2014 10:40:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jim Gettys References: <538D2BCC.8030906@mti-systems.com> <538DE3EA.2030104@isi.edu> <538E00D9.4030802@isi.edu> <538E9094.4020205@mti-systems.com> <538F4F84.6040004@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pXxd0RgIo-Ai_xmga7T4Avotz0w Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 17:42:19 -0000 On 6/4/2014 10:33 AM, Jim Gettys wrote: > Unfortunately, I believe the default (being on) is wrong. But it's far > too late to make that change. We can try ;-) That might be a useful place to start. Joe From nobody Wed Jun 4 11:07:22 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66FA1A0312 for ; Wed, 4 Jun 2014 11:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnBBpRwVHP7g for ; Wed, 4 Jun 2014 11:07:17 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50FD1A0331 for ; Wed, 4 Jun 2014 11:07:16 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.5/8.14.5) with SMTP id s54HxdXj004194; Wed, 4 Jun 2014 11:07:09 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 1m9gk31yy6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 04 Jun 2014 11:07:08 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 12:06:18 -0600 Received: from PPOMSG1.QUANTUM.com ([10.50.35.26]) by ppomsg2 ([10.50.35.27]) with mapi id 14.03.0158.001; Wed, 4 Jun 2014 12:07:07 -0600 From: David Borman To: Greg Minshall Thread-Topic: [tcpm] draft-minshall-nagle Thread-Index: AQHPgB/LsB02X1NvqUu2hQrvBHJgag== Date: Wed, 4 Jun 2014 18:07:06 +0000 Message-ID: <08CCAE10-17D6-42BC-9116-033FDBDCB0AF@quantum.com> References: <76411.1401824441@greg-minshalls-mbp.local> In-Reply-To: <76411.1401824441@greg-minshalls-mbp.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.176.229] Content-ID: <39CF719C73537448ADD04AB2E402E50F@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-04_04:2014-06-04,2014-06-04,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=1.23401289187086e-13 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.0734735701287243 urlsuspect_oldscore=0.0734735701287243 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.0734735701287243 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406040224 Content-Type: text/plain; charset="Windows-1252" Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Cm6rEpNGUNfMglmMsvu0sSxXFYo Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 04 Jun 2014 18:07:21 -0000 So, since I=92m in the acknowledgement section of the draft, I did some dig= ging to see if I could discover what I contributed. One message I sent at = the time shows the BSD/OS did implement some of these ideas. You can find = it at: http://roland.grc.nasa.gov/tcp-impl/list/archive/1498.html All the previous discussion is in the tcp-impl archives, there were two thr= eads, starting at: http://roland.grc.nasa.gov/tcp-impl/list/archive/1475.html http://roland.grc.nasa.gov/tcp-impl/list/archive/1743.html It=92s probably worth looking over the previous discussions before rehashin= g it all over again. :-) -David Borman On Jun 3, 2014, at 2:40 PM, Greg Minshall wrote: > Lars, et al., >=20 > i had heard that the Linux kernel implemented my proposed mods to > Nagle's algorithm, but i haven't looked at that implementation. i don't > have any memory of any similar modifications being released in, e.g., > *BSD. (i did make some mods to FreeBSD, but i don't think i ever > released them.) i also don't remember why the draft didn't progress, > though probably i dropped the ball somewhere. hope that helps. >=20 > cheers, Greg >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From nobody Thu Jun 5 13:34:14 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8F1A02F2 for ; Thu, 5 Jun 2014 13:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NkbSJ749ZmO for ; Thu, 5 Jun 2014 13:34:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C96E1A02B5 for ; Thu, 5 Jun 2014 13:34:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s55KWiox021456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jun 2014 13:32:44 -0700 (PDT) Message-ID: <5390D3EC.4020701@isi.edu> Date: Thu, 05 Jun 2014 13:32:44 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Borman , Greg Minshall References: <76411.1401824441@greg-minshalls-mbp.local> <08CCAE10-17D6-42BC-9116-033FDBDCB0AF@quantum.com> In-Reply-To: <08CCAE10-17D6-42BC-9116-033FDBDCB0AF@quantum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/nRuG-otxukKLIThQt_w29TseWxI Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-minshall-nagle X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 05 Jun 2014 20:34:13 -0000 Hi, David, Yes - those points raised before are probably still as relevant, but the broader point that Jim G. raised was never considered before - why not just push to change the default? We've long since evolved past a world where we can make assumptions that a TCP stream can safely be stalled at an arbitrary byte boundary... Joe On 6/4/2014 11:07 AM, David Borman wrote: > So, since Im in the acknowledgement section of the draft, I did some digging to see if I could discover what I contributed. One message I sent at the time shows the BSD/OS did implement some of these ideas. You can find it at: > http://roland.grc.nasa.gov/tcp-impl/list/archive/1498.html > > All the previous discussion is in the tcp-impl archives, there were two threads, starting at: > > http://roland.grc.nasa.gov/tcp-impl/list/archive/1475.html > http://roland.grc.nasa.gov/tcp-impl/list/archive/1743.html > > Its probably worth looking over the previous discussions before rehashing it all over again. :-) > > -David Borman > > On Jun 3, 2014, at 2:40 PM, Greg Minshall wrote: > >> Lars, et al., >> >> i had heard that the Linux kernel implemented my proposed mods to >> Nagle's algorithm, but i haven't looked at that implementation. i don't >> have any memory of any similar modifications being released in, e.g., >> *BSD. (i did make some mods to FreeBSD, but i don't think i ever >> released them.) i also don't remember why the draft didn't progress, >> though probably i dropped the ball somewhere. hope that helps. >> >> cheers, Greg >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Sun Jun 8 23:39:51 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469251A0353 for ; Sun, 8 Jun 2014 23:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyW5gYi_P2oH for ; Sun, 8 Jun 2014 23:39:47 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58F41A0303 for ; Sun, 8 Jun 2014 23:39:46 -0700 (PDT) X-Spam-Processed: mail.kau.se, Mon, 09 Jun 2014 08:39:14 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: perhurt@kau.se X-MDRemoteIP: 130.243.25.129 X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Message-ID: <5395569F.6070303@kau.se> Date: Mon, 09 Jun 2014 08:39:27 +0200 From: Per Hurtig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Zimmermann, Alexander" References: <38DA60FD-7629-4FCB-BD19-830FC7F5232C@netapp.com> <8CEBB7AD-88F3-45CA-A1C6-D5306EEE02B3@kau.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/5IzguuxVK8DlCasya_5tssSnKs0 Cc: "draft-ietf-tcpm-rtorestart@tools.ietf.org" , "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Review of draft-ietf-tcpm-rtorestart-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Jun 2014 06:39:49 -0000 Sorry for the late reply, On 2014-05-21 10:28, Zimmermann, Alexander wrote: > Hi Per, > > Am 15.05.2014 um 12:00 schrieb Per Hurtig : > >> Hi Alexander >> >> thanks for the review, please see my comments inline >> >> >> On 13 May 2014, at 11:57, Zimmermann, Alexander wrote: >> >>> Hi folks, >>> >>> first of all thank you for writing this draft. The draft is clearly written: the >>> problem is well described, the doc is self-contained (its not necessary to read >>> dozens of other RFCs to understand the problem), and the authors state why the >>> doc is experimental and what further experiments are needed for being a STD. >>> However, on the technical side I see some open points. In detail: >>> >>> * Sec 1, 4. para: a considerable number of flows have such properties >>> Can you backup this with some numbers? This is exactly the point I raised at the >>> (last?) IETF. I would like to see some data on how severe the problem is we would >>> like to fix. >>> >> >> For short flows (e.g. web) there are a number of references in the draft. These are >> the primary target for the mechanism. Well elaborate some more on the importance >> for other types of traffic. > > Your draft focus on two different kinds of flows: a) on short flows and b) on flows > w/ low transmission rates. For the former you give two references [RJ10] and [FDT13], > but not for the latter. You say that a considerable number of flows have such > properties and my question was, if you can backup this w/ some numbers. Additionally, > Yuchung reports that he wasnt able to see much improvements while implementing your > scheme. Do you have some data that you can share to see how much your scheme helps to > improve the latency? Yes, we just recently completed a series of experiments and are currently finishing the analysis. The results look good, but we'll come back shortly to the list with details. > > Also Im not sure if we really focus on short flows. Is it not rather the case that we > concentrate us on tail losses? Your scheme will not only kick in for short flows, it > gets activated at the end of any stream. Or do I miss something here? (BTW [FDT13] > reports that 77% of the RXmits are RTO-based, it doesnt say that 77% are short flows.) > That's correct, the focus is indeed tail loss. >> >> >>> * Sec 1.1: please change this subsection to a section (1.1 => 2) and also >>> introduce your new state variable rrthresh here >>> >> >> I dont get why the section should be renumbered. The terminology is often the >> last subsection of the introduction of most drafts and RFCs. > > This was only a nit. In German language we have the grammar rule that you cannot > introduce a subsection x.1 if you dont have a second subsection in the same section. > While searching a little bit in the web, it seems that is also valid in English > (http://www.cs.berkeley.edu/~pattrsn/talks/writingtips.html). Anyway, it was only > a nit :-) > Well, you do have a point. A single subsection is not a beautiful thing, regardless of language :) >> Furthermore, it seems >> slightly overkill to introduce the variable there. RFCs that manages many more >> variables, e.g. RFC6298 does not explicitly introduce any variable in this section. > > and RFC 5681 or RFC 6675 are counterexamples :-) Anyway, the question is more whether > or not we need an additional state variable in the TCB. If you think that they are cases > possible where rrthresh should not be initialized with dupthresh + 1', then we should > introduce the state variable and explain why we need it. Otherwise, I recommend do > use dupthresh + 1 instead of 'rrthresh > ok, will fix. >> >>> * Sec 1, 5. para: Spurious timeouts typically degrade the performance of flows >>> with multiple bursts of data, as a burst following a spurious timeout might >>> not fit within the reduced congestion window (cwnd) >>> >>> This is (only) true with respect to your algo, not in general. The general >>> problem of a spurious timeout is the cwnd reduction, the go-back-N >>> retransmissions, See RFC 3522. After reading section 4.2 of your draft I >>> understand what you want to see here. Please rephrase the section and maybe >>> add the spurious RTO RFC as reference. >>> >> What is meant is the actual cwnd reduction. We should clarify this. >> >> >>> * Sec 3: Suppose FlightSize is 2 and you have exactly one segment to send, >>> your algo doesnt trigger since step 2.b isnt true. Bug? I would say yes. >>> >> Good catch! The question is if its worth fixing since the algorithm will >> become more complex > > Not really. You can 1) restart your RTO (as usual), 2) transmit new data, > 3) re-arm your RTO with RTO - T_earliest if FlightSize < 4. In terms of re-arming > we did more or less the same in RFC6069 > Will check you RFC and see if it's applicable in our scenario, thanks. >> and the situation you mention is really a corner case that >> requires either (i) the cwnd to be exactly 3 segments large; > > less than 4, no? > After you reported this, we went through it rather carefully, and I actually thinks its *exactly* 3, but it was I while ago and I might remember this incorrectly. >> or (ii) having a >> packet written to the socket just between previous data transmission and the >> arrival of the acknowledgment. > > Yes > >> >> Furthermore, this mechanism is only an optimization to the standard timer. So >> if it doesnt work in this particular scenario it wont break anything. > > Sure, but if we exclude some traffic pattern which we can on the other hand > easily include by a small algo change, we should do that. Nevertheless, you > are right if we only speak here about rare corner cases (and I dont know > the answer) we can ignore them. > >> It will >> just not be triggered. >> >>> * Sec 3: Why the condition 2.b is different from the early retransmission >>> condition 2.b or 3.b? Is there any specific reason why we exclude the >>> advertised receive window part from the condition? >>> >> Because the advertised window can be small in situations where its not >> preferable to use RTO restart. For instance, in the middle of a transfer where >> its better to wait for fast/early retransmit to kick in. > > Ah, OK I see. Could you please explain this in the draft? Is it valid to say > that RTO restart try to cover all cases where early retransmit doest work? > I have the feeling that I not fully understand which cases should be covered by > which algo. > Will clarify it! Thank you once again for reviewing, Per >> >>> * Sec 3: IMO the algo/doc is too much Linux driven. I would like to see a >>> segment-based *and* byte-based version of the algo, like RFC 5827. >>> >> Yes, this comment was given by several people at the last IETF. We will update >> the draft to address this. >> >>> * General: IMO I would be a little bit easier to read the doc if you give the >>> algo a proper name. By reading RTO restart I had sometimes trouble to >>> know if mean your algo or the action of restarting the RTO. >>> >> Agreed, this will be fixed. >> >> >> >> Thank you, >> Per Hurtig >> >>> >>> Alex >>> >>> >>> >> >> > From nobody Mon Jun 9 11:48:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E901A02A4 for ; Mon, 9 Jun 2014 11:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gu0Eskn4HBe for ; Mon, 9 Jun 2014 11:48:49 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4D31A029F for ; Mon, 9 Jun 2014 11:48:49 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so2247314igi.12 for ; Mon, 09 Jun 2014 11:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b12oiWNH7MLFnPyyJx2h6D5m8XL1rz03luXsx0SymQg=; b=XJPoCBChQGT+QU14ZXOgufsk112wJGqARVjgJecnXir7YJxMf9xGXnkDWXTvIQV1Jd zo9x6RLIJlt1YQ07iCHWRvrucBe4ZkW1VYK6C770poElFkZ2ZlX7TFXi3afGYTwG0qRL tku34fi5vpSo9u3BB/quCGtOoAzRrFR5GWdzATkLwmZoNBpnKafRaAdbwCM2tKd0EtQE b17WPwhnvBH/fXzNZSpqFSKqK5jUuJw/d4NX+BFwkbLLlbfxm8XeXkIyrs0n5YQ//pJ2 0tSzy1E1Gzfwi38/fSbaaH5jYeKC44XrVeV+2UFasp52U6WShkzPbMKVbbsNsMPSL1Y2 YJOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=b12oiWNH7MLFnPyyJx2h6D5m8XL1rz03luXsx0SymQg=; b=fsD515R2iJyyLunPT8FvVSY39nLV1z5KtZCYdUD8FBCFflieYAuH9M4kFTW/k05iIy UnTCDC69vKnPaGmtrVjQGQ0DUHH8ZtM/iQYhbs7JVrRdz/qtG2c5S9oTDYvRUm1i6c/3 4tnaaJoo5dP16959Cjiuv62D7WGsQim5rQedSAD/tnlWbmiBdtxdLrBRKH7iFLVf4Bpl B5lgqKZ6rjOFgg5IvyoMoqJEjVQk4aG1b3gV+IVUHWC07V5VugTBalzc9JpOCakkiSrC 5Tl8bxj/2IbTAApg3aDHtQ2+tVy79a9GhA6eb4y4Ha2EPR50Po//acEyeWceSCD+Rkjl milg== X-Gm-Message-State: ALoCoQmrOjAHC3VMrylGzkgCfqLjVhtmijEssvhKfmEaG74QPMU2wk9mmbIlxGyyDcXlGXGB9zlb X-Received: by 10.42.99.10 with SMTP id u10mr33214433icn.9.1402339728774; Mon, 09 Jun 2014 11:48:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.163 with HTTP; Mon, 9 Jun 2014 11:48:08 -0700 (PDT) In-Reply-To: <20140602203540.C48727825A0@lawyers.icir.org> References: <538CDB07.2090306@isi.edu> <20140602203540.C48727825A0@lawyers.icir.org> From: Yuchung Cheng Date: Mon, 9 Jun 2014 11:48:08 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/CW1tU3uYp51WghKANkkIKZGjnYY Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 09 Jun 2014 18:48:51 -0000 On Mon, Jun 2, 2014 at 1:35 PM, Mark Allman wrote: > > > > You talk about limiting the rate; that doesn't help a connection > > that cannot proceed because packets with the TS option are being > > dropped, e.g., by a midbox. > > Sure- in a spec you'd have to consider that. But, I am not going to > pretend that it is difficult to detect and react to. > > > Further, what happens to the packets? When and how do you know when > > the TS isn't working? When do you give up? > > One RTT later. Don't pretend this is difficult. I didn't fully specify > it in an **email message**, but don't pretend this is some leap into > the Great Protocol Engineering Unknown, Joe. > > > 1323bis talks about a list of mechanisms that rely on timestamps, more > > than just PAWS. What happens to those when TS is optional or started > > late? > > If you want to use something and that something needs the TS option to > be on for the entire connection (e.g., Eifel) then you turn it on for > the entire connection. Fine. I have no problem with that. But, then > you're not simply wasting 10 bytes in every packet, but you're getting > something for it. Or we can just (dynamically) start tagging TS on retransmission to support Eifel. We have developed some nice features that use TS but 12 bytes is not trivial. It could also cost a sack block. I would love to see proposals that support these features w/o requiring always-on TS. > > However, on its own 1323(bis) wastes 10 bytes in every packet because > RTTM is not helpful and PAWS is nearly never needed. So, it seems to me I second that TS RTTM is marginally helpful. In non-retransmitted sequence it's useless b/c ACK/SACK take care of it and they are less vulnerable to bad middleboxes. We've seen middleboxes messing TS option values. Even in retransmitted cases, TS can only be used if the ACK advances SND_UNA. So if some retransmission are lost again then TS aren't useful to get RTTM. Therefore Linux has changed to use TS as the last resort in RTTM. http://lxr.linux.no/linux+v3.15/net/ipv4/tcp_input.c#L2887 > that instead of dogmatically putting our foot down we could re-think > providing the information for PAWS when we actually need PAWS. I guess > that is radical engineering or something, I dunno ... > > allman > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Jun 10 10:09:13 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCDD1A019B for ; Tue, 10 Jun 2014 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0qqUqYtC-af for ; Tue, 10 Jun 2014 10:09:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8167F1A0040 for ; Tue, 10 Jun 2014 10:09:09 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 68B0A27816D for ; Wed, 11 Jun 2014 02:09:07 +0900 (JST) Received: by mail-we0-f181.google.com with SMTP id q59so2576629wes.12 for ; Tue, 10 Jun 2014 10:09:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.157.226 with SMTP id wp2mr19904513wjb.66.1402420145035; Tue, 10 Jun 2014 10:09:05 -0700 (PDT) Received: by 10.194.88.102 with HTTP; Tue, 10 Jun 2014 10:09:04 -0700 (PDT) In-Reply-To: <20140610070403.28813.97293.idtracker@ietfa.amsl.com> References: <20140610070403.28813.97293.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 10:09:04 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e0122f54892230704fb7e6221 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Mru8oDand9TMBvTVu3HJ_ystt68 Subject: [tcpm] Fwd: New Version Notification for draft-nishida-tcpm-apaws-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 10 Jun 2014 17:09:11 -0000 --089e0122f54892230704fb7e6221 Content-Type: text/plain; charset=UTF-8 Hi, I've just submitted a new version of my draft. It discusses reducing the use of TS option in segments. Also, it includes some discussions for feature negotiation using non-SYN segments. Although I don't say late feature negotiation is possible in all cases, but I still believe it will be possible for some features like this by adding some simple logics. I'm not very sure if this is the right approach, but I would like to explore this so that we can find something useful. I really appreciate your feedback. Regards, -- Yoshi ---------- Forwarded message ---------- From: Date: Tue, Jun 10, 2014 at 12:04 AM Subject: New Version Notification for draft-nishida-tcpm-apaws-01.txt To: Yoshifumi Nishida A new version of I-D, draft-nishida-tcpm-apaws-01.txt has been successfully submitted by Yoshifumi Nishida and posted to the IETF repository. Name: draft-nishida-tcpm-apaws Revision: 01 Title: A-PAWS: Alternative Approach for PAWS Document date: 2014-06-10 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-nishida-tcpm-apaws-01.txt Status: https://datatracker.ietf.org/doc/draft-nishida-tcpm-apaws/ Htmlized: http://tools.ietf.org/html/draft-nishida-tcpm-apaws-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-nishida-tcpm-apaws-01 Abstract: This documents describe a technique called A-PAWS which can provide protection against old duplicates segments like PAWS. While PAWS requires TCP to set timestamp options in all segments in a TCP connection, A-PAWS supports the same feature without using timestamps. A-PAWS is designed to be used complementary with PAWS. TCP needs to use PAWS when it is necessary and activates A-PAWS only when it is safe to use. Without impairing the reliability and the robustness of TCP, A-PAWS can provide more option space to other TCP extensions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e0122f54892230704fb7e6221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0
I've just submitted a new version of my = draft. It discusses reducing the use of TS option in segments.
Al= so, it includes some discussions for feature negotiation using non-SYN segm= ents. Although I don't say late feature negotiation is possible in all = cases, but I still believe it will be possible for some features like this = by adding some simple logics.

I'm not very sure if this is the right approach, bu= t I would like to explore this so that we can find something useful.
<= div>I really appreciate your feedback.

Regards,
--
Yoshi

---------- Forwar= ded message ----------
From: <internet-drafts@i= etf.org>
Date: Tue, Jun 10, 2014 at 12:04 AM
Subject: New Version Notification fo= r draft-nishida-tcpm-apaws-01.txt
To: Yoshifumi Nishida <nishida@wide.ad.jp>



A new version of I-D, draft-nishida-tcpm-apaws-01.txt
has been successfully submitted by Yoshifumi Nishida and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-nishida-tcpm-apaws
Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A-PAWS: Alternative Approach for P= AWS
Document date: =C2=A02014-06-10
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http:/= /www.ietf.org/internet-drafts/draft-nishida-tcpm-apaws-01.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.= org/doc/draft-nishida-tcpm-apaws/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-n= ishida-tcpm-apaws-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.= org/rfcdiff?url2=3Ddraft-nishida-tcpm-apaws-01

Abstract:
=C2=A0 =C2=A0This documents describe a technique called A-PAWS which can pr= ovide
=C2=A0 =C2=A0protection against old duplicates segments like PAWS. =C2=A0Wh= ile PAWS
=C2=A0 =C2=A0requires TCP to set timestamp options in all segments in a TCP=
=C2=A0 =C2=A0connection, A-PAWS supports the same feature without using
=C2=A0 =C2=A0timestamps. =C2=A0A-PAWS is designed to be used complementary = with PAWS.
=C2=A0 =C2=A0TCP needs to use PAWS when it is necessary and activates A-PAW= S only
=C2=A0 =C2=A0when it is safe to use. =C2=A0Without impairing the reliabilit= y and the
=C2=A0 =C2=A0robustness of TCP, A-PAWS can provide more option space to oth= er TCP
=C2=A0 =C2=A0extensions.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e0122f54892230704fb7e6221-- From nobody Mon Jun 16 06:35:01 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7F1A002E; Mon, 16 Jun 2014 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXionN-8TEoe; Mon, 16 Jun 2014 06:34:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D78331A0025; Mon, 16 Jun 2014 06:34:56 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140616133456.24823.15486.idtracker@ietfa.amsl.com> Date: Mon, 16 Jun 2014 06:34:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SmQTOllRpJcd0TqsE55MaIULBX8 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: (A Roadmap for Transmission Control Protocol (TCP) Specification Documents) to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 13:34:58 -0000 The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'A Roadmap for Transmission Control Protocol (TCP) Specification Documents' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-06-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. This document obsoletes RFC 4614. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-rfc4614bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jun 18 05:04:42 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3831A01C3 for ; Wed, 18 Jun 2014 05:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w58mkF4oqYw6 for ; Wed, 18 Jun 2014 05:04:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC5A1A0171 for ; Wed, 18 Jun 2014 05:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2274; q=dns/txt; s=iport; t=1403093077; x=1404302677; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=42fyd8pIlLHt2vBKV71uC4fQeRK5qdTFNjHwzuKM75k=; b=VCHQ9kQRzUo0xmkOK8DRGPnhAPCjoU/Ft9JPeD5Whn5Tl5vBsoghEfS1 UA6eIIZEICnXefDI1n1DzvQpaNax6R6B9KWy7XEtFall9MR+tC7+5wgrm brWmQtX012f2I4cx+zZTO80x3Dnf4qF3K3MIhAwk138WJQ9lgXKdexRvL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4IANJ+oVOtJA2K/2dsb2JhbABaDoJ/UlqqFAEBAQEBAQUBkWmHPwGBCxZ1hAMBAQEEAQEBNzQLEAIBCBgeECcLJQIEAQ0FiEINzA0XhWKJEweEQwSaQ4FDkhWDAEKCMA X-IronPort-AV: E=Sophos;i="5.01,499,1400025600"; d="scan'208";a="333763991" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2014 12:04:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5IC4Yjc020267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jun 2014 12:04:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 18 Jun 2014 07:04:34 -0500 From: "Sujeet Nayak A (sua)" To: Joe Touch , "tcpm@ietf.org" Thread-Topic: [tcpm] SHA-2 auth draft on TCP-AO Thread-Index: AQHPf1dlYV3dYpUNN0WvMJGsbW/uaJt3jEKA Date: Wed, 18 Jun 2014 12:04:34 +0000 Message-ID: References: <538E0FCE.8030905@isi.edu> In-Reply-To: <538E0FCE.8030905@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.65.75.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <9EA8A0C223AF2345A31C61010A3C85F1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uaoRoMq31iLSf_69UbULIrqINUo Cc: "Rohit M \(rrohit\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 12:04:39 -0000 Hi Joe, Thanks a lot of your quick and valuable comments: >>This doc should, AFAICT, update RFC 5926 [SUJEET]: Brian would be responding to this one. >>It should also provide motivation for the need for SHA-2 - i.e., some >>of the discussion in the Security Considerations section should be >>mentioned in the abstract and explained in detail in the body (e.g., >>sections 1 or 2). [SUJEET]: Sure, will make the changes as described above. >>Please scrub the use of RFC2119 language - I saw a couple of uses of >>the magic words that were not capitalized but should have been. [SUJEET]: Sure, will look for these and make changes. >>IMO, the doc should also provide advice as to the necessity of these >>algorithms - are they MUST (likely not), SHOULD (probably not either), >>or MAY implement? [SUJEET]: Section 2.2 has the recommendation. Pl. let us know if you were expecting this at any other place, and I can add it. Thanks again for your feedback. Regards, Sujeet & Brian On 03/06/14 11:41 PM, "Joe Touch" wrote: >Hi, Sujeet, > >This doc should, AFAICT, update RFC 5926 > >It should also provide motivation for the need for SHA-2 - i.e., some of >the discussion in the Security Considerations section should be >mentioned in the abstract and explained in detail in the body (e.g., >sections 1 or 2). > >Please scrub the use of RFC2119 language - I saw a couple of uses of the >magic words that were not capitalized but should have been. > >IMO, the doc should also provide advice as to the necessity of these >algorithms - are they MUST (likely not), SHOULD (probably not either), >or MAY implement? > >Joe > >On 6/3/2014 12:21 AM, Sujeet Nayak A (sua) wrote: >> Hi, >> In the last few months, we have been seeing a lot of customer interest >> for SHA-2 based auth on TCP-AO enabled connections. In this regard, we >> (Brian Weis and myself) have posted a draft for the same: >> http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 >> >> Pl. review and let me know your valuable comments. >> >> Regards, >> >> Sujeet Nayak A. >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Wed Jun 18 05:32:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60C1A01CC for ; Wed, 18 Jun 2014 05:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5DvzxVJcwuJ for ; Wed, 18 Jun 2014 05:32:47 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F23C1A0127 for ; Wed, 18 Jun 2014 05:32:45 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:32:43 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 18 Jun 2014 13:32:43 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Wed, 18 Jun 2014 13:32:42 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s5ICWfjN003732; Wed, 18 Jun 2014 13:32:41 +0100 Message-ID: <201406181232.s5ICWfjN003732@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Jun 2014 13:15:58 +0100 To: Mirja KUEHLEWIND , Brian Trammell From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LJ0zUY75rVox7OAEXe6U5KliR10 Cc: tcpm IETF list Subject: [tcpm] ECN fall-back: draft-kuehlewind-tcpm-ecn-fallback-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 12:32:49 -0000 Mirja, Brian, I had an idea to be able to test ECN in the initial window rather than after it: Send the initial window with 4 extra CE pkts at the start with sizes as follows: start size IP-ECN __________________________ A 1 1 CE B 1 2 CE C 1 1466 ECT0 D 1467 1 CE E 1467 1465 ECT0 F 2932 1 CE G 2932 1466 ECT0 etc. This doesn't work for some unfortunate patterns of re-ordering. Aside from that,... * If the CE packets get through, each one pushes forward the cumulative ack boundary, so it should elicit an ACK. * Even if some box drops the CE pkts, the ECT0 packets overlap the CE packets, so there won't be any sequence gaps, so none of the incoming side of the slow-start code has to be changed to ignore losses. * Some receiver implementations delay ACKs during slow start (BSD, Windows), so the CE packets are inserted every second segment so they should be the ones that trigger the ACKs. * If the receiver delays ACKs for 2 full-sized segments (as per RFC5681), packet (F) is the first one that goes beyond that limit. * Only 5 extra bytes of payload are sent. If any of the CE ACKs do not feedback ECE, you know CE is getting re-written. If all the CE ACKs do not cause an ACK, you know CE is getting dropped. I've got some other niggles about the draft, but I'll send them separately. Cheers Bob ________________________________________________________________ Bob Briscoe, BT From nobody Wed Jun 18 06:29:55 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B226C1A0247 for ; Wed, 18 Jun 2014 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUgHQt5hQB9M for ; Wed, 18 Jun 2014 06:29:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 763FD1A01E8 for ; Wed, 18 Jun 2014 06:29:52 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 10A90285B6 for ; Wed, 18 Jun 2014 13:29:52 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id F31A4285AE for ; Wed, 18 Jun 2014 13:29:51 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id E27CE8004B for ; Wed, 18 Jun 2014 13:29:51 +0000 (GMT) Message-ID: <53A1944F.2070003@akamai.com> Date: Wed, 18 Jun 2014 09:29:51 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/VXE8vVeXoEKMnJoKXNNrI8f2ApY Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: brandon.williams@akamai.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 13:29:53 -0000 Hi Sunjeet, The mac lengths of the algorithms specified here increase the option size, don't they? There is a detailed discussion of the option space tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact that all mac lengths would be 96 bits. An I.D. that increases the possible mac lengths should probably revisit that discussion. In particular, the use of a 256 bit mac length would mean that the most commonly used TCP options must be discarded in favor of TCP-AO. On the SYN, you would have just enough room for MSS and that's it. On systems that word align options, there isn't even enough space available for a 128 bit mac length on the SYN, and such systems would also be unable to support both timestamps and SACK. Regards, --Brandon On 06/03/2014 03:21 AM, Sujeet Nayak A (sua) wrote: > Hi, > In the last few months, we have been seeing a lot of customer interest > for SHA-2 based auth on TCP-AO enabled connections. In this regard, we > (Brian Weis and myself) have posted a draft for the same: > http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 > > Pl. review and let me know your valuable comments. > > Regards, > > Sujeet Nayak A. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Jun 18 09:12:46 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B421A02B4 for ; Wed, 18 Jun 2014 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h83-CD_PS79l for ; Wed, 18 Jun 2014 09:12:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8C71A02B5 for ; Wed, 18 Jun 2014 09:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3603; q=dns/txt; s=iport; t=1403107961; x=1404317561; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WGkr5dkX2iI8c48LElomvYKKeb3p5kjhM/sqa4r9Os8=; b=G1w0U2wiUur+yymthATY8TiXJdjKhPaY/bda58/aeYYXKQDhU5kYdeI+ M+NZZGu3s7TSi+LY9KDh9pfhdsU1cZ/nN0VYdCHfCXGL1lPCE17aO9y8E eks0pWp4bqEwUqzQS/ztEtxv9I0r/iHnKVBo/CEPM4+jbB5srz+STGcoz k=; X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="334028401" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jun 2014 16:12:41 +0000 Received: from sjc-vpn6-1782.cisco.com (sjc-vpn6-1782.cisco.com [10.21.126.246]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5IGCcml032500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jun 2014 16:12:40 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Wed, 18 Jun 2014 09:12:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7940AE67-BB4B-4A06-A277-465940C469B3@cisco.com> References: <538E0FCE.8030905@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Gw5by2yfLfOgNqcq4nKzyc_zvsY Cc: "Rohit M \(rrohit\)" , tcpm@ietf.org, "Sujeet Nayak A \(sua\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 16:12:44 -0000 Hi Joe, On Jun 18, 2014, at 5:04 AM, Sujeet Nayak A (sua) wrote: > Hi Joe, > Thanks a lot of your quick and valuable comments: >=20 >>> This doc should, AFAICT, update RFC 5926 We're proposing updates to the IANA registries to add new algorithms, = but it is not our goal to change the requirements language in RFC 5926. = I was recently given advice by IESG members that if an I-D doesn't = propose changes to the base RFC, then the new I-D isn't considered an = "update" to it. There isn't any compelling reason to change the existing algorithm = requirements as both algorithms remain acceptable. We should clarify = that the algorithm recommendations are really only relevant when this = Internet-Draft is implemented. An implementation of TCP-AO still is = required to comply with RFC 5926, but if it also implements this draft = then it would need to pay attention to the algorithm recommendations in = this draft. We'll add some text pointing this out, to make it clear this = does not need to be considered an update to RFC5926. Thanks, Brian > [SUJEET]: Brian would be responding to this one. >=20 >>> It should also provide motivation for the need for SHA-2 - i.e., = some >>> of the discussion in the Security Considerations section should be >>> mentioned in the abstract and explained in detail in the body (e.g., >>> sections 1 or 2). > [SUJEET]: Sure, will make the changes as described above. >=20 >>> Please scrub the use of RFC2119 language - I saw a couple of uses of >>> the magic words that were not capitalized but should have been. > [SUJEET]: Sure, will look for these and make changes. >=20 >>> IMO, the doc should also provide advice as to the necessity of these >>> algorithms - are they MUST (likely not), SHOULD (probably not = either), >>> or MAY implement? > [SUJEET]: Section 2.2 has the recommendation. Pl. let us know if you = were > expecting this at any other place, and I can add it. >=20 >=20 > Thanks again for your feedback. >=20 > Regards, >=20 > Sujeet & Brian >=20 >=20 >=20 >=20 > On 03/06/14 11:41 PM, "Joe Touch" wrote: >=20 >> Hi, Sujeet, >>=20 >> This doc should, AFAICT, update RFC 5926 >>=20 >> It should also provide motivation for the need for SHA-2 - i.e., some = of >> the discussion in the Security Considerations section should be >> mentioned in the abstract and explained in detail in the body (e.g., >> sections 1 or 2). >>=20 >> Please scrub the use of RFC2119 language - I saw a couple of uses of = the >> magic words that were not capitalized but should have been. >>=20 >> IMO, the doc should also provide advice as to the necessity of these >> algorithms - are they MUST (likely not), SHOULD (probably not = either), >> or MAY implement? >>=20 >> Joe >>=20 >> On 6/3/2014 12:21 AM, Sujeet Nayak A (sua) wrote: >>> Hi, >>> In the last few months, we have been seeing a lot of customer = interest >>> for SHA-2 based auth on TCP-AO enabled connections. In this regard, = we >>> (Brian Weis and myself) have posted a draft for the same: >>> http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 >>>=20 >>> Pl. review and let me know your valuable comments. >>>=20 >>> Regards, >>>=20 >>> Sujeet Nayak A. >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jun 18 10:32:18 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5161A00E8 for ; Wed, 18 Jun 2014 10:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOfoSozraG4t for ; Wed, 18 Jun 2014 10:32:15 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207811A0066 for ; Wed, 18 Jun 2014 10:32:14 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5IHVbkd007845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 10:31:37 -0700 (PDT) Message-ID: <53A1CCF9.8080203@isi.edu> Date: Wed, 18 Jun 2014 10:31:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Sujeet Nayak A (sua)" , "tcpm@ietf.org" References: <538E0FCE.8030905@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Us1Eu3rbwvylwGqqDmNMmvAV6vc Cc: "Rohit M \(rrohit\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 17:32:16 -0000 On 6/18/2014 5:04 AM, Sujeet Nayak A (sua) wrote: > Hi Joe, > Thanks a lot of your quick and valuable comments: ... >>> IMO, the doc should also provide advice as to the necessity of these >>> algorithms - are they MUST (likely not), SHOULD (probably not either), >>> or MAY implement? > [SUJEET]: Section 2.2 has the recommendation. Pl. let us know if you were > expecting this at any other place, and I can add it. It should definitely be reiterated in the abstract and intro. Joe From nobody Wed Jun 18 10:32:20 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7281A00E8 for ; Wed, 18 Jun 2014 10:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QaXYcxpaNmz for ; Wed, 18 Jun 2014 10:32:16 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EFC1A0066 for ; Wed, 18 Jun 2014 10:32:16 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5IHUtYw007453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 10:30:58 -0700 (PDT) Message-ID: <53A1CCCF.20804@isi.edu> Date: Wed, 18 Jun 2014 10:30:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Weis References: <538E0FCE.8030905@isi.edu> <7940AE67-BB4B-4A06-A277-465940C469B3@cisco.com> In-Reply-To: <7940AE67-BB4B-4A06-A277-465940C469B3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/IfPug7WZlCZBuVi2Y5GrFa3ASjE Cc: "Rohit M \(rrohit\)" , tcpm@ietf.org, "Sujeet Nayak A \(sua\)" Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 17:32:17 -0000 On 6/18/2014 9:12 AM, Brian Weis wrote: > Hi Joe, > > On Jun 18, 2014, at 5:04 AM, Sujeet Nayak A (sua) wrote: > >> Hi Joe, >> Thanks a lot of your quick and valuable comments: >> >>>> This doc should, AFAICT, update RFC 5926 > > We're proposing updates to the IANA registries to add new > algorithms,but it is not our goal to change the requirements language in RFC 5926. RFC 5926 indicates the security algs for TCP-AO; this doc proposes to augment that list. Yes, that's captured by the IANA registry, but the way RFC 5926 is written appears to indicate that additions to that registry should UPDATE that RFC. If the WG or IESG sees otherwise, that's fine with me. > There isn't any compelling reason to change the existing algorithm > requirements as both algorithms remain acceptable. We should clarify > that the algorithm recommendations are really only relevant when this > Internet-Draft is implemented. An implementation of TCP-AO still is > required to comply with RFC 5926, but if it also implements this draft > then it would need to pay attention to the algorithm recommendations in > this draft. That's how all RFCs work, though. It would certainly be useful to be more clear about the impact of this doc - i.e., that it adds additional optional algorithms, rather than deprecating existing ones. Joe From nobody Wed Jun 18 10:39:05 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7B1A0102 for ; Wed, 18 Jun 2014 10:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXib0AGtKcNu for ; Wed, 18 Jun 2014 10:39:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1131D1A00D5 for ; Wed, 18 Jun 2014 10:39:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5IHbxPL009623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 10:37:59 -0700 (PDT) Message-ID: <53A1CE77.2020603@isi.edu> Date: Wed, 18 Jun 2014 10:37:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: brandon.williams@akamai.com, tcpm@ietf.org References: <53A1944F.2070003@akamai.com> In-Reply-To: <53A1944F.2070003@akamai.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ImRBXHfUqDhzn-oqIUV0lD0ZZ0E Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 17:39:04 -0000 On 6/18/2014 6:29 AM, Brandon Williams wrote: > Hi Sunjeet, > > The mac lengths of the algorithms specified here increase the option > size, don't they? There is a detailed discussion of the option space > tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact > that all mac lengths would be 96 bits. An I.D. that increases the > possible mac lengths should probably revisit that discussion. +1. I ought to be trivial to have this approach truncate the MAC, as other algorithms do, and for the same reason. Joe > In particular, the use of a 256 bit mac length would mean that the most > commonly used TCP options must be discarded in favor of TCP-AO. On the > SYN, you would have just enough room for MSS and that's it. On systems > that word align options, there isn't even enough space available for a > 128 bit mac length on the SYN, and such systems would also be unable to > support both timestamps and SACK. > > Regards, > --Brandon > > On 06/03/2014 03:21 AM, Sujeet Nayak A (sua) wrote: >> Hi, >> In the last few months, we have been seeing a lot of customer interest >> for SHA-2 based auth on TCP-AO enabled connections. In this regard, we >> (Brian Weis and myself) have posted a draft for the same: >> http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 >> >> Pl. review and let me know your valuable comments. >> >> Regards, >> >> Sujeet Nayak A. > From nobody Wed Jun 18 11:46:52 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E8F1A0016 for ; Wed, 18 Jun 2014 11:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Loxux-O2A8UT for ; Wed, 18 Jun 2014 11:46:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344551A0125 for ; Wed, 18 Jun 2014 11:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2053; q=dns/txt; s=iport; t=1403117208; x=1404326808; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RMwZPHQCuV/8HNNwKWQDAhuCKws1pfFDM/QmOfGrF78=; b=LwqAoxg2URuHt/8SBWNxloMJmr8QW/kDk+9j1tJhi1AlaBaj49vAZdIe 88CKfvlyQelwYK+wI+G4o8lasPuvZmARJ/Limy7Qi0U03o/ynxcpALe/+ 4b5NPCGME0QZRJc9Kz9djEF6fyxj9Lr6LhDAXa2lB6bNrsY9WSP/is61a w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwIAAHeoVOtJV2a/2dsb2JhbABXAw6Cf1KqbQEBAQEBAQUBkWmHPwGBCxZ1hAMBAQEDAQEBATc0CxALGC4nMAYBEog6CA3NMReFYogxEQEdIxAHEYMcgRYEij+QBIFDhTeMXoMAYh2BOg X-IronPort-AV: E=Sophos;i="5.01,501,1400025600"; d="scan'208";a="333869013" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2014 18:46:47 +0000 Received: from [10.154.165.238] ([10.154.165.238]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5IIkk3G017674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jun 2014 18:46:47 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: <53A1CE77.2020603@isi.edu> Date: Wed, 18 Jun 2014 11:46:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <099D2327-9556-44B6-A857-0420D095F8B3@cisco.com> References: <53A1944F.2070003@akamai.com> <53A1CE77.2020603@isi.edu> To: Joe Touch , brandon.williams@akamai.com X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pzRL7m1PP_PQFsgG7i_ZVUry2h0 Cc: tcpm@ietf.org Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 18:46:50 -0000 Hi Joe & Brandon, On Jun 18, 2014, at 10:37 AM, Joe Touch wrote: >=20 >=20 > On 6/18/2014 6:29 AM, Brandon Williams wrote: >> Hi Sunjeet, >>=20 >> The mac lengths of the algorithms specified here increase the option >> size, don't they? There is a detailed discussion of the option space >> tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the = fact >> that all mac lengths would be 96 bits. An I.D. that increases the >> possible mac lengths should probably revisit that discussion. >=20 > +1. >=20 > I ought to be trivial to have this approach truncate the MAC, as other = algorithms do, and for the same reason. The proposed methods do already truncate the output down to the minimum = recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC output. Brian=20 >=20 > Joe >=20 >> In particular, the use of a 256 bit mac length would mean that the = most >> commonly used TCP options must be discarded in favor of TCP-AO. On = the >> SYN, you would have just enough room for MSS and that's it. On = systems >> that word align options, there isn't even enough space available for = a >> 128 bit mac length on the SYN, and such systems would also be unable = to >> support both timestamps and SACK. >>=20 >> Regards, >> --Brandon >>=20 >> On 06/03/2014 03:21 AM, Sujeet Nayak A (sua) wrote: >>> Hi, >>> In the last few months, we have been seeing a lot of customer = interest >>> for SHA-2 based auth on TCP-AO enabled connections. In this regard, = we >>> (Brian Weis and myself) have posted a draft for the same: >>> http://tools.ietf.org/html/draft-nayak-tcp-sha2-00 >>>=20 >>> Pl. review and let me know your valuable comments. >>>=20 >>> Regards, >>>=20 >>> Sujeet Nayak A. >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Wed Jun 18 11:54:02 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991CC1A0016 for ; Wed, 18 Jun 2014 11:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHJP9Oz8vyR7 for ; Wed, 18 Jun 2014 11:54:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5826F1A0019 for ; Wed, 18 Jun 2014 11:54:00 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s5IIrlA7009651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 11:53:47 -0700 (PDT) Message-ID: <53A1E03E.4040801@isi.edu> Date: Wed, 18 Jun 2014 11:53:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Weis , brandon.williams@akamai.com References: <53A1944F.2070003@akamai.com> <53A1CE77.2020603@isi.edu> <099D2327-9556-44B6-A857-0420D095F8B3@cisco.com> In-Reply-To: <099D2327-9556-44B6-A857-0420D095F8B3@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/gTcSojLhb_TKnhZmfMLxcm8qpSs Cc: tcpm@ietf.org Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 18 Jun 2014 18:54:01 -0000 On 6/18/2014 11:46 AM, Brian Weis wrote: > Hi Joe & Brandon, > > On Jun 18, 2014, at 10:37 AM, Joe Touch wrote: > >> >> >> On 6/18/2014 6:29 AM, Brandon Williams wrote: >>> Hi Sunjeet, >>> >>> The mac lengths of the algorithms specified here increase the option >>> size, don't they? There is a detailed discussion of the option space >>> tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact >>> that all mac lengths would be 96 bits. An I.D. that increases the >>> possible mac lengths should probably revisit that discussion. >> >> +1. >> >> I ought to be trivial to have this approach truncate the MAC, as other algorithms do, and for the same reason. > > The proposed methods do already truncate the output down to the > minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC > output. IMO if they cannot be truncated to 96 bits for this use then they are not appropriate for TCP-AO. Using a longer HMAC directly in the TCP-AO field would require this doc to UPDATE RFC 5925, as well as addressing the comments already made on the impact of using the additional space, and I don't think that's a good idea. Joe From nobody Fri Jun 20 10:09:28 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FA11B2853 for ; Fri, 20 Jun 2014 10:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7Jb83C5pk_2 for ; Fri, 20 Jun 2014 10:09:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08751A03E1 for ; Fri, 20 Jun 2014 10:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1776; q=dns/txt; s=iport; t=1403284165; x=1404493765; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dOejeHeesUVX+xX31Nj6u+/9jmgRkcz5corj+gW2T+8=; b=Js6+lrVinnhgSKeFtIYozIldofSWMuVSNwKmMiCizUHGI+3zw5LBWQQk o8GYVP/Y8YTF8C331tjurXsDCYWsV7tp2vzMfrmBp9mhArtE3ajTpCZlV 1KAnU3AnEa/RJbS6hodXePZ0j58GgcrEqBc3HlUb54xWEPAaCZTKipDPo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8GAHdqpFOtJV2R/2dsb2JhbABWAw6Cf6tMAQEBAQEBBQGZKgGBChZ1hAMBAQEDAXkQCxguVwYTiDoIymAXhWKIMhEBHSMQBxGDHIEWBIpAkASGeoxggwBiHYE6 X-IronPort-AV: E=Sophos;i="5.01,514,1400025600"; d="scan'208";a="334608083" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 20 Jun 2014 17:09:19 +0000 Received: from [10.154.160.107] ([10.154.160.107]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s5KH9GS4017463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jun 2014 17:09:18 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: <53A1E03E.4040801@isi.edu> Date: Fri, 20 Jun 2014 09:11:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <91B3FBA6-2568-4C50-B12B-EE02D425DB56@cisco.com> References: <53A1944F.2070003@akamai.com> <53A1CE77.2020603@isi.edu> <099D2327-9556-44B6-A857-0420D095F8B3@cisco.com> <53A1E03E.4040801@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UtNr7vdfR4cfkpYuToz45kpc-A8 Cc: tcpm@ietf.org Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jun 2014 17:09:26 -0000 Hi Joe, On Jun 18, 2014, at 11:53 AM, Joe Touch wrote: >=20 >=20 > On 6/18/2014 11:46 AM, Brian Weis wrote: >> Hi Joe & Brandon, >>=20 >> On Jun 18, 2014, at 10:37 AM, Joe Touch wrote: >>=20 >>>=20 >>>=20 >>> On 6/18/2014 6:29 AM, Brandon Williams wrote: >>>> Hi Sunjeet, >>>>=20 >>>> The mac lengths of the algorithms specified here increase the = option >>>> size, don't they? There is a detailed discussion of the option = space >>>> tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the = fact >>>> that all mac lengths would be 96 bits. An I.D. that increases the >>>> possible mac lengths should probably revisit that discussion. >>>=20 >>> +1. >>>=20 >>> I ought to be trivial to have this approach truncate the MAC, as = other algorithms do, and for the same reason. >>=20 >> The proposed methods do already truncate the output down to the >> minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the = MAC >> output. >=20 > IMO if they cannot be truncated to 96 bits for this use then they are = not appropriate for TCP-AO. Using a longer HMAC directly in the TCP-AO = field would require this doc to UPDATE RFC 5925, as well as addressing = the comments already made on the impact of using the additional space, = and I don't think that's a good idea. I understand the concerns of using too much option space. But can you = point me to the requirements language requires a maximum of 96 bits for = the MAC? Although that may have been your intent, I can find no such = requirement in either RFC 5925 or RFC 5926. Brian >=20 > Joe --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Fri Jun 20 11:04:56 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C71B288C for ; Fri, 20 Jun 2014 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17nc5G0mZ9Uy for ; Fri, 20 Jun 2014 11:04:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943351A00DD for ; Fri, 20 Jun 2014 11:04:53 -0700 (PDT) Received: from [10.120.125.195] (guest-wireless-upc-nat-206-117-88-005.usc.edu [206.117.88.5]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s5KI48Zt013084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Jun 2014 11:04:17 -0700 (PDT) Message-ID: <53A47798.5000303@isi.edu> Date: Fri, 20 Jun 2014 11:04:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Weis References: <53A1944F.2070003@akamai.com> <53A1CE77.2020603@isi.edu> <099D2327-9556-44B6-A857-0420D095F8B3@cisco.com> <53A1E03E.4040801@isi.edu> <91B3FBA6-2568-4C50-B12B-EE02D425DB56@cisco.com> In-Reply-To: <91B3FBA6-2568-4C50-B12B-EE02D425DB56@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ZarGn9OQqXc7IwRIkV0rJTZO5aI Cc: tcpm@ietf.org Subject: Re: [tcpm] SHA-2 auth draft on TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 20 Jun 2014 18:04:55 -0000 On 6/20/2014 9:11 AM, Brian Weis wrote: > Hi Joe, > > On Jun 18, 2014, at 11:53 AM, Joe Touch wrote: > >> >> >> On 6/18/2014 11:46 AM, Brian Weis wrote: >>> Hi Joe & Brandon, >>> >>> On Jun 18, 2014, at 10:37 AM, Joe Touch wrote: >>> >>>> >>>> >>>> On 6/18/2014 6:29 AM, Brandon Williams wrote: >>>>> Hi Sunjeet, >>>>> >>>>> The mac lengths of the algorithms specified here increase the option >>>>> size, don't they? There is a detailed discussion of the option space >>>>> tradeoffs for tcp-ao in rfc5925 section 7.6, which is based on the fact >>>>> that all mac lengths would be 96 bits. An I.D. that increases the >>>>> possible mac lengths should probably revisit that discussion. >>>> >>>> +1. >>>> >>>> I ought to be trivial to have this approach truncate the MAC, as other algorithms do, and for the same reason. >>> >>> The proposed methods do already truncate the output down to the >>> minimum recommended by HMAC (RFC 2104), which is 1/2 the size of the MAC >>> output. >> >> IMO if they cannot be truncated to 96 bits for this use then they >> are not appropriate for TCP-AO. Using a longer HMAC directly in the >> TCP-AO field would require this doc to UPDATE RFC 5925, as well as >> addressing the comments already made on the impact of using the >> additional space, and I don't think that's a good idea. > > I understand the concerns of using too much option space. But can > you point me to the requirements language requires a maximum of 96 > bits for the MAC? Although that may have been your intent, I can find > no such requirement in either RFC 5925 or RFC 5926. You're correct; TCP-AO allows MACs of (nearly) any length. We had a discussion on the lengths specified for the specific algorithms in RFC 5926, and came up with 96 bits. The key question here is "why should these algorithms be different"? Joe From nobody Tue Jun 24 08:09:05 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9131B2900 for ; Tue, 24 Jun 2014 04:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuWzfbnw7D2R for ; Tue, 24 Jun 2014 04:03:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3C31B29C4 for ; Tue, 24 Jun 2014 04:03:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJE26946; Tue, 24 Jun 2014 11:03:39 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 12:03:20 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 19:03:12 +0800 From: Qin Wu To: Joe Touch , "Diego R. Lopez" , "tcpm@ietf.org" Thread-Topic: [tcpm] Looking for advice on a draft from the PCE working group Thread-Index: AQHPPSQOPWN7uGul1keGON95aVpVwJrb9joAgALQHnD//+MrAICiEkxw Date: Tue, 24 Jun 2014 11:03:11 +0000 Message-ID: References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> In-Reply-To: <5321D570.60008@isi.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/RqZP4tHdMHAETY0a4oDIKeusApI X-Mailman-Approved-At: Tue, 24 Jun 2014 08:09:00 -0700 Cc: "adrian@olddog.co.uk" , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 24 Jun 2014 11:04:00 -0000 SGksIEpvZToNClNvcnJ5IGZvciBsYXRlIHJlcGx5Lg0KDQpBdXRob3JzIGhhdmUgYmVlbiBkaXNj dXNzaW5nIGEgbWVjaGFuaXNtIHRvIGVuYWJsZSBzZWN1cmUgUENFUCB2aWEgVExTIHdpdGhvdXQg bWFraW5nIGNoYW5nZXMgdG8gdGhlIGN1cnJlbnQgUENFUCBwcm90b2NvbCBvciBzdGF0ZSBtYWNo aW5lLiANCg0KU2luY2UgaGF2aW5nIGEgc2VwYXJhdGUgcG9ydCBoYXMgYmVlbiBkaXNjb3VyYWdl ZCwgd2Ugc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGFwcHJvYWNoIGJhc2VkIG9uIGRpc2NvdmVyeSBt ZWNoYW5pc21zIG9yIGNvbmZpZ3VyYXRpb24gYW5kIGluaXRpYWwgdHJhbnNwb3J0IHNlY3VyaXR5 IGFzc2Vzc21lbnQgYnkgdGhlIHBlZXIuIA0KDQoxKSBBIFBDRSAoZ2l2ZW4gYSBjb21iaW5hdGlv biBvZiBJUCBhZGRyZXNzIGFuZCBwb3J0KSBvbmx5IHN1cHBvcnRzIG9uZSB0eXBlIG9mIGNvbm5l Y3Rpb24sIGVpdGhlciBUTFMgb3Igbm90LiBOb3RlIHRoYXQgYSBkaWZmZXJlbnQgSVAgYWRkcmVz cyBTSE9VTEQgYmUgdXNlZCBmb3Igc3VwcG9ydGluZyBib3RoIGFuZCB3aWxsIGJlIGNvbnNpZGVy ZWQgYXMgZGlmZmVyZW50IFBDRXMuIA0KDQoyKSBUaGUgUENDIE1BWSBkaXNjb3ZlciB3aGV0aGVy IHRoZSBQQ0UgaXMgd2lsbGluZyB0byBjb25uZWN0LCByZXF1aXJlcyBUTFMgb3Igbm90IHZpYSBh bnkgb2YgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc21zLiAgDQoNCjMpIFdoZW4gY29ubmVjdGluZyB0 byBhIFBDRSB0aGF0IGVuZm9yY2VzIFRMUywgdGhlIFBDQyBNVVNUIHN0YXJ0IGEgVExTIGNvbm5l Y3Rpb24gcHJpb3IgdG8gYW55IGV4Y2hhbmdlIG9mIFBDRVAgbWVzc2FnZXMuIEFueSBQQ0VQIG1l c3NhZ2UgcmVjZWl2ZWQgb3V0IG9mIGFuIGFwcHJvcHJpYXRlIFRMUyBjb250ZXh0IHdpbGwgYmUg cmVqZWN0ZWQgYnkgdGhlIFBDRSB3aXRoIGEgUENFcnIgKEVycm9yLVR5cGU9MSwgRXJyb3ItdmFs dWU9MywgVExWIGlkZW50aWZ5aW5nIHRoZSBuZWVkIGZvcg0KVExTKSBtZXNzYWdlLiBbRXhpc3Rp bmcgZXJyb3IgbWVzc2FnZSwgbmV3IFRMVl0NCg0KNCkgSWYgYSBQQ0MgYXR0ZW1wdHMgdG8gc3Rh cnQgYSBUTFMgY29ubmVjdGlvbiB3aXRoIGEgUENFIHdpdGhvdXQgc3VjY2VzcywgaXQgTUFZIGF0 dGVtcHQgYSBmdXJ0aGVyIGNvbm5lY3Rpb24gYXR0ZW1wdCB3aXRob3V0IFRMUyBvbiBhIGRpZmZl cmVudCBJUCBhZGRyZXNzIGlmIGtub3duLCB0aG91Z2ggdGhhdCBjb3VsZCBpbXBseSBhIHNlY3Vy aXR5IGRlZ3JhZGF0aW9uLg0KDQpTZXZlcmFsIGZsb3dzIGJlY29tZSBwb3NzaWJsZSB0aGlzIHdh eSwgYW5kIGRpc2NvdmVyeSBjYW4gYmUgdXNlZCB0byBzaW1wbGlmeSB0aGVtIGJ1dCBpdCBpcyBu b3QgZXNzZW50aWFsIGZvciB0aGVtIHRvIHdvcmsuIExldCdzIGNvbnNpZGVyIHRoZW0NCg0KKiBX aXRoIGRpc2NvdmVyeSAob3IgY29uZmlnKQ0KMS4tIFBDQyBsZWFybiB2aWEgZGlzY292ZXJ5IHRo YXQgdGhlIGRlc2lyZWQgUENFIHJlcXVpcmUgVExTLg0KMi4tIFBDQyBpbml0aWF0ZXMgVENQIGNv bm5lY3Rpb24gYW5kIFRMUyBoYW5kc2hha2UNCjMuLSBQQ0VQIGV4Y2hhbmdlIHdpdGhpbiBUTFMg Y29udGV4dA0KLS0tDQoxLi0gUENDIGxlYXJuIHZpYSBkaXNjb3ZlcnkgdGhhdCB0aGUgZGVzaXJl ZCBQQ0UgZG9lcyBub3QgdXNlIFRMUy4NCjIuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9u DQozLi0gUENFUCBleGNoYW5nZSBvdmVyIFRDUA0KDQoqIFdpdGhvdXQgZGlzY292ZXJ5IC0gUENF IHJlcXVpcmluZyBUTFMNCjEuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uIGFuZCBUTFMg aGFuZHNoYWtlDQoyLi0gUENFUCBleGNoYW5nZSB3aXRoaW4gVExTIGNvbnRleHQNCi0tLQ0KMS4t IFBDQyBpbml0aWF0ZXMgVENQIGNvbm5lY3Rpb24gYW5kIGF0dGVtcHRzIGEgUENFUCBPUEVOIG1l c3NhZ2UNCjIuLSBQQ0UgcmVqZWN0cyB0aGUgbWVzc2FnZSB3aXRoIGEgUENFcnIgbWVzc2FnZSAo RXJyb3ItVHlwZT0xLCBFcnJvci12YWx1ZT0zLCBUTFYgaWRlbnRpZnlpbmcgdGhlIG5lZWQgZm9y IFRMUyhvcHRpb25hbGx5KSkNCjMuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uIGFuZCBU TFMgaGFuZHNoYWtlDQo0Li0gUENFUCBleGNoYW5nZSB3aXRoaW4gVExTIGNvbnRleHQNCg0KKiBX aXRob3V0IGRpc2NvdmVyeSAtIFBDRSBub3QgcmVxdWlyaW5nIFRMUw0KMS4tIFBDQyBpbml0aWF0 ZXMgVENQIGNvbm5lY3Rpb24NCjIuLSBQQ0VQIGV4Y2hhbmdlIG92ZXIgVENQDQotLS0NCjEuLSBQ Q0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uIGFuZCBUTFMgaGFuZHNoYWtlDQoyLi0gTm8gVExT IGNvbnRleHQgZXN0YWJsaXNoZWQgd2l0aCBQQ0Ugb3IgZXJyb3IgbWVzc2FnZSByZWNlaXZlZA0K KG9wdGlvbmFsbHkpDQozLi0gUENDIGluaXRpYXRlcyBUQ1AgY29ubmVjdGlvbg0KNC4tIFBDRVAg ZXhjaGFuZ2Ugb3ZlciBUQ1ANCg0KV2hhdCBkbyB5b3UgdGhpbmsgb2YgdGhpcyBhcHByb2FjaD8g DQoNCkFsc28gd2UgbGlrZSB0byBwb2ludCBhIHJlbGF0ZWQgZGlzY3Vzc2lvbiBoYXBwZW5lZCBv biBVVEEgbWFpbGluZyBsaXN0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3V0YS9jdXJyZW50L21zZzAwNDIzLmh0bWwNCg0KUmVnYXJkcywNCkF1dGhvcnMNCi0tLS0t6YKu 5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVk dV0gDQrlj5HpgIHml7bpl7Q6IDIwMTTlubQz5pyIMTPml6UgMjM6NTgNCuaUtuS7tuS6ujogUWlu IFd1OyBEaWVnbyBSLiBMb3BlejsgdGNwbUBpZXRmLm9yZw0K5oqE6YCBOiBkcmFmdC1pZXRmLXBj ZS1wY2Vwc0B0b29scy5pZXRmLm9yZw0K5Li76aKYOiBSZTogW3RjcG1dIExvb2tpbmcgZm9yIGFk dmljZSBvbiBhIGRyYWZ0IGZyb20gdGhlIFBDRSB3b3JraW5nIGdyb3VwDQoNCkhpLCBRaW4sDQoN Ck9uIDMvMTMvMjAxNCAzOjM1IEFNLCBRaW4gV3Ugd3JvdGU6DQo+IEhpLCBKb2U6DQo+DQo+IEl0 IGlzIHN0aWxsIG5vdCBjbGVhciB0byBtZSB3aGVuIHdlIGNob29zZSB0aGUgc2FtZSBwb3J0IGFu ZCB3aGVuIHdlIA0KPiBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0IGlmIHdlIGFwcGx5IFRMUyB0 byBkaWZmZXJlbnQgcHJvdG9jb2xzLA0KDQpJdCdzIHNpbXBsZSB0byBkZXRlcm1pbmU6DQoNCgkt IGlmIHlvdSBkZXNpZ25lZCB5b3VyIHNlcnZpY2UgYmVmb3JlIFNUQVJUVExTLCB0aGVuIHlvdSBu ZWVkZWQNCglhIHNlcGFyYXRlIHBvcnQNCg0KCS0gaWYgeW91IGFyZSBkZXNpZ25pbmcgeW91ciBw b3J0IG5vdywgeW91IGRvbid0DQoNCj4gVGFrZSBTTVRQLCBQT1AzLElNQVAgYXMgZXhhbXBsZXM6 DQouLi4NCj4gSXQgbG9va3MgdG8gbWUgd2hlbiB3ZSBhcHBseSBTU0wgdG8gU01UUCxQT1AzLElN QVAsIHRoZW4gU01UUCwgUE9QMyANCj4gYW5kIElNQVAgd2l0aCBTU0wgc3VwcG9ydChpLmUuLFNN VFBTLFBPUDNTLElNQVBTKQ0KPg0KPiBXaWxsIHVzdWFsbHkgY2hvb3NlIHRoZSBkaWZmZXJlbnQg cG9ydHMuDQo+DQo+IFRoZSBzYW1lIHJ1bGUgYWJvdmUgaXMgYWxzbyBhcHBsaWVkIHRvIEhUVFAg d2hlbiB3ZSBhcHBseSBTU0wgdG8gDQo+IEhUVFAoaS5lLiwgSFRUUFMpLg0KDQpBbGwgb2YgdGhl IGFib3ZlIGFyZSBnb29kIGV4YW1wbGVzIG9mIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBydWxlLg0K DQpOb3RlIHRoYXQgd2UgaGF2ZSBvdGhlciBhc3NpZ25tZW50cyB0aGF0IG5vdyB3b3VsZCBiZSBk ZWNsaW5lZCwgYmVjYXVzZSB3ZSd2ZSBsZWFybmVkIHRvIGRvIGJldHRlci4gRS5nLiwgdGhlcmUg d291bGQgbm90IGJlIGEgUE9QMiBvciBQT1AzIGJlY2F1c2Ugd2Ugd291bGQgZXhwZWN0IFBPUCB0 byBpbmRpY2F0ZSB0aGUgcHJvdG9jb2wgdmVyc2lvbiBpbi1iYW5kLiBXZSBhbHNvIG5vIGxvbmdl ciBhc3NpZ24gbXVsdGlwbGUgbmFtZXMgZm9yIHRoZSBzYW1lIHNlcnZpY2UsIGFzIHdhcyBkb25l IGZvciBodHRwL3d3dywgbm9yIGRvIHdlIG5vdyBhc3NpZ24gbXVsdGlwbGUgcG9ydHMgZm9yIHRo ZSBzYW1lIHNlcnZpY2UgKDgwLCA4MDgwKSwgbm9yIGRvIHdlIG5vdyBhc3NpZ24gcG9ydHMgZm9y IGRldmVsb3BtZW50IHB1cnBvc2VzICAoaHR0cC1kZXYpLg0KDQpXZSd2ZSBsZWFybmVkIHRvIGRv IGJldHRlci4NCg0KSm9lDQoNCg== From nobody Tue Jun 24 23:24:32 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D481B2AE9 for ; Tue, 24 Jun 2014 23:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.472 X-Spam-Level: *** X-Spam-Status: No, score=3.472 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CE1ZY1bwvxv for ; Tue, 24 Jun 2014 23:24:30 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA241B2AE0 for ; Tue, 24 Jun 2014 23:24:29 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E97122780C3 for ; Wed, 25 Jun 2014 15:24:27 +0900 (JST) Received: by mail-la0-f51.google.com with SMTP id mc6so392547lab.38 for ; Tue, 24 Jun 2014 23:24:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.63.65 with SMTP id e1mr34068lbs.81.1403677465311; Tue, 24 Jun 2014 23:24:25 -0700 (PDT) Received: by 10.114.95.101 with HTTP; Tue, 24 Jun 2014 23:24:25 -0700 (PDT) Date: Tue, 24 Jun 2014 23:24:25 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/k6L_-yJm3prf7HF2Kc-CrxSvAq0 Subject: [tcpm] TCPM agenda requests for Tronto meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 25 Jun 2014 06:24:31 -0000 Hi, The schedule has not been fixed yet, but we currently have the following slot at the Tronto meeting MONDAY, July 21, Morning Session I 0900-1130 If you're planning to present something at the meeting, please provide us the following info. 1: Presenter's name 2: Title/ Name of draft 3: Length of the presentation Thanks, -- tcpm co-chairs From nobody Fri Jun 27 05:41:27 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A31B2B44 for ; Fri, 27 Jun 2014 05:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sa5UUijIh9d for ; Fri, 27 Jun 2014 05:41:22 -0700 (PDT) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A93311B2AB5 for ; Fri, 27 Jun 2014 05:41:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 838E82C40F3; Fri, 27 Jun 2014 05:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y4nXaOmHJ3yN; Fri, 27 Jun 2014 05:41:22 -0700 (PDT) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 84AF32C40F5; Fri, 27 Jun 2014 05:41:21 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 22D872FC6585; Fri, 27 Jun 2014 08:41:21 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7D65F942B70; Fri, 27 Jun 2014 08:41:26 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Nothingman X-URL-0: http://www.icir.org/mallman-files/Document7677.docx X-URL-1: http://www.icir.org/mallman-files/Document79886.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma26230-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 27 Jun 2014 08:41:26 -0400 Sender: mallman@icir.org Message-Id: <20140627124126.7D65F942B70@lawyers.icir.org> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LphJI5p_Jhorx5C7V0XjNLwvSt8 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 27 Jun 2014 12:41:25 -0000 ----------ma26230-1 Content-Type: text/plain Content-Disposition: inline [catching up after a long, pretty-much-offline vacation] Just a quick note .. > Or we can just (dynamically) start tagging TS on retransmission to > support Eifel. The pushback against this has always been that if you are retransmitting a full packet and only add a TS on the retransmission, now you have to retransmit two packets to convey all the lost data. allman ----------ma26230-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlOtZnYACgkQWyrrWs4yIs7aZwCdH9smb6QHDqP/VSem9MFCJTda 4hQAniivD3poLVqNZCbZS5g8v0v9RUva =F3u+ -----END PGP SIGNATURE----- ----------ma26230-1-- From nobody Fri Jun 27 11:04:39 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB281A041C for ; Fri, 27 Jun 2014 11:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkXPpV-M3Gom for ; Fri, 27 Jun 2014 11:04:36 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4539F1A03B4 for ; Fri, 27 Jun 2014 11:04:36 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id h18so2243471igc.1 for ; Fri, 27 Jun 2014 11:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xCwDYGAfhkXoJ0PvmuQ7nrYLD8BkST24Ho/fgRkYBFc=; b=CkT8niSH9CcFWwHJvuZYi+EobLKSX5DvbFIygryTECxNG02Pp1KlcFyqj+AyuNEWdx Sn43Ajzp7pueQqJgSJzDN7WR1pKEdesMJc34rDuezEkpy0XwMW6c5aTrKJI0bEe+QIw6 EZVn5xVcQtq5XrIPzWGN70vOdu83+awcr+phayOsG5D3Mbd3ac48IZxtrpBtZW8foxln HOG7jGo10Bl8tpl67/XNITd763T1VkOBS4j+6ohAK2pM1E/nortudJtcJ58/QTBV9P7u yfsjR6jYOlK2Rpg5wbdfmzNTTeVLeCQ++Z6xkU7anrFuUv/lMsrkYZQT5uDdvi2BQmus 8/GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xCwDYGAfhkXoJ0PvmuQ7nrYLD8BkST24Ho/fgRkYBFc=; b=DzsiWnw5GclItFStiImWpHDtyvALD4fQNxbVCsudzKsIHbfTmc+x3gx7mem3R0T1jZ oN9Gz4iz8Dqj0V55xFVuCevZ/R5+rh1rs34+vw0SfOymddc7xKhtCpmZJ/n/rUcQMdBs rbavxtvOrpsNLkUuYEY69CSrB6CGQUHW5oxNoJSOaSdbnzvkX2VNhDBIMvKCsLy7LP3v haL7LVA/ZJKMIiGwma73r5bYIFSIMWwVtZrren43JVAU0SaOq9GGyoitimsiSkU1jYvf vpJ077olWrdSF0kFbZwdXU7O3XQHlgUjjOUDJfxFyPx4RQ4nOBTmVyV08jt/Huytu5Nq bd6Q== X-Gm-Message-State: ALoCoQmg4i7UBAoWggZi23U2Vo0FQBygsZR1agzkxn6OPYfmGHJhOD7D7GeQNiFC+mEVeyU5ePid X-Received: by 10.42.99.10 with SMTP id u10mr22787923icn.9.1403892274650; Fri, 27 Jun 2014 11:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.223.163 with HTTP; Fri, 27 Jun 2014 11:03:54 -0700 (PDT) In-Reply-To: <20140627124126.7D65F942B70@lawyers.icir.org> References: <20140627124126.7D65F942B70@lawyers.icir.org> From: Yuchung Cheng Date: Fri, 27 Jun 2014 11:03:54 -0700 Message-ID: To: "mallman@icir.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SgaFSAYeM-3hQro2aKlqWQFo_K4 Cc: "tcpm@ietf.org" , Joe Touch Subject: Re: [tcpm] timestamp options (was Re: New Version Notification for draft-touch-tcpm-tcp-edo-01.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 27 Jun 2014 18:04:37 -0000 On Fri, Jun 27, 2014 at 5:41 AM, Mark Allman wrote: > > > [catching up after a long, pretty-much-offline vacation] > > Just a quick note .. > > > Or we can just (dynamically) start tagging TS on retransmission to > > support Eifel. > > The pushback against this has always been that if you are retransmitting > a full packet and only add a TS on the retransmission, now you have to > retransmit two packets to convey all the lost data. ah that's right. so this won't work (well) :_( > > > allman > > > From nobody Fri Jun 27 21:36:04 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827941A0291 for ; Fri, 27 Jun 2014 21:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QL9fkqIvhR-N for ; Fri, 27 Jun 2014 21:35:59 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0461D1A028F for ; Fri, 27 Jun 2014 21:35:58 -0700 (PDT) Received: from [128.9.176.210] (c2-vpn01.isi.edu [128.9.176.210]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5S4ZZAS013075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2014 21:35:35 -0700 (PDT) Message-ID: <53AE4617.2000800@isi.edu> Date: Fri, 27 Jun 2014 21:35:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Qin Wu , "Diego R. Lopez" , "tcpm@ietf.org" References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/FNU4dth6T7_HfdbSvhX1Hpzz3_k Cc: "adrian@olddog.co.uk" , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 04:36:01 -0000 Hi, On 6/24/2014 4:03 AM, Qin Wu wrote: > Hi, Joe: > Sorry for late reply. > > Authors have been discussing a mechanism to enable secure PCEP via > TLS without making changes to the current PCEP protocol or state > machine. > > Since having a separate port has been discouraged, we suggest the ? following approach based on discovery mechanisms or configuration and > initial transport security assessment by the peer. > > 1) A PCE (given a combination of IP address and port) only supports > one type of connection, either TLS or not. I'm not sure why that needs to be the case, given STARTTLS. > Note that a different IP > address SHOULD be used for supporting both and will be considered as > different PCEs. I don't quite understand this. Different IP addresses should be different PCEs anyway. If you want to support both encrypted and non-encrypted, why not use the existing TLS mechanism for that - STARTTLS? > 2) The PCC MAY discover whether the PCE is willing to connect, > requires TLS or not via any of the discovery mechanisms. That seems reasonable, but doesn't answer why a PCE needs to support only one type of connection. The discovery could indicate "either" and let the client decide, e.g., if both are supported (again, via STARTTLS) > 3) When connecting to a PCE that enforces TLS, the PCC MUST start a > TLS connection prior to any exchange of PCEP messages. Isn't that already what happens if TLS-only is used? > Any PCEP message > received out of an appropriate TLS context will be rejected by the PCE > with a PCErr (Error-Type=1, Error-value=3, TLV identifying the need for > TLS) message. [Existing error message, new TLV] If non-TLS connections are rejected, then there shouldn't be any such messages seen AFAICT. I.e., that would be a TLS port that is configured to not support STARTTLS. > 4) If a PCC attempts to start a TLS connection with a PCE without > success, it MAY attempt a further connection attempt without TLS on a > different IP address if known, though that could imply a security > degradation. I don't understand why a different address would be considered degraded access to the same PCE. That seems like a different PCE, as noted above. If you want to support degraded (non-secure) access, why not just support STARTTLS? > Several flows become possible this way, and discovery can be used to simplify them but it is not essential for them to work. Let's consider them > > * With discovery (or config) > 1.- PCC learn via discovery that the desired PCE require TLS. > 2.- PCC initiates TCP connection and TLS handshake > 3.- PCEP exchange within TLS context Makes sense. > --- > 1.- PCC learn via discovery that the desired PCE does not use TLS. > 2.- PCC initiates TCP connection > 3.- PCEP exchange over TCP Makes sense. > * Without discovery - PCE requiring TLS > 1.- PCC initiates TCP connection and TLS handshake Wouldn't the TLS handshake here fail? Why would the rest of the exchange occur? > 2.- PCEP exchange within TLS context > --- > 1.- PCC initiates TCP connection and attempts a PCEP OPEN message > 2.- PCE rejects the message with a PCErr message (Error-Type=1, Error-value=3, TLV identifying the need for TLS(optionally)) > 3.- PCC initiates TCP connection and TLS handshake > 4.- PCEP exchange within TLS context (see issue above) > * Without discovery - PCE not requiring TLS > 1.- PCC initiates TCP connection > 2.- PCEP exchange over TCP > --- > 1.- PCC initiates TCP connection and TLS handshake Why is this even attempted? > 2.- No TLS context established with PCE or error message received > (optionally) > 3.- PCC initiates TCP connection > 4.- PCEP exchange over TCP > > What do you think of this approach? > > Also we like to point a related discussion happened on UTA mailing list: > http://www.ietf.org/mail-archive/web/uta/current/msg00423.html Those points were raised on the TSVWG list too, but fail to address the key issue - insecure ports are insecure. Regardless of how many ports we allocate, it's no longer clear we should continue to deploy new insecure services on the Internet. Joe > > Regards, > Authors > -----邮件原件----- > 发件人: Joe Touch [mailto:touch@isi.edu] > 发送时间: 2014年3月13日 23:58 > 收件人: Qin Wu; Diego R. Lopez; tcpm@ietf.org > 抄送: draft-ietf-pce-pceps@tools.ietf.org > 主题: Re: [tcpm] Looking for advice on a draft from the PCE working group > > Hi, Qin, > > On 3/13/2014 3:35 AM, Qin Wu wrote: >> Hi, Joe: >> >> It is still not clear to me when we choose the same port and when we >> choose the different port if we apply TLS to different protocols, > > It's simple to determine: > > - if you designed your service before STARTTLS, then you needed > a separate port > > - if you are designing your port now, you don't > >> Take SMTP, POP3,IMAP as examples: > ... >> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3 >> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS) >> >> Will usually choose the different ports. >> >> The same rule above is also applied to HTTP when we apply SSL to >> HTTP(i.e., HTTPS). > > All of the above are good examples of the first part of the rule. > > Note that we have other assignments that now would be declined, because we've learned to do better. E.g., there would not be a POP2 or POP3 because we would expect POP to indicate the protocol version in-band. We also no longer assign multiple names for the same service, as was done for http/www, nor do we now assign multiple ports for the same service (80, 8080), nor do we now assign ports for development purposes (http-dev). > > We've learned to do better. > > Joe > From nobody Mon Jun 30 03:01:53 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89961A01DD for ; Mon, 30 Jun 2014 03:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51S3Vdk-R0a1 for ; Mon, 30 Jun 2014 03:01:48 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id B04C71A01D2 for ; Mon, 30 Jun 2014 03:01:46 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N7Z00EIX7UWBK@tid.hi.inet> for tcpm@ietf.org; Mon, 30 Jun 2014 12:01:44 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id D3.BA.22923.31051B35; Mon, 30 Jun 2014 13:54:59 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N7Z00EIQ7UVBK@tid.hi.inet> for tcpm@ietf.org; Mon, 30 Jun 2014 12:01:44 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.134]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Mon, 30 Jun 2014 12:01:43 +0200 Date: Mon, 30 Jun 2014 10:01:59 +0000 From: "Diego R. Lopez" In-reply-to: <53AE4617.2000800@isi.edu> X-Originating-IP: [10.95.64.115] To: Joe Touch Message-id: <2E9995E5-16AC-4E8E-BF48-D9C3566CE8FE@tid.es> Content-id: <0A09D001FE99684FB1B6E755300E7249@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [tcpm] Looking for advice on a draft from the PCE working group Thread-index: AQHPPSQOPWN7uGul1keGON95aVpVwJrb9joAgALQHnD//+MrAICiEkxwgAW9MICAA3/GgA== X-AuditID: 0a5f4e69-f79d66d00000598b-34-53b150134a1e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsXCFe9nqCscsDHYoPmzicW2k/OZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcWHiE+aCS14Vp2fWNzDe8ehi5OSQEDCR+HToBBOELSZx4d56 ti5GLg4hge2MEg9n3mMBSQgJ/GCUePROFyIxk1Fi4/59YAkWAVWJFbf+s4PYbED2o+bfYLaw gI/E5Ul9bCA2p4C6xPx/LcwQGxQk/px7DNYrIiAr8eDPG3aQocwC+xglXj1YDtbAK2Ap8WtJ P9ggZgEzic7ZD1kh4oISPyaDXMQBFFeXmDIlF6JEXKK59SYLhK0oMW1RAyOIzQg0/938+awQ u3wlju/9ygZhR0h8ObqbEeIeAYkle85D3SYq8fLxP1aIJ5cxSVzuPsM2gVFiFpIzZiE5YxbC GbOQnDELyRkLGFlXMYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKERF3mDsblO1UOMQpwMCrx 8Hoc2hAsxJpYVlyZe4hRgoNZSYT3ucrGYCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8zO+KAoQE 0hNLUrNTUwtSi2CyTBycUg2MATHWm+wPWzNX/pzAKhG1U37n9B83vuhwLqg7GnbdJCewfYa/ DP+nzG0rfq3UXqykOP/uoph/p7gqDH3nWnqrsEcFRN2PaLrw08CucsVymb8v+w7wFHqYSvws /HUmcv+isK17dwVOZlmi+aLqgt3PH490xMpqGdbe7rf8eOq1FEtm1qrrPHullFiKMxINtZiL ihMBz9v4XLYCAAA= References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> <53AE4617.2000800@isi.edu> Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GIr00NTBWXBxBYbcPbdC3Hd95Z8 Cc: "adrian@olddog.co.uk" , "tcpm@ietf.org" , Qin Wu , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jun 2014 10:01:50 -0000 SGksDQoNCldlIGFyZSBub3QgcHJvcG9zaW5nIHRvIHVzZSBTVEFSVFRMUyBiZWNhdXNlLCBhZnRl ciBkaXNjdXNzaW5nIHRoZSBkaWZmZXJlbnQgb3B0aW9ucyBmb3IgZG9pbmcgc28gaW4gUENFUCwg d2UgYmVsaWV2ZSBpbmNsdWRpbmcgaXQgd291bGQgdHJhbnNsYXRlIGludG8gYSBjaGFuZ2Ugb2Yg dGhlIFBDRVAgcHJvdG9jb2w6DQooMSkgYWdhaW5zdCB0aGUgb3JpZ2luYWwgY29tbWl0bWVudCBv ZiBub3QgY2hhbmdpbmcgaXQNCigyKSB3b3VsZCB0cmFuc2xhdGUgaW50byBhIG11Y2ggbG9uZ2Vy IGFkb3B0aW9uIGJ5IGltcGxlbWVudGF0aW9ucw0KDQpCZSBnb29kZSwNCg0KT24gMjggSnVuIDIw MTQsIGF0IDA2OjM1ICwgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PiB3cm90ZToNCg0KPiBIaSwN Cj4NCj4gT24gNi8yNC8yMDE0IDQ6MDMgQU0sIFFpbiBXdSB3cm90ZToNCj4+IEhpLCBKb2U6DQo+ PiBTb3JyeSBmb3IgbGF0ZSByZXBseS4NCj4+DQo+PiBBdXRob3JzIGhhdmUgYmVlbiBkaXNjdXNz aW5nIGEgbWVjaGFuaXNtIHRvIGVuYWJsZSBzZWN1cmUgUENFUCB2aWENCj4+IFRMUyB3aXRob3V0 IG1ha2luZyBjaGFuZ2VzIHRvIHRoZSBjdXJyZW50IFBDRVAgcHJvdG9jb2wgb3Igc3RhdGUNCj4+ IG1hY2hpbmUuDQo+Pg0KPj4gU2luY2UgaGF2aW5nIGEgc2VwYXJhdGUgcG9ydCBoYXMgYmVlbiBk aXNjb3VyYWdlZCwgd2Ugc3VnZ2VzdCB0aGUNCj4gPyBmb2xsb3dpbmcgYXBwcm9hY2ggYmFzZWQg b24gZGlzY292ZXJ5IG1lY2hhbmlzbXMgb3IgY29uZmlndXJhdGlvbiBhbmQNCj4+IGluaXRpYWwg dHJhbnNwb3J0IHNlY3VyaXR5IGFzc2Vzc21lbnQgYnkgdGhlIHBlZXIuDQo+Pg0KPj4gMSkgQSBQ Q0UgKGdpdmVuIGEgY29tYmluYXRpb24gb2YgSVAgYWRkcmVzcyBhbmQgcG9ydCkgb25seSBzdXBw b3J0cw0KPj4gb25lIHR5cGUgb2YgY29ubmVjdGlvbiwgZWl0aGVyIFRMUyBvciBub3QuDQo+DQo+ IEknbSBub3Qgc3VyZSB3aHkgdGhhdCBuZWVkcyB0byBiZSB0aGUgY2FzZSwgZ2l2ZW4gU1RBUlRU TFMuDQo+DQo+PiBOb3RlIHRoYXQgYSBkaWZmZXJlbnQgSVANCj4+IGFkZHJlc3MgU0hPVUxEIGJl IHVzZWQgZm9yIHN1cHBvcnRpbmcgYm90aCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGFzDQo+PiBk aWZmZXJlbnQgUENFcy4NCj4NCj4gSSBkb24ndCBxdWl0ZSB1bmRlcnN0YW5kIHRoaXMuIERpZmZl cmVudCBJUCBhZGRyZXNzZXMgc2hvdWxkIGJlIGRpZmZlcmVudCBQQ0VzIGFueXdheS4gSWYgeW91 IHdhbnQgdG8gc3VwcG9ydCBib3RoIGVuY3J5cHRlZCBhbmQgbm9uLWVuY3J5cHRlZCwgd2h5IG5v dCB1c2UgdGhlIGV4aXN0aW5nIFRMUyBtZWNoYW5pc20gZm9yIHRoYXQgLSBTVEFSVFRMUz8NCj4N Cj4+IDIpIFRoZSBQQ0MgTUFZIGRpc2NvdmVyIHdoZXRoZXIgdGhlIFBDRSBpcyB3aWxsaW5nIHRv IGNvbm5lY3QsDQo+PiByZXF1aXJlcyBUTFMgb3Igbm90IHZpYSBhbnkgb2YgdGhlIGRpc2NvdmVy eSBtZWNoYW5pc21zLg0KPg0KPiBUaGF0IHNlZW1zIHJlYXNvbmFibGUsIGJ1dCBkb2Vzbid0IGFu c3dlciB3aHkgYSBQQ0UgbmVlZHMgdG8gc3VwcG9ydCBvbmx5IG9uZSB0eXBlIG9mIGNvbm5lY3Rp b24uIFRoZSBkaXNjb3ZlcnkgY291bGQgaW5kaWNhdGUgImVpdGhlciIgYW5kIGxldCB0aGUgY2xp ZW50IGRlY2lkZSwgZS5nLiwgaWYgYm90aCBhcmUgc3VwcG9ydGVkIChhZ2FpbiwgdmlhIFNUQVJU VExTKQ0KPg0KPj4gMykgV2hlbiBjb25uZWN0aW5nIHRvIGEgUENFIHRoYXQgZW5mb3JjZXMgVExT LCB0aGUgUENDIE1VU1Qgc3RhcnQgYQ0KPj4gVExTIGNvbm5lY3Rpb24gcHJpb3IgdG8gYW55IGV4 Y2hhbmdlIG9mIFBDRVAgbWVzc2FnZXMuDQo+DQo+IElzbid0IHRoYXQgYWxyZWFkeSB3aGF0IGhh cHBlbnMgaWYgVExTLW9ubHkgaXMgdXNlZD8NCj4NCj4+IEFueSBQQ0VQIG1lc3NhZ2UNCj4+IHJl Y2VpdmVkIG91dCBvZiBhbiBhcHByb3ByaWF0ZSBUTFMgY29udGV4dCB3aWxsIGJlIHJlamVjdGVk IGJ5IHRoZSBQQ0UNCj4+IHdpdGggYSBQQ0VyciAoRXJyb3ItVHlwZT0xLCBFcnJvci12YWx1ZT0z LCBUTFYgaWRlbnRpZnlpbmcgdGhlIG5lZWQgZm9yDQo+PiBUTFMpIG1lc3NhZ2UuIFtFeGlzdGlu ZyBlcnJvciBtZXNzYWdlLCBuZXcgVExWXQ0KPg0KPiBJZiBub24tVExTIGNvbm5lY3Rpb25zIGFy ZSByZWplY3RlZCwgdGhlbiB0aGVyZSBzaG91bGRuJ3QgYmUgYW55IHN1Y2ggbWVzc2FnZXMgc2Vl biBBRkFJQ1QuIEkuZS4sIHRoYXQgd291bGQgYmUgYSBUTFMgcG9ydCB0aGF0IGlzIGNvbmZpZ3Vy ZWQgdG8gbm90IHN1cHBvcnQgU1RBUlRUTFMuDQo+DQo+PiA0KSBJZiBhIFBDQyBhdHRlbXB0cyB0 byBzdGFydCBhIFRMUyBjb25uZWN0aW9uIHdpdGggYSBQQ0Ugd2l0aG91dA0KPj4gc3VjY2Vzcywg aXQgTUFZIGF0dGVtcHQgYSBmdXJ0aGVyIGNvbm5lY3Rpb24gYXR0ZW1wdCB3aXRob3V0IFRMUyBv biBhDQo+PiBkaWZmZXJlbnQgSVAgYWRkcmVzcyBpZiBrbm93biwgdGhvdWdoIHRoYXQgY291bGQg aW1wbHkgYSBzZWN1cml0eQ0KPj4gZGVncmFkYXRpb24uDQo+DQo+IEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aHkgYSBkaWZmZXJlbnQgYWRkcmVzcyB3b3VsZCBiZSBjb25zaWRlcmVkIGRlZ3JhZGVkIGFj Y2VzcyB0byB0aGUgc2FtZSBQQ0UuIFRoYXQgc2VlbXMgbGlrZSBhIGRpZmZlcmVudCBQQ0UsIGFz IG5vdGVkIGFib3ZlLg0KPg0KPiBJZiB5b3Ugd2FudCB0byBzdXBwb3J0IGRlZ3JhZGVkIChub24t c2VjdXJlKSBhY2Nlc3MsIHdoeSBub3QganVzdCBzdXBwb3J0IFNUQVJUVExTPw0KPg0KPj4gU2V2 ZXJhbCBmbG93cyBiZWNvbWUgcG9zc2libGUgdGhpcyB3YXksIGFuZCBkaXNjb3ZlcnkgY2FuIGJl IHVzZWQgdG8NCj4gc2ltcGxpZnkgdGhlbSBidXQgaXQgaXMgbm90IGVzc2VudGlhbCBmb3IgdGhl bSB0byB3b3JrLiBMZXQncyBjb25zaWRlciB0aGVtDQo+Pg0KPj4gKiBXaXRoIGRpc2NvdmVyeSAo b3IgY29uZmlnKQ0KPj4gMS4tIFBDQyBsZWFybiB2aWEgZGlzY292ZXJ5IHRoYXQgdGhlIGRlc2ly ZWQgUENFIHJlcXVpcmUgVExTLg0KPj4gMi4tIFBDQyBpbml0aWF0ZXMgVENQIGNvbm5lY3Rpb24g YW5kIFRMUyBoYW5kc2hha2UNCj4+IDMuLSBQQ0VQIGV4Y2hhbmdlIHdpdGhpbiBUTFMgY29udGV4 dA0KPg0KPiBNYWtlcyBzZW5zZS4NCj4NCj4+IC0tLQ0KPj4gMS4tIFBDQyBsZWFybiB2aWEgZGlz Y292ZXJ5IHRoYXQgdGhlIGRlc2lyZWQgUENFIGRvZXMgbm90IHVzZSBUTFMuDQo+PiAyLi0gUEND IGluaXRpYXRlcyBUQ1AgY29ubmVjdGlvbg0KPj4gMy4tIFBDRVAgZXhjaGFuZ2Ugb3ZlciBUQ1AN Cj4NCj4gTWFrZXMgc2Vuc2UuDQo+DQo+PiAqIFdpdGhvdXQgZGlzY292ZXJ5IC0gUENFIHJlcXVp cmluZyBUTFMNCj4+IDEuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9uIGFuZCBUTFMgaGFu ZHNoYWtlDQo+DQo+IFdvdWxkbid0IHRoZSBUTFMgaGFuZHNoYWtlIGhlcmUgZmFpbD8gV2h5IHdv dWxkIHRoZSByZXN0IG9mIHRoZSBleGNoYW5nZSBvY2N1cj8NCj4NCj4+IDIuLSBQQ0VQIGV4Y2hh bmdlIHdpdGhpbiBUTFMgY29udGV4dA0KPj4gLS0tDQo+PiAxLi0gUENDIGluaXRpYXRlcyBUQ1Ag Y29ubmVjdGlvbiBhbmQgYXR0ZW1wdHMgYSBQQ0VQIE9QRU4gbWVzc2FnZQ0KPj4gMi4tIFBDRSBy ZWplY3RzIHRoZSBtZXNzYWdlIHdpdGggYSBQQ0VyciBtZXNzYWdlIChFcnJvci1UeXBlPTEsIEVy cm9yLXZhbHVlPTMsIFRMViBpZGVudGlmeWluZyB0aGUgbmVlZCBmb3IgVExTKG9wdGlvbmFsbHkp KQ0KPj4gMy4tIFBDQyBpbml0aWF0ZXMgVENQIGNvbm5lY3Rpb24gYW5kIFRMUyBoYW5kc2hha2UN Cj4+IDQuLSBQQ0VQIGV4Y2hhbmdlIHdpdGhpbiBUTFMgY29udGV4dA0KPg0KPiAoc2VlIGlzc3Vl IGFib3ZlKQ0KPg0KPj4gKiBXaXRob3V0IGRpc2NvdmVyeSAtIFBDRSBub3QgcmVxdWlyaW5nIFRM Uw0KPj4gMS4tIFBDQyBpbml0aWF0ZXMgVENQIGNvbm5lY3Rpb24NCj4+IDIuLSBQQ0VQIGV4Y2hh bmdlIG92ZXIgVENQDQo+PiAtLS0NCj4+IDEuLSBQQ0MgaW5pdGlhdGVzIFRDUCBjb25uZWN0aW9u IGFuZCBUTFMgaGFuZHNoYWtlDQo+DQo+IFdoeSBpcyB0aGlzIGV2ZW4gYXR0ZW1wdGVkPw0KPg0K Pj4gMi4tIE5vIFRMUyBjb250ZXh0IGVzdGFibGlzaGVkIHdpdGggUENFIG9yIGVycm9yIG1lc3Nh Z2UgcmVjZWl2ZWQNCj4+IChvcHRpb25hbGx5KQ0KPj4gMy4tIFBDQyBpbml0aWF0ZXMgVENQIGNv bm5lY3Rpb24NCj4+IDQuLSBQQ0VQIGV4Y2hhbmdlIG92ZXIgVENQDQo+Pg0KPj4gV2hhdCBkbyB5 b3UgdGhpbmsgb2YgdGhpcyBhcHByb2FjaD8NCj4+DQo+PiBBbHNvIHdlIGxpa2UgdG8gcG9pbnQg YSByZWxhdGVkIGRpc2N1c3Npb24gaGFwcGVuZWQgb24gVVRBIG1haWxpbmcgbGlzdDoNCj4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi91dGEvY3VycmVudC9tc2cwMDQyMy5o dG1sDQo+DQo+IFRob3NlIHBvaW50cyB3ZXJlIHJhaXNlZCBvbiB0aGUgVFNWV0cgbGlzdCB0b28s IGJ1dCBmYWlsIHRvIGFkZHJlc3MgdGhlIGtleSBpc3N1ZSAtIGluc2VjdXJlIHBvcnRzIGFyZSBp bnNlY3VyZS4gUmVnYXJkbGVzcyBvZiBob3cgbWFueSBwb3J0cyB3ZSBhbGxvY2F0ZSwgaXQncyBu byBsb25nZXIgY2xlYXIgd2Ugc2hvdWxkIGNvbnRpbnVlIHRvIGRlcGxveSBuZXcgaW5zZWN1cmUg c2VydmljZXMgb24gdGhlIEludGVybmV0Lg0KPg0KPiBKb2UNCj4NCj4+DQo+PiBSZWdhcmRzLA0K Pj4gQXV0aG9ycw0KPj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPj4g5Y+R5Lu25Lq6OiBKb2Ug VG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0M+ac iDEz5pelIDIzOjU4DQo+PiDmlLbku7bkuro6IFFpbiBXdTsgRGllZ28gUi4gTG9wZXo7IHRjcG1A aWV0Zi5vcmcNCj4+IOaKhOmAgTogZHJhZnQtaWV0Zi1wY2UtcGNlcHNAdG9vbHMuaWV0Zi5vcmcN Cj4+IOS4u+mimDogUmU6IFt0Y3BtXSBMb29raW5nIGZvciBhZHZpY2Ugb24gYSBkcmFmdCBmcm9t IHRoZSBQQ0Ugd29ya2luZyBncm91cA0KPj4NCj4+IEhpLCBRaW4sDQo+Pg0KPj4gT24gMy8xMy8y MDE0IDM6MzUgQU0sIFFpbiBXdSB3cm90ZToNCj4+PiBIaSwgSm9lOg0KPj4+DQo+Pj4gSXQgaXMg c3RpbGwgbm90IGNsZWFyIHRvIG1lIHdoZW4gd2UgY2hvb3NlIHRoZSBzYW1lIHBvcnQgYW5kIHdo ZW4gd2UNCj4+PiBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0IGlmIHdlIGFwcGx5IFRMUyB0byBk aWZmZXJlbnQgcHJvdG9jb2xzLA0KPj4NCj4+IEl0J3Mgc2ltcGxlIHRvIGRldGVybWluZToNCj4+ DQo+PiAgICAgIC0gaWYgeW91IGRlc2lnbmVkIHlvdXIgc2VydmljZSBiZWZvcmUgU1RBUlRUTFMs IHRoZW4geW91IG5lZWRlZA0KPj4gICAgICBhIHNlcGFyYXRlIHBvcnQNCj4+DQo+PiAgICAgIC0g aWYgeW91IGFyZSBkZXNpZ25pbmcgeW91ciBwb3J0IG5vdywgeW91IGRvbid0DQo+Pg0KPj4+IFRh a2UgU01UUCwgUE9QMyxJTUFQIGFzIGV4YW1wbGVzOg0KPj4gLi4uDQo+Pj4gSXQgbG9va3MgdG8g bWUgd2hlbiB3ZSBhcHBseSBTU0wgdG8gU01UUCxQT1AzLElNQVAsIHRoZW4gU01UUCwgUE9QMw0K Pj4+IGFuZCBJTUFQIHdpdGggU1NMIHN1cHBvcnQoaS5lLixTTVRQUyxQT1AzUyxJTUFQUykNCj4+ Pg0KPj4+IFdpbGwgdXN1YWxseSBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0cy4NCj4+Pg0KPj4+ IFRoZSBzYW1lIHJ1bGUgYWJvdmUgaXMgYWxzbyBhcHBsaWVkIHRvIEhUVFAgd2hlbiB3ZSBhcHBs eSBTU0wgdG8NCj4+PiBIVFRQKGkuZS4sIEhUVFBTKS4NCj4+DQo+PiBBbGwgb2YgdGhlIGFib3Zl IGFyZSBnb29kIGV4YW1wbGVzIG9mIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSBydWxlLg0KPj4NCj4+ IE5vdGUgdGhhdCB3ZSBoYXZlIG90aGVyIGFzc2lnbm1lbnRzIHRoYXQgbm93IHdvdWxkIGJlIGRl Y2xpbmVkLCBiZWNhdXNlIHdlJ3ZlIGxlYXJuZWQgdG8gZG8gYmV0dGVyLiBFLmcuLCB0aGVyZSB3 b3VsZCBub3QgYmUgYSBQT1AyIG9yIFBPUDMgYmVjYXVzZSB3ZSB3b3VsZCBleHBlY3QgUE9QIHRv IGluZGljYXRlIHRoZSBwcm90b2NvbCB2ZXJzaW9uIGluLWJhbmQuIFdlIGFsc28gbm8gbG9uZ2Vy IGFzc2lnbiBtdWx0aXBsZSBuYW1lcyBmb3IgdGhlIHNhbWUgc2VydmljZSwgYXMgd2FzIGRvbmUg Zm9yIGh0dHAvd3d3LCBub3IgZG8gd2Ugbm93IGFzc2lnbiBtdWx0aXBsZSBwb3J0cyBmb3IgdGhl IHNhbWUgc2VydmljZSAoODAsIDgwODApLCBub3IgZG8gd2Ugbm93IGFzc2lnbiBwb3J0cyBmb3Ig ZGV2ZWxvcG1lbnQgcHVycG9zZXMgIChodHRwLWRldikuDQo+Pg0KPj4gV2UndmUgbGVhcm5lZCB0 byBkbyBiZXR0ZXIuDQo+Pg0KPj4gSm9lDQo+Pg0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFy ZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJ K0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRp ZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZh bWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGlj YSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5s YWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNp dmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9u IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VT L1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From nobody Mon Jun 30 09:28:41 2014 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD11A03A1 for ; Mon, 30 Jun 2014 09:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFgghTsCeICr for ; Mon, 30 Jun 2014 09:28:37 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEB141A0385 for ; Mon, 30 Jun 2014 09:28:36 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5UGSFwS012525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Jun 2014 09:28:19 -0700 (PDT) Message-ID: <53B19022.4060107@isi.edu> Date: Mon, 30 Jun 2014 09:28:18 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <531F918C.2080700@isi.edu> <5321D570.60008@isi.edu> <53AE4617.2000800@isi.edu> <2E9995E5-16AC-4E8E-BF48-D9C3566CE8FE@tid.es> In-Reply-To: <2E9995E5-16AC-4E8E-BF48-D9C3566CE8FE@tid.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/WMXvvu1iiBMaIDDpF3VVH3t0pkA Cc: "adrian@olddog.co.uk" , "tcpm@ietf.org" , Qin Wu , "draft-ietf-pce-pceps@tools.ietf.org" Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: 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, 30 Jun 2014 16:28:40 -0000 On 6/30/2014 3:01 AM, Diego R. Lopez wrote: > Hi, > > We are not proposing to use STARTTLS because, after discussing the > different options for doing so in PCEP, we believe including it would > translate into a change of the PCEP protocol: > (1) against the original commitment of not changing it > (2) would translate into a much longer adoption by implementations I don't understand or agree with either position. STARTTLS does not change the protocol; it precedes it. The complex mechanism below is, IMO, much less likely to be successfuly adopted than STARTTLS, which is widely used. Joe > > Be goode, > > On 28 Jun 2014, at 06:35 , Joe Touch wrote: > >> Hi, >> >> On 6/24/2014 4:03 AM, Qin Wu wrote: >>> Hi, Joe: >>> Sorry for late reply. >>> >>> Authors have been discussing a mechanism to enable secure PCEP via >>> TLS without making changes to the current PCEP protocol or state >>> machine. >>> >>> Since having a separate port has been discouraged, we suggest the >> ? following approach based on discovery mechanisms or configuration and >>> initial transport security assessment by the peer. >>> >>> 1) A PCE (given a combination of IP address and port) only supports >>> one type of connection, either TLS or not. >> >> I'm not sure why that needs to be the case, given STARTTLS. >> >>> Note that a different IP >>> address SHOULD be used for supporting both and will be considered as >>> different PCEs. >> >> I don't quite understand this. Different IP addresses should be different PCEs anyway. If you want to support both encrypted and non-encrypted, why not use the existing TLS mechanism for that - STARTTLS? >> >>> 2) The PCC MAY discover whether the PCE is willing to connect, >>> requires TLS or not via any of the discovery mechanisms. >> >> That seems reasonable, but doesn't answer why a PCE needs to support only one type of connection. The discovery could indicate "either" and let the client decide, e.g., if both are supported (again, via STARTTLS) >> >>> 3) When connecting to a PCE that enforces TLS, the PCC MUST start a >>> TLS connection prior to any exchange of PCEP messages. >> >> Isn't that already what happens if TLS-only is used? >> >>> Any PCEP message >>> received out of an appropriate TLS context will be rejected by the PCE >>> with a PCErr (Error-Type=1, Error-value=3, TLV identifying the need for >>> TLS) message. [Existing error message, new TLV] >> >> If non-TLS connections are rejected, then there shouldn't be any such messages seen AFAICT. I.e., that would be a TLS port that is configured to not support STARTTLS. >> >>> 4) If a PCC attempts to start a TLS connection with a PCE without >>> success, it MAY attempt a further connection attempt without TLS on a >>> different IP address if known, though that could imply a security >>> degradation. >> >> I don't understand why a different address would be considered degraded access to the same PCE. That seems like a different PCE, as noted above. >> >> If you want to support degraded (non-secure) access, why not just support STARTTLS? >> >>> Several flows become possible this way, and discovery can be used to >> simplify them but it is not essential for them to work. Let's consider them >>> >>> * With discovery (or config) >>> 1.- PCC learn via discovery that the desired PCE require TLS. >>> 2.- PCC initiates TCP connection and TLS handshake >>> 3.- PCEP exchange within TLS context >> >> Makes sense. >> >>> --- >>> 1.- PCC learn via discovery that the desired PCE does not use TLS. >>> 2.- PCC initiates TCP connection >>> 3.- PCEP exchange over TCP >> >> Makes sense. >> >>> * Without discovery - PCE requiring TLS >>> 1.- PCC initiates TCP connection and TLS handshake >> >> Wouldn't the TLS handshake here fail? Why would the rest of the exchange occur? >> >>> 2.- PCEP exchange within TLS context >>> --- >>> 1.- PCC initiates TCP connection and attempts a PCEP OPEN message >>> 2.- PCE rejects the message with a PCErr message (Error-Type=1, Error-value=3, TLV identifying the need for TLS(optionally)) >>> 3.- PCC initiates TCP connection and TLS handshake >>> 4.- PCEP exchange within TLS context >> >> (see issue above) >> >>> * Without discovery - PCE not requiring TLS >>> 1.- PCC initiates TCP connection >>> 2.- PCEP exchange over TCP >>> --- >>> 1.- PCC initiates TCP connection and TLS handshake >> >> Why is this even attempted? >> >>> 2.- No TLS context established with PCE or error message received >>> (optionally) >>> 3.- PCC initiates TCP connection >>> 4.- PCEP exchange over TCP >>> >>> What do you think of this approach? >>> >>> Also we like to point a related discussion happened on UTA mailing list: >>> http://www.ietf.org/mail-archive/web/uta/current/msg00423.html >> >> Those points were raised on the TSVWG list too, but fail to address the key issue - insecure ports are insecure. Regardless of how many ports we allocate, it's no longer clear we should continue to deploy new insecure services on the Internet. >> >> Joe >> >>> >>> Regards, >>> Authors >>> -----邮件原件----- >>> 发件人: Joe Touch [mailto:touch@isi.edu] >>> 发送时间: 2014年3月13日 23:58 >>> 收件人: Qin Wu; Diego R. Lopez; tcpm@ietf.org >>> 抄送: draft-ietf-pce-pceps@tools.ietf.org >>> 主题: Re: [tcpm] Looking for advice on a draft from the PCE working group >>> >>> Hi, Qin, >>> >>> On 3/13/2014 3:35 AM, Qin Wu wrote: >>>> Hi, Joe: >>>> >>>> It is still not clear to me when we choose the same port and when we >>>> choose the different port if we apply TLS to different protocols, >>> >>> It's simple to determine: >>> >>> - if you designed your service before STARTTLS, then you needed >>> a separate port >>> >>> - if you are designing your port now, you don't >>> >>>> Take SMTP, POP3,IMAP as examples: >>> ... >>>> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3 >>>> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS) >>>> >>>> Will usually choose the different ports. >>>> >>>> The same rule above is also applied to HTTP when we apply SSL to >>>> HTTP(i.e., HTTPS). >>> >>> All of the above are good examples of the first part of the rule. >>> >>> Note that we have other assignments that now would be declined, because we've learned to do better. E.g., there would not be a POP2 or POP3 because we would expect POP to indicate the protocol version in-band. We also no longer assign multiple names for the same service, as was done for http/www, nor do we now assign multiple ports for the same service (80, 8080), nor do we now assign ports for development purposes (http-dev). >>> >>> We've learned to do better. >>> >>> Joe >>> > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >