From tcpm-bounces@ietf.org Wed Oct 1 12:33:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1143A6C4C; Wed, 1 Oct 2008 12:33:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D419E3A6918 for ; Wed, 1 Oct 2008 12:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5scK0L0zlNe for ; Wed, 1 Oct 2008 12:33:37 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 989A43A67A6 for ; Wed, 1 Oct 2008 12:33:37 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m91JXoIs018606; Wed, 1 Oct 2008 12:33:50 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 12:33:32 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 12:33:31 -0700 Message-Id: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: <48E2A22A.8000209@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 1 Oct 2008 14:33:29 -0500 References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF435A@xmb-sjc-21c.amer.cisco.com><48E110DE.8050903@isi.edu><724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com><3B570CE3-309B-4473-9A19-99905A93986A@windriver.com> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 01 Oct 2008 19:33:32.0193 (UTC) FILETIME=[96964110:01C923FC] Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Ok, Wes and I count four opinions against and two opinions for having = "Updates: 793" in the header of tcpsecure. Unless other folks chime = in, the resolution we see is: 1) "Updates: 793" is not put in the header of tcpsecure 2) When we send tcpsecure up to the IESG, we will note this issue and = the discussion, and if the IESG feels that is appropriate to have = "Updates: 793" in the header, then it can be added in. We think everyone has been heard and understood, but don't see this = conversation coming to full agreement. -David Borman & Wes Eddy, TCPM co-chairs On Sep 30, 2008, at 5:03 PM, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >>> -----Original Message----- >>> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] >>> Sent: Tuesday, September 30, 2008 1:47 PM >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; >>> tcpm@ietf.org >>> Cc: Alfred H=CEnes; Mitesh Dalal (mdalal); randall@lakerest.net; >>> ext Joe Touch >>> Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] >>> >>> Wes, >>> >>>> >>>> My personal opinion on the number of angels on the head of this >>>> pin is that 3168 redefines bits that were formerly reserved. Thus >>>> it "updates" the description of those bits in 793 (they're no = >>>> longer >>>> reserved). *Regardless* of the fact that 3168 is itself optional, >>>> those bits are no longer available in the way 793 describes. = >>>> *That* >>>> is why it has to "update" even though it's optional itself. >>>> >>>> The tcpsecure document does not "update" in that sense, as it only >>>> contains optional alternative state machine arcs; the arcs defined >>>> in 793 are still able to be used in the way 793 describes ... they >>>> aren't "updated", but there's now an alternative to them. >>> Are you saying that we should construe that "alternate >>> processing" doesn't update the RFC?. Now, the update itself >>> can be optional. In other words, my point is that the current >>> meaning and usage of "updates" is to be used for any updates >>> to the RFC, irrespective of the fact it is minor, major or >>> optional. Agreed that, currently there is fine granularity in >>> describing an update i.e, "minor update, medium update or >>> conditinal update " etc., until such a granularity is >>> available, we should use the existing documented mechanisms. >>> This is the reason I think it would be expedient to seek the >>> advice of IESG in this matter. >> >> >> My position is very simple: >> What part of RFC 793 is no longer correct? Which text is no >> longer accurate in RFC 793? >> >> With ECN, it's very clear, the answer is "the 2 reserved bits >> are not reserved anymore". With tcpsecure, the answer is also >> very clear: "nothing". You need to point to some part of 793 >> that is actually updated and not just alternatively defined, >> IMO. If 2581, 1323, and others don't update 793, then I don't >> see how tcpsecure can have any valid claim to. >> >> That's just my personal opinion, though. > > > This makes sense to me. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i > 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI > =3Dq5ru > -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Oct 1 16:15:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322783A6A80; Wed, 1 Oct 2008 16:15:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06E33A6985 for ; Wed, 1 Oct 2008 16:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPZPhwIh7lOi for ; Wed, 1 Oct 2008 16:15:13 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A5A573A698F for ; Wed, 1 Oct 2008 16:15:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,346,1220227200"; d="scan'208";a="85626462" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2008 23:15:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m91NFTfN021949; Wed, 1 Oct 2008 16:15:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m91NFThk024188; Wed, 1 Oct 2008 23:15:29 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Oct 2008 16:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Oct 2008 16:15:29 -0700 Message-ID: <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] Thread-Index: Ackj/KOHD9MzS2XBRdmx/SjKs35F6AAHXOww From: "Mitesh Dalal (mdalal)" To: "David Borman" , X-OriginalArrivalTime: 01 Oct 2008 23:15:29.0470 (UTC) FILETIME=[984D75E0:01C9241B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4771; t=1222902930; x=1223766930; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20(mdalal)=22=20 |Subject:=20RE=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=AdbpUDyMFC4z/BanxeBzv2kDyiYvdsYEPr2gUofqOpQ=; b=drrS70FjzNK/X3JC/eEDSdulxm691gEDhzTqCbyvaJnW0EQinhuaa2Qi87 TQ2pVGPHGnOKRREpBmrVul54NCjUIjEB7ujEWXyUTmQQ/DW65CS6XlCG4nGY m5rt33ZXiS; Authentication-Results: sj-dkim-2; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org vote for updates. = I personally feel we are reading too much into the updates lingo. = I didn't care one way or the other until somebody (Alfred ?) brought = this up. Given that this is standards track document, the entire = interne community will be well served if we clearly highlight where we are coming from. Updates in my mind does not mean a tcp V2 = nor it means MUST implement. It simply means a new piece of = information found that concerns a base spec and sheds some new light on it. Thanks Mitesh = > -----Original Message----- > From: David Borman [mailto:david.borman@windriver.com] = > Sent: Wednesday, October 01, 2008 12:33 PM > To: tcpm@ietf.org > Cc: Eddy, Wesley M. (GRC-RCN0)[VZ]; Anantha Ramaiah (ananth); = > Lars Eggert; Alfred H=CEnes; Mitesh Dalal (mdalal); Randy = > Stewart; Joe Touch > Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] > = > Ok, Wes and I count four opinions against and two opinions for having > "Updates: 793" in the header of tcpsecure. Unless other = > folks chime in, the resolution we see is: > = > 1) "Updates: 793" is not put in the header of tcpsecure > 2) When we send tcpsecure up to the IESG, we will note this = > issue and the discussion, and if the IESG feels that is = > appropriate to have > "Updates: 793" in the header, then it can be added in. > = > We think everyone has been heard and understood, but don't = > see this conversation coming to full agreement. > = > -David Borman & Wes Eddy, TCPM co-chairs > = > = > On Sep 30, 2008, at 5:03 PM, Joe Touch wrote: > = > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > > > Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > >>> -----Original Message----- > >>> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > >>> Sent: Tuesday, September 30, 2008 1:47 PM > >>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; = > >>> tcpm@ietf.org > >>> Cc: Alfred H=CEnes; Mitesh Dalal (mdalal); = > randall@lakerest.net; ext = > >>> Joe Touch > >>> Subject: RE: [tcpm] another review of = > draft-ietf-tcpm-tcpsecure[-10] > >>> > >>> Wes, > >>> > >>>> > >>>> My personal opinion on the number of angels on the head = > of this pin = > >>>> is that 3168 redefines bits that were formerly reserved. = > Thus it = > >>>> "updates" the description of those bits in 793 (they're = > no longer = > >>>> reserved). *Regardless* of the fact that 3168 is itself = > optional, > >>>> those bits are no longer available in the way 793 describes. = > >>>> *That* > >>>> is why it has to "update" even though it's optional itself. > >>>> > >>>> The tcpsecure document does not "update" in that sense, = > as it only = > >>>> contains optional alternative state machine arcs; the = > arcs defined = > >>>> in 793 are still able to be used in the way 793 = > describes ... they = > >>>> aren't "updated", but there's now an alternative to them. > >>> Are you saying that we should construe that "alternate = > processing" = > >>> doesn't update the RFC?. Now, the update itself can be = > optional. In = > >>> other words, my point is that the current meaning and usage of = > >>> "updates" is to be used for any updates to the RFC, = > irrespective of = > >>> the fact it is minor, major or optional. Agreed that, currently = > >>> there is fine granularity in describing an update i.e, "minor = > >>> update, medium update or conditinal update " etc., until such a = > >>> granularity is available, we should use the existing documented = > >>> mechanisms. > >>> This is the reason I think it would be expedient to seek = > the advice = > >>> of IESG in this matter. > >> > >> > >> My position is very simple: > >> What part of RFC 793 is no longer correct? Which text is = > no longer = > >> accurate in RFC 793? > >> > >> With ECN, it's very clear, the answer is "the 2 reserved = > bits are not = > >> reserved anymore". With tcpsecure, the answer is also very clear: = > >> "nothing". You need to point to some part of 793 that is actually = > >> updated and not just alternatively defined, IMO. If 2581, = > 1323, and = > >> others don't update 793, then I don't see how tcpsecure = > can have any = > >> valid claim to. > >> > >> That's just my personal opinion, though. > > > > > > This makes sense to me. > > > > Joe > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (MingW32) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i > > 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI > > =3Dq5ru > > -----END PGP SIGNATURE----- > = > = _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Oct 1 17:16:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702363A6862; Wed, 1 Oct 2008 17:16:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BF83A6862 for ; Wed, 1 Oct 2008 17:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3wQ0Kfhfyti for ; Wed, 1 Oct 2008 17:16:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id B3AF53A6811 for ; Wed, 1 Oct 2008 17:16:43 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m920GQrE011844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Oct 2008 17:16:27 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m920GPbg048640; Wed, 1 Oct 2008 17:16:25 -0700 (PDT) (envelope-from faber) Date: Wed, 1 Oct 2008 17:16:25 -0700 From: Ted Faber To: "Mitesh Dalal (mdalal)" Message-ID: <20081002001625.GQ60793@zod.isi.edu> References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: Alfred =?iso-8859-1?Q?H=CEnes?= , tcpm@ietf.org, David Borman , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0394030770==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0394030770== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/YnR2r17TIEndSCI" Content-Disposition: inline --/YnR2r17TIEndSCI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 01, 2008 at 04:15:29PM -0700, Mitesh Dalal (mdalal) wrote: > vote for updates.=20 I do not believe this draft updates 793. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --/YnR2r17TIEndSCI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjkEtkACgkQaUz3f+Zf+Xv33gCcCvzTosKrsaGODhki/2SJgBWm JwIAn0KKpHuiMRR6rFEK+o+wlJ4fPtFt =MxeY -----END PGP SIGNATURE----- --/YnR2r17TIEndSCI-- --===============0394030770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0394030770==-- From tcpm-bounces@ietf.org Wed Oct 1 17:25:01 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65213A69C6; Wed, 1 Oct 2008 17:25:01 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF8D3A69C6 for ; Wed, 1 Oct 2008 17:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsYEDD3VPcXR for ; Wed, 1 Oct 2008 17:24:59 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id AF87F3A69B1 for ; Wed, 1 Oct 2008 17:24:59 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so757703rvf.49 for ; Wed, 01 Oct 2008 17:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=P56xihvVhDCVvnr6K7eX4gpl/1czbMuiPAvD7U5nAOw=; b=UWcyFefan9E158TLvHauCTTLBXIPgwO9+K8HNVFpER6zKa91KbLLbItZpf/xI4zZ37 sYUaCcegPxHP9tWVnXVn+HdCjeie4O57lyjTG7vhGqfAW1wzP4EoZm720Qg3l3IdSYw4 LKYgQZTy4bNcvw44lCdEk/LFggo5FeHDeUsQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=MmLwelEn0fePupXRlkpgLhHcoUX1FTHm/gjLucLBohbZl1/Tqbw7rQZnl5xBNrVlYz K65bAxCSdBI1gjDQMpwd5BxNA7LYVej0QA64bSPHHDEztIa3m6GWtMMfpytMgfeXXRoS wA5ILs1VtWFqz4rfy1AahIqyNPMtz8mkwyR+k= Received: by 10.142.229.5 with SMTP id b5mr3603751wfh.50.1222907123951; Wed, 01 Oct 2008 17:25:23 -0700 (PDT) Received: by 10.142.116.4 with HTTP; Wed, 1 Oct 2008 17:25:23 -0700 (PDT) Message-ID: <9c8209a10810011725u5014bf04tceef1608fa79ca31@mail.gmail.com> Date: Wed, 1 Oct 2008 17:25:23 -0700 From: "Murali Bashyam" To: "David Borman" In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> MIME-Version: 1.0 References: <200808140650.IAA05627@TR-Sys.de> <48E110DE.8050903@isi.edu> <724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com> <3B570CE3-309B-4473-9A19-99905A93986A@windriver.com> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0858902306==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0858902306== Content-Type: multipart/alternative; boundary="----=_Part_73891_6080660.1222907123943" ------=_Part_73891_6080660.1222907123943 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It seems to me that if the rules of the processing of TCP segments are modified , then it updates RFC 793. By that definition, this draft does revise RFC 793 especially w.r.t handling rules for those (SYN , RST) segments. My vote is for having "Updates : 793" in the header. On Wed, Oct 1, 2008 at 12:33 PM, David Borman w= rote: > Ok, Wes and I count four opinions against and two opinions for having > "Updates: 793" in the header of tcpsecure. Unless other folks chime in, = the > resolution we see is: > > 1) "Updates: 793" is not put in the header of tcpsecure > 2) When we send tcpsecure up to the IESG, we will note this issue and the > discussion, and if the IESG feels that is appropriate to have "Updates: 7= 93" > in the header, then it can be added in. > > We think everyone has been heard and understood, but don't see this > conversation coming to full agreement. > > -David Borman & Wes Eddy, TCPM co-chairs > > > > On Sep 30, 2008, at 5:03 PM, Joe Touch wrote: > > -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >> >>> -----Original Message----- >>>> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] >>>> Sent: Tuesday, September 30, 2008 1:47 PM >>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; >>>> tcpm@ietf.org >>>> Cc: Alfred H=CEnes; Mitesh Dalal (mdalal); randall@lakerest.net; >>>> ext Joe Touch >>>> Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] >>>> >>>> Wes, >>>> >>>> >>>>> My personal opinion on the number of angels on the head of this >>>>> pin is that 3168 redefines bits that were formerly reserved. Thus >>>>> it "updates" the description of those bits in 793 (they're no longer >>>>> reserved). *Regardless* of the fact that 3168 is itself optional, >>>>> those bits are no longer available in the way 793 describes. *That* >>>>> is why it has to "update" even though it's optional itself. >>>>> >>>>> The tcpsecure document does not "update" in that sense, as it only >>>>> contains optional alternative state machine arcs; the arcs defined >>>>> in 793 are still able to be used in the way 793 describes ... they >>>>> aren't "updated", but there's now an alternative to them. >>>>> >>>> Are you saying that we should construe that "alternate >>>> processing" doesn't update the RFC?. Now, the update itself >>>> can be optional. In other words, my point is that the current >>>> meaning and usage of "updates" is to be used for any updates >>>> to the RFC, irrespective of the fact it is minor, major or >>>> optional. Agreed that, currently there is fine granularity in >>>> describing an update i.e, "minor update, medium update or >>>> conditinal update " etc., until such a granularity is >>>> available, we should use the existing documented mechanisms. >>>> This is the reason I think it would be expedient to seek the >>>> advice of IESG in this matter. >>>> >>> >>> >>> My position is very simple: >>> What part of RFC 793 is no longer correct? Which text is no >>> longer accurate in RFC 793? >>> >>> With ECN, it's very clear, the answer is "the 2 reserved bits >>> are not reserved anymore". With tcpsecure, the answer is also >>> very clear: "nothing". You need to point to some part of 793 >>> that is actually updated and not just alternatively defined, >>> IMO. If 2581, 1323, and others don't update 793, then I don't >>> see how tcpsecure can have any valid claim to. >>> >>> That's just my personal opinion, though. >>> >> >> >> This makes sense to me. >> >> Joe >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i >> 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI >> =3Dq5ru >> -----END PGP SIGNATURE----- >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --=20 Rgds, Murali Bashyam (c) (510)6736915 ----------------------------- CONFIDENTIAL -------------------- ***************************************************** This telecommunication and any data attached to, or included in it is considered confidential, and is intended only for use by the named recipient. The contents may be legally protected as any one or more of: copyrighted material, trade-secret protected material, attorney-client privileged material, attorney workproduct, or as material covered by any other legally available means. If you received this material in error, please notify the sender and destroy the original and all copies, whether electronic or otherwise. Thank you. ***************************************************** ------------------------------ CONFIDENTIAL -------------------- ------=_Part_73891_6080660.1222907123943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
It seems to me that if the rules of the processing of TCP = segments are modified , then it updates RFC 793. By that definition, this d= raft does revise RFC 793  especially w.r.t handling rules for those (S= YN , RST) segments. My vote is for having "Updates : 793" in the = header.

On Wed, Oct 1, 2008 at 12:33 PM, David Borma= n <david= .borman@windriver.com> wrote:
Ok, Wes and I count four opinions against and two opinions for having "= ;Updates: 793" in the header of tcpsecure.  Unless other folks ch= ime in, the resolution we see is:

1) "Updates: 793" is not put in the header of tcpsecure
2) When we send tcpsecure up to the IESG, we will note this issue and the d= iscussion, and if the IESG feels that is appropriate to have "Updates:= 793" in the header, then it can be added in.

We think everyone has been heard and understood, but don't see this con= versation coming to full agreement.

                    &nbs= p;  -David Borman & Wes Eddy, TCPM co-chairs



On Sep 30, 2008, at 5:03 PM, Joe Touch wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
-----Original Message-----
From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com]
Sent: Tuesday, September 30, 2008 1:47 PM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert;
tcpm@ietf.org
Cc: Alfred H=CEnes; Mitesh Dalal (mdalal); randall@lakerest.net;
ext Joe Touch
Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]

Wes,


My personal opinion on the number of angels on the head of this
pin is that 3168 redefines bits that were formerly reserved.  Thus
it "updates" the description of those bits in 793 (they're no= longer
reserved).  *Regardless* of the fact that 3168 is itself optional,
those bits are no longer available in the way 793 describes.  *That* is why it has to "update" even though it's optional itself.
The tcpsecure document does not "update" in that sense, as it onl= y
contains optional alternative state machine arcs; the arcs defined
in 793 are still able to be used in the way 793 describes ... they
aren't "updated", but there's now an alternative to them.=
Are you saying that we should construe that "alternate
processing" doesn't update the RFC?. Now, the update itself
can be optional. In other words, my point is that the current
meaning and usage of "updates" is to be used for any updates
to the RFC, irrespective of the fact it is minor, major or
optional. Agreed that, currently there is fine granularity in
describing an update i.e, "minor update, medium update or
conditinal update " etc., until such a granularity is
available, we should use the existing documented mechanisms.
This is the reason I think it would be expedient to seek the
advice of IESG in this matter.


My position is very simple:
What part of RFC 793 is no longer correct?  Which text is no
longer accurate in RFC 793?

With ECN, it's very clear, the answer is "the 2 reserved bits
are not reserved anymore".  With tcpsecure, the answer is also very clear: "nothing".  You need to point to some part of 79= 3
that is actually updated and not just alternatively defined,
IMO.  If 2581, 1323, and others don't update 793, then I don't=
see how tcpsecure can have any valid claim to.

That's just my personal opinion, though.


This makes sense to me.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i
2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI
=3Dq5ru
-----END PGP SIGNATURE-----

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



--
Rgds,
Mu= rali Bashyam
(c) (510)6736915

----------------------------- CONFI= DENTIAL  --------------------
*************************************= ****************
This telecommunication and any data attached to, or included in it
is co= nsidered confidential, and is intended only for use by the named
recipie= nt. The contents may be legally protected as any one or more of:
copyrig= hted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any= other legally available means. If you received this material in
error, = please notify the sender and destroy the original and all copies,
whethe= r electronic or otherwise. Thank you.
*****************************************************
------------------= ------------ CONFIDENTIAL  --------------------
------=_Part_73891_6080660.1222907123943-- --===============0858902306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0858902306==-- From tcpm-bounces@ietf.org Thu Oct 2 06:54:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382953A685B; Thu, 2 Oct 2008 06:54:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C47B3A659B; Thu, 2 Oct 2008 06:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+iFrioSDSaz; Thu, 2 Oct 2008 06:54:46 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 0F2BF3A6784; Thu, 2 Oct 2008 06:54:45 -0700 (PDT) Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m92Dt5u8011586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2008 16:55:06 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> From: Lars Eggert To: TSV Area , tcpm Extensions WG Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 16:55:05 +0300 References: <20081002093129.5bb80658@cs.columbia.edu> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8371/Thu Oct 2 13:15:33 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [IPv6:2001:2060:40:1::123]); Thu, 02 Oct 2008 16:55:10 +0300 (EEST) Subject: [tcpm] Fwd: Secdir Review of draft-stjohns-sipso-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1117787055==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1117787055== Content-Type: multipart/signed; boundary=Apple-Mail-27--164630064; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-27--164630064 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit FYI, this discussion on the main IETF list needs input from transport folks. Look at Section 7.3 of draft-stjohns-sipso-05. Lars Begin forwarded message: > From: "ext Steven M. Bellovin" > Date: October 2, 2008 16:31:29 GMT+03:00 > To: "Steven M. Bellovin" > Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman >, secdir@mit.edu, ietf@ietf.org > Subject: Re: Secdir Review of draft-stjohns-sipso-05 > > On Wed, 1 Oct 2008 22:12:17 -0400 > "Steven M. Bellovin" wrote: > >>> Steven> Note 7.3.1 on >>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>> Steven> with 793 on the treatment of security labels in section >>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>> >>> I had completely missed this. I'll call out the section to the >>> transport ADs >>> >> I should have added: I think the new document is in fact more correct >> than 793 -- the 793 scheme would permit various forms of >> high-bandwidth covert channels to be set up. This is an issue that >> was not nearly that well understood when 793 was written. That said, >> it is a change to TCP, and needs to be treated as such. >> > Thinking further -- I suspect that the right thing to do here is for > someone to write a short, simple draft amending 793 -- it's handling > of > the security option is simply wrong, independent of this draft. I > wonder -- what TCPs actually implement even 793? NetBSD doesn't; I > strongly suspect that no BSDs do. Does Solaris? Linux? > > --Steve Bellovin, http://www.cs.columbia.edu/~smb > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-27--164630064 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwMjEzNTUwNlowIwYJKoZI hvcNAQkEMRYEFNG5GG/xT+MEEWk+1spaBhtNtf+JMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQC+hTI2pc8+gbAJObm/awiLvSbf YSJ8GiAUbqYR4OX5RJM+cQJGDaGkmszEMtwtV5Va3z9Zqrmu4NWs1D4qO8eLi7QiiDy3t88FBHO+ AcjynfGMm7BXYTm31BkGrM3xeWQZyut8iEd1yVM96aafManFyYSFS6XazIOzrddtgrn80bqMTCuS WYX6/vKiJdTUVhPWMUH36ua+WDq0lHlhbdsnz375/gRtBv6Uj139CQgIRQY5CuA8XknWJvcIOeCw Yi/6zy4pRvBuLdmnBvj+Ovte9UoY+dQPpvQ3ZvtrC0M4d9qBr/I8na5r99fngGDb/AkQ0VzTVmRe Vv2s0+yA1vg8AAAAAAAA --Apple-Mail-27--164630064-- --===============1117787055== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1117787055==-- From tcpm-bounces@ietf.org Thu Oct 2 09:57:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1047E3A6A0C; Thu, 2 Oct 2008 09:57:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8CA3A6A0C for ; Thu, 2 Oct 2008 09:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwcAilfK-fy9 for ; Thu, 2 Oct 2008 09:57:34 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 2F4463A694C for ; Thu, 2 Oct 2008 09:57:34 -0700 (PDT) Received: from [192.168.255.2] (a88-114-157-111.elisa-laajakaista.fi [88.114.157.111]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m92Gtn6j012374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2008 19:55:50 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> From: Lars Eggert To: ext Ted Faber In-Reply-To: <20081002001625.GQ60793@zod.isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 19:55:49 +0300 References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8371/Thu Oct 2 13:15:33 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Thu, 02 Oct 2008 19:55:59 +0300 (EEST) Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, David Borman , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0081354451==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0081354451== Content-Type: multipart/signed; boundary=Apple-Mail-2--153786620; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-2--153786620 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, FYI, Pasi Eronen pointed me at RFC2223, which defines what "updates" means. In Section 12, it says: 12. Relation to other RFCs Sometimes an RFC adds information on a topic discussed in a previous RFC or completely replaces an earlier RFC. There are two terms used for these cases respectively, Updates and Obsoletes. A document that obsoletes an earlier document can stand on its own. A document that merely updates an earlier document cannot stand on its own; it is something that must be added to or inserted into the previously existing document, and has limited usefulness independently. The terms Supercedes and Replaces are no longer used. Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Nothing in that text talks about conditional applicability, and the argument that tcpsecure is an addendum to be added as an optional component to RFC793 can be made. The unfortunate thing is that the IETF's running code has been different from what RFC2223 describes, at least to some degree even back then and certainly since. I other words, according to the definition in RFC2223, many more RFCs should have been updating RFC793 over the years, not to speak of other RFC/protocol families. Lars --Apple-Mail-2--153786620 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwMjE2NTU0OVowIwYJKoZI hvcNAQkEMRYEFEdbNZPXemW1bMSALdM7FpPlHhmgMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQAMWTh6PAijI9z1eg3VYBjQv/kH VbjvDFvFitfLt7ufxQHSDP8XzoufBa/2EtT0gZomgS9HAPhi3xEoZ8CQt3r5WQM2S9aBI/TvBIwm OH4ESm6kflZNhTUaiWKI2B4AoAMtRK3sBU2KL6h7ol1ahYS/rbImF8A3LYlKh+/U/Jb+Y3/RGVVv 6VOudr4huWwBg0PP3RkV+sCIgY831pGNMa5p4SjI7vI8//bLrCiKjMT1mYfCQ5iT1YYz57fzpmMo ueNu8LzV5v+eUAx4MskUZ7bX9LehuLOFYQXeJSfOHW1QLAtE3krrQ3mIAKusO/BWx1qvxCoUJIlp Slzp11oAP4X3AAAAAAAA --Apple-Mail-2--153786620-- --===============0081354451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0081354451==-- From tcpm-bounces@ietf.org Thu Oct 2 10:11:43 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A84F3A6AAE; Thu, 2 Oct 2008 10:11:43 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2F23A69DA for ; Thu, 2 Oct 2008 10:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcGrf7-Z3MLi for ; Thu, 2 Oct 2008 10:11:41 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id A6A7A3A6AAE for ; Thu, 2 Oct 2008 10:11:35 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m92HB5uH000354; Thu, 2 Oct 2008 20:11:05 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id m92HB5hQ003030; Thu, 2 Oct 2008 20:11:05 +0300 Received: from hell.hell.gr (adsl61-198.lsf.forthnet.gr [79.103.188.198]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m92HB0ov005044; Thu, 2 Oct 2008 20:11:02 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral From: Stefanos Harhalakis To: tcpm@ietf.org Date: Thu, 2 Oct 2008 20:10:59 +0300 User-Agent: KMail/1.9.9 References: <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200810022011.00289.v13@v13.gr> Cc: Alfred =?utf-8?q?H=C3=8Enes?= , David Borman , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thursday 02 October 2008, Mitesh Dalal (mdalal) wrote: > vote for updates. > > I personally feel we are reading too much into the updates lingo. > I didn't care one way or the other until somebody (Alfred ?) brought > this up. Given that this is standards track document, the entire > interne community will be well served if we clearly highlight where > we are coming from. Updates in my mind does not mean a tcp V2 > nor it means MUST implement. It simply means a new piece of > information found that concerns a base spec and sheds some new > light on it. When I read 'updated by' for an RFC I understand that if I want to implement a current version of that RFC then I need to also read the 'updated by' document. A good example is RFC 4032 (Update to the Session Initiation Protocol (SIP)) which says: (Abstract) This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. (Introduction) This document updates RFC 3312, provides guidelines for authors of new precondition types and explains which topics they need to discuss when defining them. In addition, it updates some of the procedures in RFC 3312 for using SIP preconditions in situations that involve session mobility as described below. Since tcpsecure does something simillar it may just need a sentence like "This document updates RFC 793 blah blah". The rationale is that whoever implements a current version of RFC 793 should also have in mind tcpsecure. So, FWIW, I believe that tcpsecure should update RFC 793. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:20:07 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4E13A69DA; Thu, 2 Oct 2008 10:20:07 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AEB3A6816 for ; Thu, 2 Oct 2008 10:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubbCjqZIRDdw for ; Thu, 2 Oct 2008 10:20:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 32FA73A67E4 for ; Thu, 2 Oct 2008 10:20:00 -0700 (PDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92HJTft024228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 10:19:32 -0700 (PDT) Message-ID: <48E502A1.5060006@isi.edu> Date: Thu, 02 Oct 2008 10:19:29 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lars Eggert References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> In-Reply-To: <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, David Borman , "Anantha Ramaiah \(ananth\)" , ext Ted Faber , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FWIW, we're dealing not only with what RFC2223 says in this regard, but the current IETF culture of when to use "updates". As I've noted, there are other extensions to TCP that are more "updates" than this. We have a roadmap document to more clearly explain the relationship of components to 793; when that document is updated, tcpsecure should be added to that. Given the complexity of that document, this label isn't going to help, and IMO will misdirect implementers to include this where it wasn't necessary. I see no reason to lead the charge of changing IETF culture on this issue with this document, and specific reasons NOT to use this document as the defining case. Joe Lars Eggert wrote: > Hi, > > FYI, Pasi Eronen pointed me at RFC2223, which defines what "updates" > means. In Section 12, it says: > > 12. Relation to other RFCs > > Sometimes an RFC adds information on a topic discussed in a previous > RFC or completely replaces an earlier RFC. There are two terms used > for these cases respectively, Updates and Obsoletes. A document that > obsoletes an earlier document can stand on its own. A document that > merely updates an earlier document cannot stand on its own; it is > something that must be added to or inserted into the previously > existing document, and has limited usefulness independently. The > terms Supercedes and Replaces are no longer used. > > Updates > > To be used as a reference from a new item that cannot be used > alone (i.e., one that supplements a previous document), to refer > to the previous document. The newer publication is a part that > will supplement or be added on to the existing document; e.g., an > addendum, or separate, extra information that is to be added to > the original document. > > Nothing in that text talks about conditional applicability, and the > argument that tcpsecure is an addendum to be added as an optional > component to RFC793 can be made. > > The unfortunate thing is that the IETF's running code has been different > from what RFC2223 describes, at least to some degree even back then and > certainly since. I other words, according to the definition in RFC2223, > many more RFCs should have been updating RFC793 over the years, not to > speak of other RFC/protocol families. > > Lars -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlAqAACgkQE5f5cImnZrsr7ACg+qDI6l+4QfjyI2UYCsxs6o4T tzEAoNXu6K7Pz2/7uXhyiqKwH+qIksRk =KhuK -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:24:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8CDC28C102; Thu, 2 Oct 2008 10:24:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D1F3A6AE1; Thu, 2 Oct 2008 10:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9FJ0QrX162e; Thu, 2 Oct 2008 10:24:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 42EE63A695B; Thu, 2 Oct 2008 10:24:17 -0700 (PDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92HO6FV025727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 10:24:09 -0700 (PDT) Message-ID: <48E503B6.7010505@isi.edu> Date: Thu, 02 Oct 2008 10:24:06 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lars Eggert References: <20081002093129.5bb80658@cs.columbia.edu> <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> In-Reply-To: <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm Extensions WG , TSV Area Subject: Re: [tcpm] [tsv-area] Fwd: Secdir Review of draft-stjohns-sipso-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Lars, Are you suggesting we have that discussion there, or that they move this issue here (e.g., to TCPM or TSVAREA)? I would expect the latter would be more useful... Joe Lars Eggert wrote: > FYI, this discussion on the main IETF list needs input from transport > folks. Look at Section 7.3 of draft-stjohns-sipso-05. > > Lars > > Begin forwarded message: > >> From: "ext Steven M. Bellovin" >> Date: October 2, 2008 16:31:29 GMT+03:00 >> To: "Steven M. Bellovin" >> Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman >> , secdir@mit.edu, ietf@ietf.org >> Subject: Re: Secdir Review of draft-stjohns-sipso-05 >> >> On Wed, 1 Oct 2008 22:12:17 -0400 >> "Steven M. Bellovin" wrote: >> >>>> Steven> Note 7.3.1 on >>>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>>> Steven> with 793 on the treatment of security labels in section >>>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>>> >>>> I had completely missed this. I'll call out the section to the >>>> transport ADs >>>> >>> I should have added: I think the new document is in fact more correct >>> than 793 -- the 793 scheme would permit various forms of >>> high-bandwidth covert channels to be set up. This is an issue that >>> was not nearly that well understood when 793 was written. That said, >>> it is a change to TCP, and needs to be treated as such. >>> >> Thinking further -- I suspect that the right thing to do here is for >> someone to write a short, simple draft amending 793 -- it's handling of >> the security option is simply wrong, independent of this draft. I >> wonder -- what TCPs actually implement even 793? NetBSD doesn't; I >> strongly suspect that no BSDs do. Does Solaris? Linux? >> >> --Steve Bellovin, http://www.cs.columbia.edu/~smb >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlA7UACgkQE5f5cImnZrszXQCeNkIxxBZUmEjidZBxwF5RMaDg sgEAn3aoDE4kcBsV7kglGiXvKbRWZwK6 =fiTu -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:36:20 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517FD3A6A8D; Thu, 2 Oct 2008 10:36:20 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421123A6A8D for ; Thu, 2 Oct 2008 10:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.27 X-Spam-Level: * X-Spam-Status: No, score=1.27 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN68qXDx1y-p for ; Thu, 2 Oct 2008 10:36:18 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id AE22B3A6816 for ; Thu, 2 Oct 2008 10:36:17 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA165018898; Thu, 2 Oct 2008 19:34:58 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA13446; Thu, 2 Oct 2008 19:34:57 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200810021734.TAA13446@TR-Sys.de> To: lars.eggert@nokia.com, tcpm@ietf.org Date: Thu, 2 Oct 2008 19:34:57 +0200 (MESZ) In-Reply-To: <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> from Lars Eggert at Oct "2, " 2008 "07:55:49" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org In <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com>, Lars Eggert wrote: > ... > > The unfortunate thing is that the IETF's running code has been > different from what RFC2223 describes, at least to some degree even > back then and certainly since. I other words, according to the > definition in RFC2223, many more RFCs should have been updating > RFC793 over the years, not to speak of other RFC/protocol families. > > Lars That's exactly what I personally feel and 'preach', also based on feedback from networking practitioners not familar with the details of the procedures within the IETF -- also our 'customers', isn't it? Nevertheless, quit a couple of such "Updates" <--> "Updated by" metadata relationships have been added to the RFC index 'after the fact', based on RFC Errata and less formal discussion, and the last such addition I am aware of happened only a few weeks ago. BTW: The personal copy of the RFC index I maintain contains additional tags like "eff. Updated by ...", "eff. Historic", etc. [For anybody wanting to be assured, "eff." stands for "effectively".] Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:51:42 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC153A6ABA; Thu, 2 Oct 2008 10:51:42 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DFA43A697A for ; Thu, 2 Oct 2008 10:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpx0Jqje5748 for ; Thu, 2 Oct 2008 10:51:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7316B3A69DA for ; Thu, 2 Oct 2008 10:51:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,352,1220227200"; d="scan'208";a="167516436" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2008 17:52:05 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m92Hq5sP018181; Thu, 2 Oct 2008 10:52:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m92Hq54O015698; Thu, 2 Oct 2008 17:52:05 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 10:52:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 10:52:04 -0700 Message-ID: <0C53DCFB700D144284A584F54711EC5805E5BB5E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <48E502A1.5060006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] Thread-Index: Ackksx6V++O+HJhNSw+kWz8E7b9bEwAAKIog References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> <48E502A1.5060006@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Lars Eggert" X-OriginalArrivalTime: 02 Oct 2008 17:52:05.0112 (UTC) FILETIME=[94D12780:01C924B7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=424; t=1222969925; x=1223833925; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20 |Subject:=20RE=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=kEYnW3qa1lKIfdEONUh7fe/2oMXxS1LIywjmfZpal2g=; b=qNJ95//NhRCo/xrKTmNU93Y41//tWn3ObJq0JRmsthLFJY5ylt6r3gtUNY +fj+pyuiSa04Gnea9JzLbKtL+TYBBkGRrDvxNP+8IQuSzdTHRbQJluax3Pgq YOD23430RTIQ2j0y8bqSaXTPXgHRzYb+tzq9fwx58tDEQoVOCE2NU=; Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, David Borman , ext Ted Faber , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > Given the > complexity of that document, this label isn't going to help, > and IMO will misdirect implementers to include this where it > wasn't necessary. We have already addressed the "mis-direction" case, by adding the qualifiers (SHOULD, MAY etc.,) and more importantly the applicability statement. Actually not adding "updates" would mis-direct the implementers, IMO. -Anantha _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:59:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6722B3A6AAE; Thu, 2 Oct 2008 10:59:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BACF3A6816 for ; Thu, 2 Oct 2008 10:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1OPMPs0Yz7i for ; Thu, 2 Oct 2008 10:59:12 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 199CB3A6AAE for ; Thu, 2 Oct 2008 10:59:12 -0700 (PDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92HxAhA007879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 10:59:12 -0700 (PDT) Message-ID: <48E50BEE.904@isi.edu> Date: Thu, 02 Oct 2008 10:59:10 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> <48E502A1.5060006@isi.edu> <0C53DCFB700D144284A584F54711EC5805E5BB5E@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5805E5BB5E@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, David Borman , Randy Stewart , ext Ted Faber , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anantha Ramaiah (ananth) wrote: > >> Given the >> complexity of that document, this label isn't going to help, >> and IMO will misdirect implementers to include this where it >> wasn't necessary. > > We have already addressed the "mis-direction" case, by adding the qualifiers (SHOULD, MAY etc.,) and more importantly the applicability statement. Actually not adding "updates" would mis-direct the implementers, IMO. Presumably we agree that most current mods to 793 don't include "Updates." By that logic, adding "Updates" here flags this as more important or more relevant than the current mods. Since I do not believe that is accurate, that is the kind of misdirection I'm speaking to. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlC+0ACgkQE5f5cImnZrtYGgCgh8tAlPHVjyRUfdBtghDEj6wH HD0AoLw3K2cFNY1w7eLWATMs3arR6ixf =vvPW -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 10:59:23 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955BE28C142; Thu, 2 Oct 2008 10:59:23 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFAC28C13E for ; Thu, 2 Oct 2008 10:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hQkmhQy4lLL for ; Thu, 2 Oct 2008 10:59:21 -0700 (PDT) Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id D057028C116 for ; Thu, 2 Oct 2008 10:59:20 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 57C3179A53; Thu, 2 Oct 2008 12:59:43 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m92Hxg4T029052; Thu, 2 Oct 2008 12:59:42 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Oct 2008 12:59:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Oct 2008 12:59:42 -0500 Message-ID: In-Reply-To: <48E502A1.5060006@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] Thread-Index: Ackksywn5m1ZacUKTKOtAUnjb7ekQQAAl7yg References: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <13D1EAB852BE194C94773A947138483D061CA91D@xmb-sjc-21c.amer.cisco.com> <20081002001625.GQ60793@zod.isi.edu> <0A1AC67E-26EE-4553-92FA-7FDC46685B37@nokia.com> <48E502A1.5060006@isi.edu> From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: "Joe Touch" , "Lars Eggert" X-OriginalArrivalTime: 02 Oct 2008 17:59:42.0305 (UTC) FILETIME=[A5534510:01C924B8] Cc: tcpm@ietf.org Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org >-----Original Message----- >From: Joe Touch [mailto:touch@ISI.EDU] >Sent: Thursday, October 02, 2008 1:19 PM > >FWIW, we're dealing not only with what RFC2223 says in this regard, but >the current IETF culture of when to use "updates". > >As I've noted, there are other extensions to TCP that are more >"updates" >than this. We have a roadmap document to more clearly explain the >relationship of components to 793; when that document is updated, >tcpsecure should be added to that. Given the complexity of that >document, this label isn't going to help, and IMO will misdirect >implementers to include this where it wasn't necessary. > >I see no reason to lead the charge of changing IETF culture on this >issue with this document, and specific reasons NOT to use this document >as the defining case. It's just my personal opinion, but I'm in full agreement with Joe. Further, I think that if people are interpreting "updates" as "we should read and consider implementing", then I'm especially hesitant to have IPR-encumbered documents "update" 793, as it becomes an advertisement attached to the base of TCP. I also feel that tcpsecure is really a stop-gap to handle packets with spoofed addresses, that could've/should've been caught elsewhere (RFC 4953) and in more powerful ways (ingress filters, ipsec, md5, gtsm, etc.) depending on deployment particulars. It happens to be a nice and effective stop-gap, but the long-term solution is to make spoofed packets become nonexistent, at which point we'll no longer need tcpsecure. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 11:36:34 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FFD28C242; Thu, 2 Oct 2008 11:36:34 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4B828C134; Thu, 2 Oct 2008 11:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh7UOCHpC9xq; Thu, 2 Oct 2008 11:36:32 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id C4E2D28C23A; Thu, 2 Oct 2008 11:36:31 -0700 (PDT) Received: from [192.168.255.2] (a88-114-157-111.elisa-laajakaista.fi [88.114.157.111]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m92IalnX012746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2008 21:36:48 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <3BD35F16-FE31-402D-BEAE-0E0206A372D4@nokia.com> From: Lars Eggert To: ext Joe Touch In-Reply-To: <48E503B6.7010505@isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 21:36:40 +0300 References: <20081002093129.5bb80658@cs.columbia.edu> <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> <48E503B6.7010505@isi.edu> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8372/Thu Oct 2 18:21:47 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Thu, 02 Oct 2008 21:36:56 +0300 (EEST) Cc: tcpm Extensions WG , TSV Area Subject: Re: [tcpm] [tsv-area] Fwd: Secdir Review of draft-stjohns-sipso-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658719807==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1658719807== Content-Type: multipart/signed; boundary=Apple-Mail-7--147735105; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-7--147735105 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I'd suggest over there. Or at least CC the folks that are on the current thread there, it's a pretty diverse set of people. Lars On 2008-10-2, at 20:24, ext Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Lars, > > Are you suggesting we have that discussion there, or that they move > this > issue here (e.g., to TCPM or TSVAREA)? > > I would expect the latter would be more useful... > > Joe > > Lars Eggert wrote: >> FYI, this discussion on the main IETF list needs input from transport >> folks. Look at Section 7.3 of draft-stjohns-sipso-05. >> >> Lars >> >> Begin forwarded message: >> >>> From: "ext Steven M. Bellovin" >>> Date: October 2, 2008 16:31:29 GMT+03:00 >>> To: "Steven M. Bellovin" >>> Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman >>> , secdir@mit.edu, ietf@ietf.org >>> Subject: Re: Secdir Review of draft-stjohns-sipso-05 >>> >>> On Wed, 1 Oct 2008 22:12:17 -0400 >>> "Steven M. Bellovin" wrote: >>> >>>>> Steven> Note 7.3.1 on >>>>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>>>> Steven> with 793 on the treatment of security labels in section >>>>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>>>> >>>>> I had completely missed this. I'll call out the section to the >>>>> transport ADs >>>>> >>>> I should have added: I think the new document is in fact more >>>> correct >>>> than 793 -- the 793 scheme would permit various forms of >>>> high-bandwidth covert channels to be set up. This is an issue that >>>> was not nearly that well understood when 793 was written. That >>>> said, >>>> it is a change to TCP, and needs to be treated as such. >>>> >>> Thinking further -- I suspect that the right thing to do here is for >>> someone to write a short, simple draft amending 793 -- it's >>> handling of >>> the security option is simply wrong, independent of this draft. I >>> wonder -- what TCPs actually implement even 793? NetBSD doesn't; I >>> strongly suspect that no BSDs do. Does Solaris? Linux? >>> >>> --Steve Bellovin, http://www.cs.columbia.edu/~smb >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkjlA7UACgkQE5f5cImnZrszXQCeNkIxxBZUmEjidZBxwF5RMaDg > sgEAn3aoDE4kcBsV7kglGiXvKbRWZwK6 > =fiTu > -----END PGP SIGNATURE----- --Apple-Mail-7--147735105 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwMjE4MzY0MVowIwYJKoZI hvcNAQkEMRYEFN9WxIpN0ej+VIOfhrCYa1KkIBLiMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQBsHdkV2qRqS0rsdmTZ3ukfp5oR ARqE87m8ysq+ItBFI3ICMFPINuIZZQqfb8diJm3GDzr2+66CDwHWC79zvmqMomCsEclZ0aQxAZDi 8I09EkOeYK+1xzm4g0epZgj+uyhXT0bazsLV18smx7a7sTZXah863qfyXUGs6sImWefGk2nDOHO6 Bh2rSF110bDyVNagg6bx6N6lNcZ7zFlYCMxK4cG915S+2ugdU56aIV+y6DU9vTHPnioWyRhFMpDn 04g1Ac0MXrcKeIh69JRSyNoKmbcM+nhxi4ZK2hMuqTS6l+qQ0Y+VyEhtdDFzaTnhkNT9c6/M4YtH w+31AXlaAEKmAAAAAAAA --Apple-Mail-7--147735105-- --===============1658719807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1658719807==-- From tcpm-bounces@ietf.org Thu Oct 2 11:44:23 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD42228C134; Thu, 2 Oct 2008 11:44:23 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8424028C24B; Thu, 2 Oct 2008 11:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLwKc5hQH-yi; Thu, 2 Oct 2008 11:44:21 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9A1F23A68E1; Thu, 2 Oct 2008 11:44:21 -0700 (PDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92IhYOe023699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 11:43:37 -0700 (PDT) Message-ID: <48E51655.20207@isi.edu> Date: Thu, 02 Oct 2008 11:43:33 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: TSV Area , tcpm Extensions WG X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: [tcpm] [Fwd: Re: Secdir Review of draft-stjohns-sipso-05] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1729254784==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1729254784== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F8EDB48B92AB7E490E3185B" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F8EDB48B92AB7E490E3185B Content-Type: multipart/mixed; boundary="------------010101090309020704080105" This is a multi-part message in MIME format. --------------010101090309020704080105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI - discussion is happening over on the main list. Joe --------------010101090309020704080105 Content-Type: message/rfc822; name="Re: Secdir Review of draft-stjohns-sipso-05.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: Secdir Review of draft-stjohns-sipso-05.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m92IIgjU018501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 2 Oct 2008 11:18:44 -0700 (PDT) Received: from [75.215.151.23] (23.sub-75-215-151.myvzw.com [75.215.151.23]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m92IIHgC013898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 11:18:21 -0700 (PDT) Message-ID: <48E51069.1040403@isi.edu> Date: Thu, 02 Oct 2008 11:18:17 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Steven M. Bellovin" CC: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman , secdir@mit.edu, ietf@ietf.org Subject: Re: Secdir Review of draft-stjohns-sipso-05 References: <20080929170305.4740f779@cs.columbia.edu> <20081001221217.3921b69e@cs.columbia.edu> <20081002093129.5bb80658@cs.columbia.edu> In-Reply-To: <20081002093129.5bb80658@cs.columbia.edu> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean X-MailScanner-From: touch@isi.edu -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven M. Bellovin wrote: > On Wed, 1 Oct 2008 22:12:17 -0400 > "Steven M. Bellovin" wrote: > >>> Steven> Note 7.3.1 on >>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>> Steven> with 793 on the treatment of security labels in section >>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>> >>> I had completely missed this. I'll call out the section to the >>> transport ADs >>> >> I should have added: I think the new document is in fact more correct >> than 793 -- the 793 scheme would permit various forms of >> high-bandwidth covert channels to be set up. This is an issue that >> was not nearly that well understood when 793 was written. That said, >> it is a change to TCP, and needs to be treated as such. >> > Thinking further -- I suspect that the right thing to do here is for > someone to write a short, simple draft amending 793 -- it's handling of > the security option is simply wrong, independent of this draft. I > wonder -- what TCPs actually implement even 793? NetBSD doesn't; I > strongly suspect that no BSDs do. Does Solaris? Linux? First, I don't agree with this document's recommendation in section 7.3.1. TCP's current definition of a connection is: local IP address remote IP address local port remote port protocol (e.g., TCP) I don't agree that treating each sensitivity level as a separate virtual network (Sec 3 of this ID) is the appropriate analogy. If that were the case, we'd need to redefine every Internet protocol to understand the pair [address, sensitivity level] as an identifier, and that is not realistic. Further, if we did need to do such an extension, there are other equally (or arguably more) worthy candidates, notably VPN-ID. I.e., I don't think this needs to update 793 - it needs to redefine the Internet architecture in places like 1122, 1123, and 1812, and flow down through all protocols they impact to make this sort of change, and I don't see a reason to do so solely for this issue. Overall, I see no reason why 793's current rules aren't sufficient to emulate the desirable separation of sensitivity levels without extending this to true virtualization. I.e., the current rule (in 793, sec 3.6, paraphrased): - match the levels proposed by both ends of the connection where there is a mismatch, terminate the connection I.e., I don't see how to extend TCP to support concurrent connections with matching connection identifiers on different sensitivity levels without rearchitecting the entire Internet. AFAICT, it's sufficient to allow each TCP connection to have exactly one sensitivity level, as is already currently required. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlEGkACgkQE5f5cImnZruKoQCfZ9qnOBIRZTCNzsUWzfB39HdL AicAn1kLwAQdQ087x9H32tbdVK26t1Hq =8u6k -----END PGP SIGNATURE----- --------------010101090309020704080105-- --------------enig4F8EDB48B92AB7E490E3185B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlFlUACgkQE5f5cImnZrtr5QCfQfqdl/p465YyfWHWgTPA+1n4 9K0AoOz4xqeBXN+9F6/zxZAVk3CKx1Ac =+L4J -----END PGP SIGNATURE----- --------------enig4F8EDB48B92AB7E490E3185B-- --===============1729254784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1729254784==-- From tcpm-bounces@ietf.org Thu Oct 2 12:12:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4841A28C261; Thu, 2 Oct 2008 12:12:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CABCF28C261 for ; Thu, 2 Oct 2008 12:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVT+Abj-gsKr for ; Thu, 2 Oct 2008 12:12:50 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AEEC928C0EE for ; Thu, 2 Oct 2008 12:12:50 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m92JC3SD025781; Thu, 2 Oct 2008 12:12:03 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:12:03 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Oct 2008 12:12:02 -0700 Message-Id: <3FAB3E97-F849-46C8-B81E-22060D601D8D@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 2 Oct 2008 14:12:00 -0500 References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF435A@xmb-sjc-21c.amer.cisco.com><48E110DE.8050903@isi.edu><724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com><3B570CE3-309B-4473-9A19-99905A93986A@windriver.com> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 02 Oct 2008 19:12:03.0359 (UTC) FILETIME=[C0CB8AF0:01C924C2] Cc: =?ISO-8859-1?Q?Alfred_H=CEnes?= , Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At this point I count 5 for (Alfred, Anantha, Mitesh, Murali & = Stefanos) and 5 against (Lars, Joe, David, Wes & Ted). We have = conflicting interpretations of what "Updates" means; what is written = down in the RFC index and in RFC 2223, what as been done in practice, = and personal opinions. I don't see those converging on the TCPM = mailing list. So, whether or not "Updates: 793" is put into the = draft, this issue will be explicitly noted when it is sent up to the = IESG. -David Borman On Oct 1, 2008, at 2:33 PM, David Borman wrote: > Ok, Wes and I count four opinions against and two opinions for = > having "Updates: 793" in the header of tcpsecure. Unless other = > folks chime in, the resolution we see is: > > 1) "Updates: 793" is not put in the header of tcpsecure > 2) When we send tcpsecure up to the IESG, we will note this issue = > and the discussion, and if the IESG feels that is appropriate to = > have "Updates: 793" in the header, then it can be added in. > > We think everyone has been heard and understood, but don't see this = > conversation coming to full agreement. > > -David Borman & Wes Eddy, TCPM co-chairs > > > On Sep 30, 2008, at 5:03 PM, Joe Touch wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: >>>> -----Original Message----- >>>> From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] >>>> Sent: Tuesday, September 30, 2008 1:47 PM >>>> To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; >>>> tcpm@ietf.org >>>> Cc: Alfred H=CEnes; Mitesh Dalal (mdalal); randall@lakerest.net; >>>> ext Joe Touch >>>> Subject: RE: [tcpm] another review of draft-ietf-tcpm- = >>>> tcpsecure[-10] >>>> >>>> Wes, >>>> >>>>> >>>>> My personal opinion on the number of angels on the head of this >>>>> pin is that 3168 redefines bits that were formerly reserved. Thus >>>>> it "updates" the description of those bits in 793 (they're no = >>>>> longer >>>>> reserved). *Regardless* of the fact that 3168 is itself optional, >>>>> those bits are no longer available in the way 793 describes. = >>>>> *That* >>>>> is why it has to "update" even though it's optional itself. >>>>> >>>>> The tcpsecure document does not "update" in that sense, as it only >>>>> contains optional alternative state machine arcs; the arcs defined >>>>> in 793 are still able to be used in the way 793 describes ... they >>>>> aren't "updated", but there's now an alternative to them. >>>> Are you saying that we should construe that "alternate >>>> processing" doesn't update the RFC?. Now, the update itself >>>> can be optional. In other words, my point is that the current >>>> meaning and usage of "updates" is to be used for any updates >>>> to the RFC, irrespective of the fact it is minor, major or >>>> optional. Agreed that, currently there is fine granularity in >>>> describing an update i.e, "minor update, medium update or >>>> conditinal update " etc., until such a granularity is >>>> available, we should use the existing documented mechanisms. >>>> This is the reason I think it would be expedient to seek the >>>> advice of IESG in this matter. >>> >>> >>> My position is very simple: >>> What part of RFC 793 is no longer correct? Which text is no >>> longer accurate in RFC 793? >>> >>> With ECN, it's very clear, the answer is "the 2 reserved bits >>> are not reserved anymore". With tcpsecure, the answer is also >>> very clear: "nothing". You need to point to some part of 793 >>> that is actually updated and not just alternatively defined, >>> IMO. If 2581, 1323, and others don't update 793, then I don't >>> see how tcpsecure can have any valid claim to. >>> >>> That's just my personal opinion, though. >> >> >> This makes sense to me. >> >> Joe >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i >> 2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI >> =3Dq5ru >> -----END PGP SIGNATURE----- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 17:13:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404993A6ADD; Thu, 2 Oct 2008 17:13:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCCF53A68E0 for ; Thu, 2 Oct 2008 17:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zJg-uJdRYRH for ; Thu, 2 Oct 2008 17:13:37 -0700 (PDT) Received: from mail.ocarinanetworks.com (h-69-3-29-18.snvacaid.covad.net [69.3.29.18]) by core3.amsl.com (Postfix) with ESMTP id D62F23A6AEF for ; Thu, 2 Oct 2008 17:13:36 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 2 Oct 2008 17:13:54 -0700 From: Murali Bashyam To: John Heffner , David Borman Date: Thu, 2 Oct 2008 17:13:50 -0700 Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document Thread-Index: Ackiw1TZsuAj/be9Tea1xNDmnzYShwCKV4SA Message-ID: References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> In-Reply-To: <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: John Heffner [mailto:johnwheffner@gmail.com] > Sent: Monday, September 29, 2008 11:10 PM > To: David Borman > Cc: tcpm@ietf.org; Anantha Ramaiah (ananth); Murali Bashyam > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > On Fri, Sep 26, 2008 at 12:37 PM, David Borman > wrote: > > At Dublin a presentation was made on draft-ananth-tcpm-persist- > 00.txt. Not > > a lot of people had read the document at the time of the > presentation, but > > there didn't seem to be any objections to adopting it as a TCPM WG > document. > > > > The authors posted a summary to the mailing list, have responded to > all > > issues that were raised, and have a new version of the document ready > for > > publication. We (Wes and I) feel that there is support for adopting > this as > > a WG document, but as always, we need to verify this on the mailing > list. > > So, if you have any objections to adopting this as a WG document, > please > > speak up now. Also speak up if you support adopting it as a WG > document. > > > > I'll be the first to say I support adopting this as a WG document. > If there > > are no serious objections, the authors can submit their updated > version next > > week and Wes and I will add it to our list of WG documents. > > > I have reservations about moving forward with this draft as a wg > document. While the information is technically correct, it is overly > specific to the point of possibly being misleading rather than > clarifying. An operating system may terminate a tcp connection at any > time, not just when the connection is in the persist state. Further, > I would actually argue that terminating a connection *because* it's in > the persist state is a bad idea and should be discouraged. (The > reason for termination should be for its use of resources, not TCP's > state.) No implementation today (the well-known ones BSD, Windows and Linux) terminates the TCP connection in that persist state as long as ACKs are being reliably received from the peer. Those three implementations are not doing what you are saying they should be doing, and if it's crystal clear from the standard that they should be doing so, why aren't they? They are all following the letter of the standard (1122) which dictates that they MUST do so. Linux even has a comment in the code that says RFC 1122 prevents it from doing so. The *informational* document's goals are the following: - Clarify 1122's position on this sender behaviour. - Bring to light a consequence of persisting indefinitely, leading to a DoS vulnerability triggered easily by a user-space receiving application. The mitigation techniques for this are not going to be described in this doc, as discussed in the mailing list before. It's possible that some of the OS's existing techniques for mitigating resource exhaustion can already address this scenario, but that's out of scope of this document. - Expose the indefinite persisting behavior to allow the application to control that behavior and terminate the connection (possibly even when resources are available). Murali > > -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 17:55:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CD428C0D9; Thu, 2 Oct 2008 17:54:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077F83A6A77 for ; Thu, 2 Oct 2008 17:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tinkeW6eb+rN for ; Thu, 2 Oct 2008 17:54:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 28D0C3A6B0E for ; Thu, 2 Oct 2008 17:54:58 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m930snwF028768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 17:54:51 -0700 (PDT) Message-ID: <48E56D59.7010004@isi.edu> Date: Thu, 02 Oct 2008 17:54:49 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Murali Bashyam References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "Anantha Ramaiah \(ananth\)" , "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murali Bashyam wrote: ... >> I have reservations about moving forward with this draft as a wg >> document. While the information is technically correct, it is overly >> specific to the point of possibly being misleading rather than >> clarifying. An operating system may terminate a tcp connection at any >> time, not just when the connection is in the persist state. Further, >> I would actually argue that terminating a connection *because* it's in >> the persist state is a bad idea and should be discouraged. (The >> reason for termination should be for its use of resources, not TCP's >> state.) > > No implementation today (the well-known ones BSD, Windows and Linux) > terminates the TCP connection in that persist state as long as ACKs are > being reliably received from the peer. No OS I'm aware of cleans much of anything up when it runs out of space. They tend to just run out of space and silently hang or thrash incessently. The point is that an OS that wants to do this can. That's an OS implementation recommendation that I support - the question is whether such OS implementation issues are useful as RFCs. > Those three implementations are > not doing what you are saying they should be doing, and if it's crystal > clear from the standard that they should be doing so, why aren't they? The standard already says, IMO, that they MAY do this. Not that they MUST. The standard says nothing about what to do when you run out of resources to run the connections you're currently supporting - it says nothing about what to do when new connections arrive in that state either. Memory management is the OS's job, not the protocol's. > They are all following the letter of the standard (1122) which dictates > that they MUST do so. Linux even has a comment in the code that says RFC > 1122 prevents it from doing so. That's a great reason to: a) write code to enable this behavior in the OS's you want to fix b) correct the Linux comment This is all an OS implementation issue, not a protocol standards issue. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlbVkACgkQE5f5cImnZrs/fQCfYqFOdyjmg9aVMxyuMjY2eDZd svkAnjvVH/Rq5E93BOsp5A/ZzKv4LBjL =p3nQ -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 22:26:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2CF28C196; Thu, 2 Oct 2008 22:26:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B96E3A6975 for ; Thu, 2 Oct 2008 22:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TveQWC6uGsgA for ; Thu, 2 Oct 2008 22:26:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 13DD53A69D8 for ; Thu, 2 Oct 2008 22:26:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,354,1220227200"; d="scan'208";a="86243524" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Oct 2008 05:26:26 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m935QQ8V025934; Thu, 2 Oct 2008 22:26:26 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m935QQWC001121; Fri, 3 Oct 2008 05:26:26 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA28646; Thu, 2 Oct 2008 22:25:54 -0700 (PDT) Date: Thu, 2 Oct 2008 22:25:54 -0700 From: Chandrashekhar Appanna To: David Borman Message-ID: <20081003052554.GC19007@cisco.com> References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> Mime-Version: 1.0 In-Reply-To: <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4341; t=1223011587; x=1223875587; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=OIuhJoPymYNNIjj8ZgirzopJRSPm8utqLBa8Xrlcmg0=; b=hb+eSUDVpzukfSDLORm1hu4oV/XVIiQJ+YhJPeE05E17JSspfAoKrdRyWZ rrmKlsRIxu0A5Gdtp9M2DqRGy6LjIkwSSP/nuyPM8SA1bzsbTWD1zMmgUcHG /nnM5oZC/R; Authentication-Results: sj-dkim-4; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Alfred =?unknown-8bit?Q?H=CEnes?= , tcpm@ietf.org, Joe Touch , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0125140748==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0125140748== Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Oct 01, 2008 at 02:33:29PM -0500, David Borman wrote: > Ok, Wes and I count four opinions against and two opinions for having > "Updates: 793" in the header of tcpsecure. Unless other folks chime > in, the resolution we see is: > > 1) "Updates: 793" is not put in the header of tcpsecure > 2) When we send tcpsecure up to the IESG, we will note this issue and > the discussion, and if the IESG feels that is appropriate to have > "Updates: 793" in the header, then it can be added in. > My opinion is that since we believe these are 'good changes' and would expect newer code to follow these recomendataions, 'Updates' would be appropriate. (Off late, we, the IETF are so caught up in just defining words that it is hard to take a position on anything clearly :).. my choice is simply based on whether I will put this into code or not... I have no clue how the IESG may think and it seems that it will probably just 'veto' one of the choices, based on their wisdom, on this anyway) Regards, Chandra. > We think everyone has been heard and understood, but don't see this > conversation coming to full agreement. > > -David Borman & Wes Eddy, TCPM co-chairs > > > On Sep 30, 2008, at 5:03 PM, Joe Touch wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > > > >Eddy, Wesley M. (GRC-RCN0)[VZ] wrote: > >>>-----Original Message----- > >>>From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > >>>Sent: Tuesday, September 30, 2008 1:47 PM > >>>To: Eddy, Wesley M. (GRC-RCN0)[VZ]; David Borman; Lars Eggert; > >>>tcpm@ietf.org > >>>Cc: Alfred HÎnes; Mitesh Dalal (mdalal); randall@lakerest.net; > >>>ext Joe Touch > >>>Subject: RE: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] > >>> > >>>Wes, > >>> > >>>> > >>>>My personal opinion on the number of angels on the head of this > >>>>pin is that 3168 redefines bits that were formerly reserved. Thus > >>>>it "updates" the description of those bits in 793 (they're no > >>>>longer > >>>>reserved). *Regardless* of the fact that 3168 is itself optional, > >>>>those bits are no longer available in the way 793 describes. > >>>>*That* > >>>>is why it has to "update" even though it's optional itself. > >>>> > >>>>The tcpsecure document does not "update" in that sense, as it only > >>>>contains optional alternative state machine arcs; the arcs defined > >>>>in 793 are still able to be used in the way 793 describes ... they > >>>>aren't "updated", but there's now an alternative to them. > >>>Are you saying that we should construe that "alternate > >>>processing" doesn't update the RFC?. Now, the update itself > >>>can be optional. In other words, my point is that the current > >>>meaning and usage of "updates" is to be used for any updates > >>>to the RFC, irrespective of the fact it is minor, major or > >>>optional. Agreed that, currently there is fine granularity in > >>>describing an update i.e, "minor update, medium update or > >>>conditinal update " etc., until such a granularity is > >>>available, we should use the existing documented mechanisms. > >>>This is the reason I think it would be expedient to seek the > >>>advice of IESG in this matter. > >> > >> > >>My position is very simple: > >>What part of RFC 793 is no longer correct? Which text is no > >>longer accurate in RFC 793? > >> > >>With ECN, it's very clear, the answer is "the 2 reserved bits > >>are not reserved anymore". With tcpsecure, the answer is also > >>very clear: "nothing". You need to point to some part of 793 > >>that is actually updated and not just alternatively defined, > >>IMO. If 2581, 1323, and others don't update 793, then I don't > >>see how tcpsecure can have any valid claim to. > >> > >>That's just my personal opinion, though. > > > > > >This makes sense to me. > > > >Joe > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.9 (MingW32) > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > >iEYEARECAAYFAkjioioACgkQE5f5cImnZrvyfACgk+tXUy6Q1TdshUpvN9Zixv/i > >2FEAoNoBwdYFzVM+r0wokwbAaJKLJ3PI > >=q5ru > >-----END PGP SIGNATURE----- > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --===============0125140748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0125140748==-- From tcpm-bounces@ietf.org Thu Oct 2 22:30:37 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929053A69CE; Thu, 2 Oct 2008 22:30:37 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD22A3A69CE for ; Thu, 2 Oct 2008 22:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du4IcVr5yr0g for ; Thu, 2 Oct 2008 22:30:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EF2613A680E for ; Thu, 2 Oct 2008 22:30:35 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m935UToh018416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 22:30:31 -0700 (PDT) Message-ID: <48E5ADF6.9030501@isi.edu> Date: Thu, 02 Oct 2008 22:30:30 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Chandrashekhar Appanna References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <20081003052554.GC19007@cisco.com> In-Reply-To: <20081003052554.GC19007@cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: =?ISO-8859-1?Q?Alfred_=3F?= , tcpm@ietf.org, David Borman , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chandrashekhar Appanna wrote: > On Wed, Oct 01, 2008 at 02:33:29PM -0500, David Borman wrote: >> Ok, Wes and I count four opinions against and two opinions for having >> "Updates: 793" in the header of tcpsecure. Unless other folks chime >> in, the resolution we see is: >> >> 1) "Updates: 793" is not put in the header of tcpsecure >> 2) When we send tcpsecure up to the IESG, we will note this issue and >> the discussion, and if the IESG feels that is appropriate to have >> "Updates: 793" in the header, then it can be added in. >> > > My opinion is that since we believe these are 'good changes' and would > expect newer code to follow these recomendataions, 'Updates' would be > appropriate. That's exactly what I don't expect. I expect these mods to be deployed ONLY where necessary, not in all newer code, FWIW. The idea that this is generally useful is the kind of misperception I would like to avoid... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlrfUACgkQE5f5cImnZrtMsQCfYjyH2vnVgEteELEXV1G+w70Q seAAoIc23DQmZ8h88NRqdxmuWnD58vfa =DUXb -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 22:44:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4438D28C1A8; Thu, 2 Oct 2008 22:44:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6041528C18B for ; Thu, 2 Oct 2008 22:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kgmTCmAkVZc for ; Thu, 2 Oct 2008 22:44:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 22B6A28C196 for ; Thu, 2 Oct 2008 22:44:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,354,1220227200"; d="scan'208";a="91964464" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Oct 2008 05:45:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m935j5Qi019970; Thu, 2 Oct 2008 22:45:05 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m935j5jg021512; Fri, 3 Oct 2008 05:45:05 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA01506; Thu, 2 Oct 2008 22:44:37 -0700 (PDT) Date: Thu, 2 Oct 2008 22:44:36 -0700 From: Chandrashekhar Appanna To: Joe Touch Message-ID: <20081003054436.GD19007@cisco.com> References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <20081003052554.GC19007@cisco.com> <48E5ADF6.9030501@isi.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E5ADF6.9030501@isi.edu> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1875; t=1223012705; x=1223876705; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=0UQLKN1oZz6h/AmXG9jTiMYGYiUcxbvoAnrSWDavhoo=; b=Hi6HWAPoNwESEx3TaWzV1cCkTVeGnhtLaOK1iRD2r13q/iPlcwr60rC9P2 sH6BaxYI5S1wUFx3iSisDgENd78ytiv8XgO2ri/XUR1OzA2w/kOZLqIoKJD3 g11L+WPk1j; Authentication-Results: sj-dkim-3; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Alfred ? , tcpm@ietf.org, David Borman , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Oct 02, 2008 at 10:30:30PM -0700, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Chandrashekhar Appanna wrote: > > On Wed, Oct 01, 2008 at 02:33:29PM -0500, David Borman wrote: > >> Ok, Wes and I count four opinions against and two opinions for having > >> "Updates: 793" in the header of tcpsecure. Unless other folks chime > >> in, the resolution we see is: > >> > >> 1) "Updates: 793" is not put in the header of tcpsecure > >> 2) When we send tcpsecure up to the IESG, we will note this issue and > >> the discussion, and if the IESG feels that is appropriate to have > >> "Updates: 793" in the header, then it can be added in. > >> > > > > My opinion is that since we believe these are 'good changes' and would > > expect newer code to follow these recomendataions, 'Updates' would be > > appropriate. > > That's exactly what I don't expect. I expect these mods to be deployed > ONLY where necessary, not in all newer code, FWIW. The idea that this is > generally useful is the kind of misperception I would like to avoid... > Joe :) While I do notice that you embody 'TCPM', and the chairs are just window dressing I would prefer that you let us provide out opinions and not jump in to mischaracterize my words to your ends ;) I __did not__ say anthying to imply generally useful. But to _me_ code is key.. it may be that you are more interested in a purely academic angle which does not affect the 'working internet'.. now I am putting words in your mouth.. are'nt I? Regards, Chandra. > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkjlrfUACgkQE5f5cImnZrtMsQCfYjyH2vnVgEteELEXV1G+w70Q > seAAoIc23DQmZ8h88NRqdxmuWnD58vfa > =DUXb > -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 23:27:19 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5ADC3A6897; Thu, 2 Oct 2008 23:27:19 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F583A6897 for ; Thu, 2 Oct 2008 23:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV+Ypuq4-e8o for ; Thu, 2 Oct 2008 23:27:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 009693A685F for ; Thu, 2 Oct 2008 23:27:16 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m936RU61002108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Oct 2008 23:27:32 -0700 (PDT) Message-ID: <48E5BB51.4020204@isi.edu> Date: Thu, 02 Oct 2008 23:27:29 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Chandrashekhar Appanna References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <20081003052554.GC19007@cisco.com> <48E5ADF6.9030501@isi.edu> <20081003054436.GD19007@cisco.com> In-Reply-To: <20081003054436.GD19007@cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Alfred ? , tcpm@ietf.org, David Borman , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chandrashekhar Appanna wrote: > On Thu, Oct 02, 2008 at 10:30:30PM -0700, Joe Touch wrote: > > > Chandrashekhar Appanna wrote: >>>> On Wed, Oct 01, 2008 at 02:33:29PM -0500, David Borman wrote: >>>>> Ok, Wes and I count four opinions against and two opinions for having >>>>> "Updates: 793" in the header of tcpsecure. Unless other folks chime >>>>> in, the resolution we see is: >>>>> >>>>> 1) "Updates: 793" is not put in the header of tcpsecure >>>>> 2) When we send tcpsecure up to the IESG, we will note this issue and >>>>> the discussion, and if the IESG feels that is appropriate to have >>>>> "Updates: 793" in the header, then it can be added in. >>>>> >>>> My opinion is that since we believe these are 'good changes' and would >>>> expect newer code to follow these recomendataions, 'Updates' would be >>>> appropriate. > > That's exactly what I don't expect. I expect these mods to be deployed > ONLY where necessary, not in all newer code, FWIW. The idea that this is > generally useful is the kind of misperception I would like to avoid... > >> Joe :) > >> While I do notice that you embody 'TCPM', and the chairs are just >> window dressing I would prefer that you >> let us provide out opinions and not jump in to mischaracterize my >> words to your ends ;) > >> I __did not__ say anthying to imply generally useful. But to _me_ >> code is key.. it may be that you are more interested in a purely >> academic angle which does not affect the 'working internet'.. now >> I am putting words in your mouth.. are'nt I? The working Internet is composed of more than just routers - at least that's what I teach my students. ;-) You made the case that newer code would add this mod. That implies generality I think should be avoided. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlu1EACgkQE5f5cImnZrvbAwCgqeCmiyvqDR2lXcqAWec4HC1K fHkAoIPvQvgeatS0mam1LoSTRdEWiKry =xV9q -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 23:44:54 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240BD3A6A9E; Thu, 2 Oct 2008 23:44:54 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7BF3A6A73 for ; Thu, 2 Oct 2008 23:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QExkubpp8-6z for ; Thu, 2 Oct 2008 23:44:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0BAF83A69D2 for ; Thu, 2 Oct 2008 23:44:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,354,1220227200"; d="scan'208";a="167906258" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2008 06:44:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id m936iiDu019710; Thu, 2 Oct 2008 23:44:44 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m936iiR7003578; Fri, 3 Oct 2008 06:44:44 GMT Received: (from achandra@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA09629; Thu, 2 Oct 2008 23:44:16 -0700 (PDT) Date: Thu, 2 Oct 2008 23:44:16 -0700 From: Chandrashekhar Appanna To: Joe Touch Message-ID: <20081003064416.GF19007@cisco.com> References: <0C53DCFB700D144284A584F54711EC5805DF4A3C@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC5805DF4AE2@xmb-sjc-21c.amer.cisco.com> <48E2A22A.8000209@isi.edu> <986B5B70-4BD5-46EF-943C-DE588603CF6C@windriver.com> <20081003052554.GC19007@cisco.com> <48E5ADF6.9030501@isi.edu> <20081003054436.GD19007@cisco.com> <48E5BB51.4020204@isi.edu> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <48E5BB51.4020204@isi.edu> User-Agent: Mutt/1.4i DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2531; t=1223016284; x=1223880284; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=achandra@cisco.com; z=From:=20Chandrashekhar=20Appanna=20 |Subject:=20Re=3A=20[tcpm]=20another=20review=20of=20draft- ietf-tcpm-tcpsecure[-10] |Sender:=20; bh=FcWdUZynYRsd0kI/FPWB/9LCGuFfj6Fu2y6KNPveidg=; b=mtBP7jCPKsZpg3+L25dmrDOnkbUKJwDeX2BTd+It2Ai65ZuWocjYzbazjY i3bWL6kELtS2N1Pw6D7/LgVYqRD0dG7kC18Dy+JfhqrpcYg4mcQJOU1UR8q9 PVUSmDZvFZ; Authentication-Results: sj-dkim-5; header.From=achandra@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); Cc: Alfred ? , tcpm@ietf.org, David Borman , "Anantha Ramaiah \(ananth\)" , Randy Stewart , "Mitesh Dalal \(mdalal\)" , "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Thu, Oct 02, 2008 at 11:27:29PM -0700, Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Chandrashekhar Appanna wrote: > > On Thu, Oct 02, 2008 at 10:30:30PM -0700, Joe Touch wrote: > > > > > > Chandrashekhar Appanna wrote: > >>>> On Wed, Oct 01, 2008 at 02:33:29PM -0500, David Borman wrote: > >>>>> Ok, Wes and I count four opinions against and two opinions for having > >>>>> "Updates: 793" in the header of tcpsecure. Unless other folks chime > >>>>> in, the resolution we see is: > >>>>> > >>>>> 1) "Updates: 793" is not put in the header of tcpsecure > >>>>> 2) When we send tcpsecure up to the IESG, we will note this issue and > >>>>> the discussion, and if the IESG feels that is appropriate to have > >>>>> "Updates: 793" in the header, then it can be added in. > >>>>> > >>>> My opinion is that since we believe these are 'good changes' and would > >>>> expect newer code to follow these recomendataions, 'Updates' would be > >>>> appropriate. > > > > That's exactly what I don't expect. I expect these mods to be deployed > > ONLY where necessary, not in all newer code, FWIW. The idea that this is > > generally useful is the kind of misperception I would like to avoid... > > > >> Joe :) > > > >> While I do notice that you embody 'TCPM', and the chairs are just > >> window dressing I would prefer that you > >> let us provide out opinions and not jump in to mischaracterize my > >> words to your ends ;) > > > >> I __did not__ say anthying to imply generally useful. But to _me_ > >> code is key.. it may be that you are more interested in a purely > >> academic angle which does not affect the 'working internet'.. now > >> I am putting words in your mouth.. are'nt I? > > The working Internet is composed of more than just routers - at least > that's what I teach my students. ;-) > Well.. good I guess ;) > You made the case that newer code would add this mod. That implies > generality I think should be avoided. > When I have some time, I will think through what you think I must have meant but for now.. My opinion as written stands and is directed to the chairs for the question they posed. Chandra. > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkjlu1EACgkQE5f5cImnZrvbAwCgqeCmiyvqDR2lXcqAWec4HC1K > fHkAoIPvQvgeatS0mam1LoSTRdEWiKry > =xV9q > -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 2 23:51:14 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEBCB3A68A4; Thu, 2 Oct 2008 23:51:14 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4851B3A68A4 for ; Thu, 2 Oct 2008 23:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrFX-ye48z7U for ; Thu, 2 Oct 2008 23:51:12 -0700 (PDT) Received: from mail.ocarinanetworks.com (h-69-3-29-18.snvacaid.covad.net [69.3.29.18]) by core3.amsl.com (Postfix) with ESMTP id 6569D3A6359 for ; Thu, 2 Oct 2008 23:51:12 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 2 Oct 2008 23:51:40 -0700 From: Murali Bashyam To: Joe Touch Date: Thu, 2 Oct 2008 23:51:36 -0700 Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document Thread-Index: Ackk8uIft0ji+b9hTs6lCfKLxGKRlQAMDaPg Message-ID: References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <48E56D59.7010004@isi.edu> In-Reply-To: <48E56D59.7010004@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: David Borman , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Thursday, October 02, 2008 5:55 PM > To: Murali Bashyam > Cc: Anantha Ramaiah (ananth); tcpm@ietf.org; David Borman > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Murali Bashyam wrote: > ... > >> I have reservations about moving forward with this draft as a wg > >> document. While the information is technically correct, it is > overly > >> specific to the point of possibly being misleading rather than > >> clarifying. An operating system may terminate a tcp connection at > any > >> time, not just when the connection is in the persist state. > Further, > >> I would actually argue that terminating a connection *because* it's > in > >> the persist state is a bad idea and should be discouraged. (The > >> reason for termination should be for its use of resources, not TCP's > >> state.) > > > > No implementation today (the well-known ones BSD, Windows and Linux) > > terminates the TCP connection in that persist state as long as ACKs > are > > being reliably received from the peer. > > No OS I'm aware of cleans much of anything up when it runs out of > space. > They tend to just run out of space and silently hang or thrash > incessently. > > The point is that an OS that wants to do this can. That's an OS > implementation recommendation that I support - the question is whether > such OS implementation issues are useful as RFCs. > > > Those three implementations are > > not doing what you are saying they should be doing, and if it's > crystal > > clear from the standard that they should be doing so, why aren't > they? > > The standard already says, IMO, that they MAY do this. Not that they > MUST. The standard says nothing about what to do when you run out of > resources to run the connections you're currently supporting - it says > nothing about what to do when new connections arrive in that state > either. Memory management is the OS's job, not the protocol's. Which standard are u referring to? I'm quoting from RFC 1122, page 91 the section on probing zero windows : "As long as the receiving TCP continues to send acknowledgments in response to the Probe segments, the sending TCP MUST allow the connection to stay open." Can you point me to the word "MAY" in that sentence that you are referring to? The important thing here is to clarify that sentence and the sender's behaviour and prevent what appears to be a conflict between memory management and protocol violation. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkjlbVkACgkQE5f5cImnZrs/fQCfYqFOdyjmg9aVMxyuMjY2eDZd > svkAnjvVH/Rq5E93BOsp5A/ZzKv4LBjL > =p3nQ > -----END PGP SIGNATURE----- > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 3 00:20:49 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2253A6975; Fri, 3 Oct 2008 00:20:49 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8993A686A for ; Fri, 3 Oct 2008 00:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTkHeUt3b88C for ; Fri, 3 Oct 2008 00:20:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 13ED03A6A59 for ; Fri, 3 Oct 2008 00:20:38 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m937JaTA016803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 00:19:38 -0700 (PDT) Message-ID: <48E5C788.60005@isi.edu> Date: Fri, 03 Oct 2008 00:19:36 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Murali Bashyam References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <48E56D59.7010004@isi.edu> In-Reply-To: X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: David Borman , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Murali Bashyam wrote: ... > The standard already says, IMO, that they MAY do this. Not that they > MUST. The standard says nothing about what to do when you run out of > resources to run the connections you're currently supporting - it says > nothing about what to do when new connections arrive in that state > either. Memory management is the OS's job, not the protocol's. > >> Which standard are u referring to? I'm quoting from RFC 1122, page 91 >> the section on probing zero windows : > >> "As long as the receiving TCP continues to send acknowledgments in response to the >> Probe segments, the sending TCP MUST allow the connection to stay open." >> >> Can you point me to the word "MAY" in that sentence that you are referring to? It's implied by the conditional. I.e., if the receiving TCP stops sending ACKs, the sending TCP can drop the connection. As to the sending side, there's the ABORT call in 793 - which we discussed on this list before. The point is that _TCP_ can't decide to stop the connection because of the TCP state of the other end, the local TCP state, or behavior on the wire. Nothing in 793 says that the OS can't kill the connection - any connection - at any time. >> The important thing here is to clarify that sentence and the sender's behaviour >> and prevent what appears to be a conflict between memory management and protocol violation. Please describe anywhere in 1122 or 793 where memory management is described. As I've noted before, this isn't a protocol violation - it's a failure of an OS to support arbitrary numbers of instances of a protocol. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjlx4cACgkQE5f5cImnZrvVIACgy317tNIROKQF8JMq1b3osIEc 4bkAoNG6gnVh3RQ3ZXGe0nStL3ot2QVY =plLF -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 3 02:46:40 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4070D3A6B46; Fri, 3 Oct 2008 02:46:40 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F8463A6AF4 for ; Fri, 3 Oct 2008 02:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPwHCAcV5+Su for ; Fri, 3 Oct 2008 02:46:37 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 679C13A69DA for ; Fri, 3 Oct 2008 02:46:37 -0700 (PDT) X-Trace: 89108581/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.122.214 X-SBRS: None X-RemoteIP: 62.188.122.214 X-IP-MAIL-FROM: nwnetworks@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAEADqH5Ug+vHrW/2dsb2JhbACDUjqIZq8EA4FlgyA X-IronPort-AV: E=Sophos;i="4.33,356,1220223600"; d="scan'208";a="89108581" X-IP-Direction: IN Received: from 1cust214.tnt30.lnd3.gbr.da.uu.net (HELO allison) ([62.188.122.214]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Oct 2008 10:46:51 +0100 Message-ID: <008601c92533$88781260$0601a8c0@allison> From: "Tom Petch" To: "Lars Eggert" , "ext Joe Touch" References: <200808140650.IAA05627@TR-Sys.de> <0C53DCFB700D144284A584F54711EC5805DF435A@xmb-sjc-21c.amer.cisco.com><48E110DE.8050903@isi.edu> <724ED3DF-B4E5-4FF8-93BF-5B84688CC940@nokia.com> Date: Fri, 3 Oct 2008 10:20:59 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= , tcpm@ietf.org, "ext Anantha Ramaiah \(ananth\)" , rrs@cisco.com, "Mitesh Dalal \(mdalal\)" Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Tom Petch List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Trouble is, the long-standing precedent is not to specify 'Updates: 793' Underlying that, the update tree (mesh?) for TCP is so complex that it needs another representation, such as RFC4614 so perhaps 'Updates: 4614'; or RFC4614bis before too long? Tom Petch ----- Original Message ----- From: "Lars Eggert" To: "ext Joe Touch" Cc: "Alfred H=CEnes" ; ; "ext Anantha Ramaiah (ananth)" ; ; "Mitesh Dalal (mdalal)" Sent: Tuesday, September 30, 2008 11:43 AM Subject: Re: [tcpm] another review of draft-ietf-tcpm-tcpsecure[-10] > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 3 11:38:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D4D28C0E9; Fri, 3 Oct 2008 11:38:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B5328C0E9 for ; Fri, 3 Oct 2008 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x93FTdEY6shK for ; Fri, 3 Oct 2008 11:38:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 30C733A6986 for ; Fri, 3 Oct 2008 11:38:00 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m93IbRdb018334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 11:37:27 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m93IbQft029944; Fri, 3 Oct 2008 11:37:26 -0700 (PDT) (envelope-from faber) Date: Fri, 3 Oct 2008 11:37:26 -0700 From: Ted Faber To: Murali Bashyam Message-ID: <20081003183726.GD27519@zod.isi.edu> References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: "Anantha Ramaiah \(ananth\)" , "tcpm@ietf.org" , David Borman Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0934646697==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0934646697== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UfEAyuTBtIjiZzX6" Content-Disposition: inline --UfEAyuTBtIjiZzX6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I don't mean to be answering from John, but your comments interested me. On Thu, Oct 02, 2008 at 05:13:50PM -0700, Murali Bashyam wrote: >=20 > > From: John Heffner [mailto:johnwheffner@gmail.com] > > I have reservations about moving forward with this draft as a wg > > document. While the information is technically correct, it is overly > > specific to the point of possibly being misleading rather than > > clarifying. An operating system may terminate a tcp connection at any > > time, not just when the connection is in the persist state. Further, > > I would actually argue that terminating a connection *because* it's in > > the persist state is a bad idea and should be discouraged. (The > > reason for termination should be for its use of resources, not TCP's > > state.) >=20 > No implementation today (the well-known ones BSD, Windows and Linux) > terminates the TCP connection in that persist state as long as ACKs > are being reliably received from the peer. Those three implementations > are not doing what you are saying they should be doing, and if it's > crystal clear from the standard that they should be doing so, why > aren't they? Your comment is a little ambiguous. John says that he believes that persist state is not necessarily a good marker for aborting connections when resources are scarce. To take him to task because implementations are not using it as a marker - because the implementers agreed with his position - is a little unfair, IMHO. On the WG item: As a bigger picture issue, I find it helpful to remember that protocol standards, like 1122, are primarily interoperation documents. As such, they tend to focus on what protocol implementers must do to talk with one another successfully, not to nail down all possible choices. Once we start offering advice (or stronger) to developers, we're leaving the interoperability domain. We, as a standards body, have to assume that implementers know their application and their environment better than we do, and that they can and will make appropriate decisions if we give them the room to do so. Where a standard has unnecessarily tied the hands of implementers, that standard should be changed, IMHO. I am also sympathetic to clarifying the standards body's intent where poor language has obscured it. I don't see that kind of confusion in the text the authors are addressing (that is RFC 1122 Section 4.2.2.17), but reasonable people can disagree on such things. As such, taking on this work item - clarifying 1122 4.2.2.17 - doesn't excite me, but I don't oppose it. The draft should, IMHO, point out that 1122 has nothing to say about resource management. Designers and implementers are free to be as clever or foolish as they'd like. End of thoughts on the WG item. As for the draft itself, I'm concerned that it seems to be advocating a particular resource management position more strongly than simply pointing out that RFC1122 should not affect resource allocation decisions. I also see some misplaced standards language that is somewhat confusing. I'm looking at this paragraph in Section 2: An extensive discussion took place recently about this issue on the TCPM WG mailing list [TCPM]. The general opinion seemed to be that terminating a TCP connection in persist condition does not violate RFC 1122. In particular the operating system, a resource manager, or an application can instruct TCP to abort a connection in the persist condition. TCP itself SHOULD not take any action and continue to keep the connection open as mandated by RFC 1122 unless otherwise instructed to do so. The exact mechanism by which the instruction to abort the connection is conveyed to TCP is an implementation decision and falls beyond the scope of the current memo.=20 There's no instruction going on, and one doesn't request an abort. Abort is a command in the TCP interface (defined in RFC 793, p. 50) that destroys a TCP connection. Abort works in any state. Anything with access to the TCP interface, including the OS, a resource manager, or an application, can call it. A TCP abort is "the exact mechanism by which the instruction to abort the connection is conveyed to TCP", and the only reason that it's outside the scope of this document is that it's defined in 793. In light of that I think that the sentence about "TCP itself SHOULD not[sic] take any action..." is more confusing than the 1122 section. It seems to imply that TCP might react differently to an abort than the single paragraph in 793, and I don't think that's the case. Now, a strictly defined abort command seems to somewhat contradict my earlier comments about allowing implementers some freedom. This is a spot where the standards body has required a specific tool to be available to applications (and OSes and resource managers): there must be a way to annihilate a TCP connection from outside without regard to its state or anything else. The standard is silent about how the command is used; that's the flexibility here. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --UfEAyuTBtIjiZzX6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjmZmYACgkQaUz3f+Zf+XvJuwCeKbo8STe9Ryj5Lr5egqlnBB9r h90AnR8ujJF7tMUGWQLTI6L3xcWO6pU4 =Oojd -----END PGP SIGNATURE----- --UfEAyuTBtIjiZzX6-- --===============0934646697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0934646697==-- From tcpm-bounces@ietf.org Fri Oct 3 12:36:45 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A423A6A07; Fri, 3 Oct 2008 12:36:45 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F5553A6859 for ; Fri, 3 Oct 2008 12:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsHNSmNTqB5b for ; Fri, 3 Oct 2008 12:36:42 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id F2E403A67FD for ; Fri, 3 Oct 2008 12:36:41 -0700 (PDT) Received: by gxk9 with SMTP id 9so3078804gxk.13 for ; Fri, 03 Oct 2008 12:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=UuaeG/pEfT6QqxQoKZaDxsjD8SHiOOml/QnYXRJ88Zg=; b=W1I6y5zrScJ3yJD5XIXLx8K3RL3wWABT++OYfnvrkwYU5YfTLCvkcNYB/GjY83BdMV m6E8kD1fxTKVLZSy1I2ZlGPvkHfr7Ree7ZagQz/foCV11VjbOPeqmJJgjJLuSrUgU3Il bW0fZirOYow2A1v4J9KA/E24ptNrXtFe48ubQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TTMVrrtXa+6Uq17/xTrQMiGSY0vawNLD9lCNLRq/1YKgSm/cJbf/x/ivJIXK0NJFCh ERwGR2WCAcK+i4kohnkGDdt5TVl6oKbwMUs/Nj2AK850wyz9qZpTbik146cfqx1bO8wi iOQrZIM5OoIsbw2HIwKGR5agi5FB04/ULMTic= Received: by 10.142.48.14 with SMTP id v14mr530369wfv.133.1223062630563; Fri, 03 Oct 2008 12:37:10 -0700 (PDT) Received: by 10.142.116.4 with HTTP; Fri, 3 Oct 2008 12:37:10 -0700 (PDT) Message-ID: <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> Date: Fri, 3 Oct 2008 12:37:10 -0700 From: "Murali Bashyam" To: "Ted Faber" In-Reply-To: <20081003183726.GD27519@zod.isi.edu> MIME-Version: 1.0 References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> Cc: David Borman , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Murali Bashyam Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1601036274==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1601036274== Content-Type: multipart/alternative; boundary="----=_Part_19981_23298380.1223062630552" ------=_Part_19981_23298380.1223062630552 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, Oct 3, 2008 at 11:37 AM, Ted Faber wrote: > I don't mean to be answering from John, but your comments interested me. > > On Thu, Oct 02, 2008 at 05:13:50PM -0700, Murali Bashyam wrote: > > > > > From: John Heffner [mailto:johnwheffner@gmail.com] > > > I have reservations about moving forward with this draft as a wg > > > document. While the information is technically correct, it is overly > > > specific to the point of possibly being misleading rather than > > > clarifying. An operating system may terminate a tcp connection at any > > > time, not just when the connection is in the persist state. Further, > > > I would actually argue that terminating a connection *because* it's in > > > the persist state is a bad idea and should be discouraged. (The > > > reason for termination should be for its use of resources, not TCP's > > > state.) > > > > No implementation today (the well-known ones BSD, Windows and Linux) > > terminates the TCP connection in that persist state as long as ACKs > > are being reliably received from the peer. Those three implementations > > are not doing what you are saying they should be doing, and if it's > > crystal clear from the standard that they should be doing so, why > > aren't they? > > Your comment is a little ambiguous. John says that he believes that > persist state is not necessarily a good marker for aborting connections > when resources are scarce. To take him to task because implementations > are not using it as a marker - because the implementers agreed with > his position - is a little unfair, IMHO. My intent was that even where TCP implementations have a scheme for dropping connections in the event of resource exhaustion (such as the Linux one does), they have excluded connections in this state. The point i am trying to convey is that the 1122 portion has (mis)guided them in that direction. > > On the WG item: > > As a bigger picture issue, I find it helpful to remember that > protocol standards, like 1122, are primarily interoperation documents. > As such, they tend to focus on what protocol implementers must do to > talk with one another successfully, not to nail down all possible > choices. > > Once we start offering advice (or stronger) to developers, we're leaving > the interoperability domain. We, as a standards body, have to assume > that implementers know their application and their environment better > than we do, and that they can and will make appropriate decisions if we > give them the room to do so. > > Where a standard has unnecessarily tied the hands of implementers, that > standard should be changed, IMHO. I am also sympathetic to clarifying > the standards body's intent where poor language has obscured it. I > don't see that kind of confusion in the text the authors are addressing > (that is RFC 1122 Section 4.2.2.17), but reasonable people can disagree > on such things. > > As such, taking on this work item - clarifying 1122 4.2.2.17 - doesn't > excite me, but I don't oppose it. > > The draft should, IMHO, point out that 1122 has nothing to say about > resource management. Designers and implementers are free to be as > clever or foolish as they'd like. I agree, the primary intention of this draft is not to restrict or present any resource management schemes, it's to clarify 1122. In addition, we are trying to highlight the need for resource management in this scenario because it leads upto a DoS potential. > > > End of thoughts on the WG item. > > As for the draft itself, I'm concerned that it seems to be advocating a > particular resource management position more strongly than simply > pointing out that RFC1122 should not affect resource allocation > decisions. I also see some misplaced standards language that is > somewhat confusing. I'm looking at this paragraph in Section 2: > > > An extensive discussion took place recently about this issue on > the TCPM WG mailing list [TCPM]. The general opinion seemed to > be that terminating a TCP connection in persist condition does > not violate RFC 1122. In particular the operating system, a > resource manager, or an application can instruct TCP to abort a > connection in the persist condition. TCP itself SHOULD not take > any action and continue to keep the connection open as mandated > by RFC 1122 unless otherwise instructed to do so. The exact > mechanism by which the instruction to abort the connection is > conveyed to TCP is an implementation decision and falls beyond > the scope of the current memo. > > There's no instruction going on, and one doesn't request an abort. > Abort is a command in the TCP interface (defined in RFC 793, p. 50) that > destroys a TCP connection. Abort works in any state. Anything with > access to the TCP interface, including the OS, a resource manager, or an > application, can call it. A TCP abort is "the exact mechanism by which > the instruction to abort the connection is conveyed to TCP", and the > only reason that it's outside the scope of this document is that it's > defined in 793. > > > In light of that I think that the sentence about "TCP itself SHOULD > not[sic] take any action..." is more confusing than the 1122 section. > It seems to imply that TCP might react differently to an abort than > the single paragraph in 793, and I don't think that's the case. What's meant here is that it's okay for the connection to get aborted in this state, whatever the mechanism for doing so maybe: TCP can abort the connection and inform the application, similar to the retransmit/persist timeout mechanisms already in place, or the application can choose to abort the connection based policy, or the OS can do so based on resource management criteria. We can re-word that sentence and paragraph to reflect this. > > > Now, a strictly defined abort command seems to somewhat contradict my > earlier comments about allowing implementers some freedom. This is a > spot where the standards body has required a specific tool to be > available to applications (and OSes and resource managers): there must > be a way to annihilate a TCP connection from outside without regard to > its state or anything else. The standard is silent about how the > command is used; that's the flexibility here. The abort semantics as specified by 793 are clear, they are not specific to a particular state, it's the opinion of the authors that 1122 excludes it from being applied in this state. Murali > > > -- > Ted Faber > http://www.isi.edu/~faber PGP: > http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See > http://www.isi.edu/~faber/FAQ.html#SIG > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- Rgds, Murali Bashyam (c) (510)6736915 ----------------------------- CONFIDENTIAL -------------------- ***************************************************** This telecommunication and any data attached to, or included in it is considered confidential, and is intended only for use by the named recipient. The contents may be legally protected as any one or more of: copyrighted material, trade-secret protected material, attorney-client privileged material, attorney workproduct, or as material covered by any other legally available means. If you received this material in error, please notify the sender and destroy the original and all copies, whether electronic or otherwise. Thank you. ***************************************************** ------------------------------ CONFIDENTIAL -------------------- ------=_Part_19981_23298380.1223062630552 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


On Fri, Oct 3, 2008 at 11:37 AM, Ted Faber <faber@isi.edu> wrote:
I don't mean to be answering from John, but your comments interested me.

On Thu, Oct 02, 2008 at 05:13:50PM -0700, Murali Bashyam wrote:
>
> > From: John Heffner [mailto:johnwheffner@gmail.com]
> > I have reservations about moving forward with this draft as a wg
> > document.  While the information is technically correct, it is overly
> > specific to the point of possibly being misleading rather than
> > clarifying.  An operating system may terminate a tcp connection at any
> > time, not just when the connection is in the persist state.  Further,
> > I would actually argue that terminating a connection *because* it's in
> > the persist state is a bad idea and should be discouraged.  (The
> > reason for termination should be for its use of resources, not TCP's
> > state.)
>
> No implementation today (the well-known ones BSD, Windows and Linux)
> terminates the TCP connection in that persist state as long as ACKs
> are being reliably received from the peer. Those three implementations
> are not doing what you are saying they should be doing, and if it's
> crystal clear from the standard that they should be doing so, why
> aren't they?

Your comment is a little ambiguous.  John says that he believes that
persist state is not necessarily a good marker for aborting connections
when resources are scarce.  To take him to task because implementations
are not using it as a marker - because the implementers agreed with
his position - is a little unfair, IMHO.

My intent was that even where TCP implementations have a scheme for  dropping connections in the event
of resource exhaustion (such as the Linux one does), they have excluded connections in this state.
The point i am trying to convey is that the 1122 portion has (mis)guided them in that direction.



On the WG item:

As a bigger picture issue, I find it helpful to remember that
protocol standards, like 1122, are primarily interoperation documents.
As such, they tend to focus on what protocol implementers must do to
talk with one another successfully, not to nail down all possible
choices.

Once we start offering advice (or stronger) to developers, we're leaving
the interoperability domain.  We, as a standards body, have to assume
that implementers know their application and their environment better
than we do, and that they can and will make appropriate decisions if we
give them the room to do so.

Where a standard has unnecessarily tied the hands of implementers, that
standard should be changed, IMHO.  I am also sympathetic to clarifying
the standards body's intent where poor language has obscured it.  I
don't see that kind of confusion in the text the authors are addressing
(that is RFC 1122 Section 4.2.2.17), but reasonable people can disagree
on such things.

As such, taking on this work item - clarifying 1122 4.2.2.17 - doesn't
excite me, but I don't oppose it.

The draft should, IMHO, point out that 1122 has nothing to say about
resource management.  Designers and implementers are free to be as
clever or foolish as they'd like.

I agree, the primary intention of this draft is not to restrict or present any resource management schemes, it's to clarify 1122.
In addition,  we are trying to highlight the need for resource management in this scenario because it leads upto a DoS potential.
 


End of thoughts on the WG item.

As for the draft itself, I'm concerned that it seems to be advocating a
particular resource management position more strongly than simply
pointing out that RFC1122 should not affect resource allocation
decisions.  I also see some misplaced standards language that is
somewhat confusing.  I'm looking at this paragraph in Section 2:


       An extensive discussion took place recently about this issue on
       the TCPM WG mailing list [TCPM].  The general opinion seemed to
       be that terminating a TCP connection in persist condition does
       not violate RFC 1122.  In particular the operating system, a
       resource manager, or an application can instruct TCP to abort a
       connection in the persist condition.  TCP itself SHOULD not take
       any action and continue to keep the connection open as mandated
       by RFC 1122 unless otherwise instructed to do so.  The exact
       mechanism by which the instruction to abort the connection is
       conveyed to TCP is an implementation decision and falls beyond
       the scope of the current memo.

There's no instruction going on, and one doesn't request an abort.
Abort is a command in the TCP interface (defined in RFC 793, p. 50) that
destroys a TCP connection.  Abort works in any state.  Anything with
access to the TCP interface, including the OS, a resource manager, or an
application, can call it.  A TCP abort is "the exact mechanism by which
the instruction to abort the connection is conveyed to TCP", and the
only reason that it's outside the scope of this document is that it's
defined in 793.


In light of that I think that the sentence about "TCP itself SHOULD
not[sic] take any action..." is more confusing than the 1122 section.
It seems to imply that TCP might react differently to an abort than
the single paragraph in 793, and I don't think that's the case.
 
What's meant here is that it's okay for the connection to get aborted in this state, whatever the mechanism for doing
so maybe: TCP can abort the connection and inform the application, similar to the retransmit/persist timeout mechanisms
already in place, or the application can choose to abort the connection based policy, or the OS can do so based
on resource management criteria. We can re-word that sentence and paragraph to reflect this.


Now, a strictly defined abort command seems to somewhat contradict my
earlier comments about allowing implementers some freedom.  This is a
spot where the standards body has required a specific tool to be
available to applications (and OSes and resource managers): there must
be a way to annihilate a TCP connection from outside without regard to
its state or anything else.  The standard is silent about how the
command is used; that's the flexibility here.

The abort semantics as specified by 793 are clear, they are not specific to a particular state, it's the opinion
of the authors that 1122 excludes it from being applied in this state.

Murali




--
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm




--
Rgds,
Murali Bashyam
(c) (510)6736915

----------------------------- CONFIDENTIAL  --------------------
*****************************************************
This telecommunication and any data attached to, or included in it
is considered confidential, and is intended only for use by the named
recipient. The contents may be legally protected as any one or more of:
copyrighted material, trade-secret protected material, attorney-client
privileged material, attorney workproduct, or as material covered by
any other legally available means. If you received this material in
error, please notify the sender and destroy the original and all copies,
whether electronic or otherwise. Thank you.
*****************************************************
------------------------------ CONFIDENTIAL  --------------------
------=_Part_19981_23298380.1223062630552-- --===============1601036274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1601036274==-- From tcpm-bounces@ietf.org Fri Oct 3 13:04:51 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A41828C156; Fri, 3 Oct 2008 13:04:51 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CC6528C15E for ; Fri, 3 Oct 2008 13:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.662 X-Spam-Level: X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+88wVMIJ4ac for ; Fri, 3 Oct 2008 13:04:49 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 146B128C142 for ; Fri, 3 Oct 2008 13:04:48 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m93K4kYg027628; Fri, 3 Oct 2008 13:04:46 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 13:03:51 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 13:03:50 -0700 Message-Id: <8A476817-02C8-426D-B7FD-67C4791E2702@windriver.com> From: David Borman To: tcpm@ietf.org In-Reply-To: <20081003183726.GD27519@zod.isi.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 15:03:45 -0500 References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 03 Oct 2008 20:03:51.0101 (UTC) FILETIME=[279116D0:01C92593] Cc: Ted Faber , "Anantha Ramaiah \(ananth\)" , Murali Bashyam Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org (WG co-chair hat off) First, I agree with everything that Ted said. It might be helpful in this discussion to know why the wording on connections in persist state was put into RFC 1122 in the first place. Everything that is in 1122 and 1123 is in there for a reason, whether or not that reason is included in the document. In the case of connections in persist state, my fuzzy recollection was that there were TCP implementations that were timing out and terminating TCP connections stuck in persist state, the same way that they timed out and terminated non-responsive connections. An example scenario where this is bad is if you have TCP connection open to a printer, and the printer has stopped accepting data because it is waiting for someone to load more paper; you don't want TCP arbitrarily timing out and closing that connection, just because the printer can't accept any more data. The printer might sit without paper for a couple of hours over a long lunch break, or overnight, and once someone comes back and reloads paper, the printer should be able to continue receiving data on TCP connection, and continue printing where it left off. That's an example of why RFC 1122 explicitly calls out keeping connections in persist state open, and is also an example of why *TCP* does not have enough information by itself to decide to shut down a connection in persist state. I do understand that in many TCP stacks, you can create a TCP socket, write a bunch of data and close the socket, and TCP will keep the state and data, and continue to send the queued up data. If the connection goes into persist state, there is no longer an application associated with the socket to say this is taking to long and abort the connection, hence as long as the other side responds to the probes, the state & data stay around. But terminating that connection is an OS implementation issue of how to reclaim data when the system is out of resources. If it decides to abort existing TCP connections, it could choose to abort first those connections in persist state where the application has closed the socket. Or it might have some other criteria. And in terms of the protocol definition, as Ted points out, the way you do that is with an ABORT. Perhaps the OS should provide an interface to abort arbitrary TCP connections, so that the sys admin can kill off any TCP connection. But that is all implementation details, it has nothing to do with how the TCP protocol operates. If the other side is being malicious, it can just as easily acknowledge one byte of data every so often to keep the connection from staying perpetually in persist state, effectively defeating any remediation based on looking at how long a connection has been in persist state. So, the connection is making progress now, but slowly. So do we now need to call out how to deal with connections that are stuck with very slow progress, in addition to those that are making no progress? It's a slippery slope. It might be useful in the draft to note that this is just one specific example of how a malicious client can tie up resources on the server, and that the server application or OS is perfectly free to terminate any TCP connection in any state for any reason, and that a connection stuck in in persist state is just one example. My personal feeling is that there isn't a problem here that is crying out to be documented, it is an implementation issue of how to deal with a lack of resources. On the other hand, if this item in 1122 has caused implementors of resource recovery to treat connections in persist state different than other TCP connections, then I have no objection to an informational document that can give some clarification. And it should be vetted through the TCPM WG. -David Borman On Oct 3, 2008, at 1:37 PM, Ted Faber wrote: > I don't mean to be answering from John, but your comments interested > me. > > On Thu, Oct 02, 2008 at 05:13:50PM -0700, Murali Bashyam wrote: >> >>> From: John Heffner [mailto:johnwheffner@gmail.com] >>> I have reservations about moving forward with this draft as a wg >>> document. While the information is technically correct, it is >>> overly >>> specific to the point of possibly being misleading rather than >>> clarifying. An operating system may terminate a tcp connection at >>> any >>> time, not just when the connection is in the persist state. >>> Further, >>> I would actually argue that terminating a connection *because* >>> it's in >>> the persist state is a bad idea and should be discouraged. (The >>> reason for termination should be for its use of resources, not TCP's >>> state.) >> >> No implementation today (the well-known ones BSD, Windows and Linux) >> terminates the TCP connection in that persist state as long as ACKs >> are being reliably received from the peer. Those three >> implementations >> are not doing what you are saying they should be doing, and if it's >> crystal clear from the standard that they should be doing so, why >> aren't they? > > Your comment is a little ambiguous. John says that he believes that > persist state is not necessarily a good marker for aborting > connections > when resources are scarce. To take him to task because > implementations > are not using it as a marker - because the implementers agreed with > his position - is a little unfair, IMHO. > > On the WG item: > > As a bigger picture issue, I find it helpful to remember that > protocol standards, like 1122, are primarily interoperation documents. > As such, they tend to focus on what protocol implementers must do to > talk with one another successfully, not to nail down all possible > choices. > > Once we start offering advice (or stronger) to developers, we're > leaving > the interoperability domain. We, as a standards body, have to assume > that implementers know their application and their environment better > than we do, and that they can and will make appropriate decisions if > we > give them the room to do so. > > Where a standard has unnecessarily tied the hands of implementers, > that > standard should be changed, IMHO. I am also sympathetic to clarifying > the standards body's intent where poor language has obscured it. I > don't see that kind of confusion in the text the authors are > addressing > (that is RFC 1122 Section 4.2.2.17), but reasonable people can > disagree > on such things. > > As such, taking on this work item - clarifying 1122 4.2.2.17 - doesn't > excite me, but I don't oppose it. > > The draft should, IMHO, point out that 1122 has nothing to say about > resource management. Designers and implementers are free to be as > clever or foolish as they'd like. > > End of thoughts on the WG item. > > As for the draft itself, I'm concerned that it seems to be > advocating a > particular resource management position more strongly than simply > pointing out that RFC1122 should not affect resource allocation > decisions. I also see some misplaced standards language that is > somewhat confusing. I'm looking at this paragraph in Section 2: > > > An extensive discussion took place recently about this issue on > the TCPM WG mailing list [TCPM]. The general opinion seemed to > be that terminating a TCP connection in persist condition does > not violate RFC 1122. In particular the operating system, a > resource manager, or an application can instruct TCP to abort a > connection in the persist condition. TCP itself SHOULD not take > any action and continue to keep the connection open as mandated > by RFC 1122 unless otherwise instructed to do so. The exact > mechanism by which the instruction to abort the connection is > conveyed to TCP is an implementation decision and falls beyond > the scope of the current memo. > > There's no instruction going on, and one doesn't request an abort. > Abort is a command in the TCP interface (defined in RFC 793, p. 50) > that > destroys a TCP connection. Abort works in any state. Anything with > access to the TCP interface, including the OS, a resource manager, > or an > application, can call it. A TCP abort is "the exact mechanism by > which > the instruction to abort the connection is conveyed to TCP", and the > only reason that it's outside the scope of this document is that it's > defined in 793. > > In light of that I think that the sentence about "TCP itself SHOULD > not[sic] take any action..." is more confusing than the 1122 section. > It seems to imply that TCP might react differently to an abort than > the single paragraph in 793, and I don't think that's the case. > > Now, a strictly defined abort command seems to somewhat contradict my > earlier comments about allowing implementers some freedom. This is a > spot where the standards body has required a specific tool to be > available to applications (and OSes and resource managers): there must > be a way to annihilate a TCP connection from outside without regard to > its state or anything else. The standard is silent about how the > command is used; that's the flexibility here. > > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 3 13:22:39 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1676B3A6839; Fri, 3 Oct 2008 13:22:39 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AB43A6833 for ; Fri, 3 Oct 2008 13:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BIQL6sY09wP for ; Fri, 3 Oct 2008 13:22:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 411763A6839 for ; Fri, 3 Oct 2008 13:22:36 -0700 (PDT) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m93KLdpQ002996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Oct 2008 13:21:40 -0700 (PDT) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.2/Submit) id m93KLdPa031900; Fri, 3 Oct 2008 13:21:39 -0700 (PDT) (envelope-from faber) Date: Fri, 3 Oct 2008 13:21:39 -0700 From: Ted Faber To: Murali Bashyam Message-ID: <20081003202139.GF27519@zod.isi.edu> References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> Mime-Version: 1.0 In-Reply-To: <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@zod.isi.edu Cc: David Borman , "tcpm@ietf.org" , "Anantha Ramaiah \(ananth\)" , Murali Bashyam Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1486751489==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1486751489== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HCdXmnRlPgeNBad2" Content-Disposition: inline --HCdXmnRlPgeNBad2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Somewhat snipped up. On Fri, Oct 03, 2008 at 12:37:10PM -0700, Murali Bashyam wrote: > On Fri, Oct 3, 2008 at 11:37 AM, Ted Faber wrote: > > > > In light of that I think that the sentence about "TCP itself SHOULD > > not[sic] take any action..." is more confusing than the 1122 section. > > It seems to imply that TCP might react differently to an abort than > > the single paragraph in 793, and I don't think that's the case. >=20 >=20 > What's meant here is that it's okay for the connection to get aborted > in this state, whatever the mechanism for doing so maybe: TCP can > abort the connection and inform the application, similar to the > retransmit/persist timeout mechanisms already in place, or the > application can choose to abort the connection based policy, or the OS > can do so based on resource management criteria. We can re-word that > sentence and paragraph to reflect this. I disagree with "TCP can abort the connection and inform the application." RFC 1122 says that TCP must allow the connection to stay open. I believe that TCP closing or aborting such a connection (without an abort command being issued) violates 1122. External entities (OS, resource allocator, applications) can abort the connection, as they can abort any connection. The point is that the OS and applications (and other entities in a system) can both annhilate TCP connections regardless of the state of those connection to meet their needs. I believe that's a perfectly adequate tool for dealing with resource starvation. Delivering that message seems a valid WG item. >=20 > > > > > > Now, a strictly defined abort command seems to somewhat contradict my > > earlier comments about allowing implementers some freedom. This is a > > spot where the standards body has required a specific tool to be > > available to applications (and OSes and resource managers): there must > > be a way to annihilate a TCP connection from outside without regard to > > its state or anything else. The standard is silent about how the > > command is used; that's the flexibility here. >=20 >=20 > The abort semantics as specified by 793 are clear, they are not > specific to a particular state, it's the opinion of the authors that > 1122 excludes it from being applied in this state. Can you say that again? What you typed says both that the abort command is independent of connection state and that it doesn't work on connections in a certain state. That sentence contradicts itself, so I must be misunderstanding something. For the record, I believe that when a TCP stack receives an abort command for a connection in persist state the stack must abort the connection as per RFC 793, p. 50. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --HCdXmnRlPgeNBad2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjmftIACgkQaUz3f+Zf+XsEYQCg7H/CUiLDmubOOgWhjriuIVKL ljAAn0PIAlFKYlv862wCGJFHwN8rgR9Q =B+ra -----END PGP SIGNATURE----- --HCdXmnRlPgeNBad2-- --===============1486751489== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1486751489==-- From tcpm-bounces@ietf.org Fri Oct 3 14:06:00 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DD228C0D8; Fri, 3 Oct 2008 14:06:00 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5556D28C0D8 for ; Fri, 3 Oct 2008 14:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw5Ax0me-n0z for ; Fri, 3 Oct 2008 14:05:58 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 80F593A6807 for ; Fri, 3 Oct 2008 14:05:58 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m93L6N2B016386; Fri, 3 Oct 2008 14:06:24 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 14:04:51 -0700 Received: from dab-restive.wrs.com ([192.168.117.73]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Oct 2008 14:04:50 -0700 Message-Id: From: David Borman To: Murali Bashyam In-Reply-To: <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 3 Oct 2008 16:04:48 -0500 References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 03 Oct 2008 21:04:50.0812 (UTC) FILETIME=[ACECABC0:01C9259B] Cc: "Anantha Ramaiah \(ananth\)" , "tcpm@ietf.org" , Ted Faber , Murali Bashyam Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote: > > My intent was that even where TCP implementations have a scheme for > dropping connections in the event > of resource exhaustion (such as the Linux one does), they have > excluded connections in this state. > The point i am trying to convey is that the 1122 portion has > (mis)guided them in that direction. If this is true, it should be clarified. 1122 does not in any way say that ABORT does not apply to connections in persist state (probing a zero window). ... >> In light of that I think that the sentence about "TCP itself SHOULD >> not[sic] take any action..." is more confusing than the 1122 section. >> It seems to imply that TCP might react differently to an abort than >> the single paragraph in 793, and I don't think that's the case. > > What's meant here is that it's okay for the connection to get > aborted in this state, whatever the mechanism for doing > so maybe: TCP can abort the connection and inform the application, > similar to the retransmit/persist timeout mechanisms > already in place, or the application can choose to abort the > connection based policy, or the OS can do so based > on resource management criteria. We can re-word that sentence and > paragraph to reflect this. Just to be clear: TCP DOES NOT ABORT THE CONNECTION! The OS or the application can choose to ABORT the connection, but TCP does not make this decision. TCP does have retransmit timers, and it is allowed to terminate unresponsive connections, but it does not abort connections just because they are in persist state for long periods of time. Until you are running out of resources there is no good reason to terminate connections in persist state, and when you are running out of resources, it is the OS that is deciding whether or not to ABORT any TCP connections. >> Now, a strictly defined abort command seems to somewhat contradict my >> earlier comments about allowing implementers some freedom. This is a >> spot where the standards body has required a specific tool to be >> available to applications (and OSes and resource managers): there >> must >> be a way to annihilate a TCP connection from outside without regard >> to >> its state or anything else. The standard is silent about how the >> command is used; that's the flexibility here. > > The abort semantics as specified by 793 are clear, they are not > specific to a particular state, it's the opinion > of the authors that 1122 excludes it from being applied in this state. Yes, that is an opinion, but it is wrong. In no way does 1122 say that connections in persist state cannot be ABORTed. What 1122 does say is that a connection being in persist state for a long time is not sufficient reason *by itself* to terminate a TCP connection, i.e., don't time it out like you would a connection to a non-responsive host. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 3 23:55:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A76A3A6947; Fri, 3 Oct 2008 23:55:21 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C5D3A6850 for ; Fri, 3 Oct 2008 23:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NTqjL-otOwg for ; Fri, 3 Oct 2008 23:54:51 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 2DF2B28C1AC for ; Fri, 3 Oct 2008 23:54:49 -0700 (PDT) Received: from [192.168.255.2] (a88-114-157-111.elisa-laajakaista.fi [88.114.157.111]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m946tC0X089102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 4 Oct 2008 09:55:12 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: tcpm Extensions WG In-Reply-To: <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 09:55:11 +0300 References: <20081002093129.5bb80658@cs.columbia.edu> <1ABB0C9F-EAF3-445D-B8E1-58110496291C@nokia.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8373/Sat Oct 4 05:00:50 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.fit.nokia.com [212.213.221.39]); Sat, 04 Oct 2008 09:55:18 +0300 (EEST) Subject: Re: [tcpm] Fwd: Secdir Review of draft-stjohns-sipso-05 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1397074206==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============1397074206== Content-Type: multipart/signed; boundary=Apple-Mail-34--17023748; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-34--17023748 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This is now being discussed on the tsv-area@ietf.org and saag@ietf.org lists. Please join the discussion there. Lars On 2008-10-2, at 16:55, ext Lars Eggert wrote: > FYI, this discussion on the main IETF list needs input from > transport folks. Look at Section 7.3 of draft-stjohns-sipso-05. > > Lars > > Begin forwarded message: > >> From: "ext Steven M. Bellovin" >> Date: October 2, 2008 16:31:29 GMT+03:00 >> To: "Steven M. Bellovin" >> Cc: draft-stjohns-sipso-05@tools.ietf.org, Sam Hartman > >, secdir@mit.edu, ietf@ietf.org >> Subject: Re: Secdir Review of draft-stjohns-sipso-05 >> >> On Wed, 1 Oct 2008 22:12:17 -0400 >> "Steven M. Bellovin" wrote: >> >>>> Steven> Note 7.3.1 on >>>> Steven> TCP considerations. (Also note that 7.3.1 disagrees >>>> Steven> with 793 on the treatment of security labels in section >>>> Steven> 3.6 of 793. At the least, this shoudl be noted. >>>> >>>> I had completely missed this. I'll call out the section to the >>>> transport ADs >>>> >>> I should have added: I think the new document is in fact more >>> correct >>> than 793 -- the 793 scheme would permit various forms of >>> high-bandwidth covert channels to be set up. This is an issue that >>> was not nearly that well understood when 793 was written. That >>> said, >>> it is a change to TCP, and needs to be treated as such. >>> >> Thinking further -- I suspect that the right thing to do here is for >> someone to write a short, simple draft amending 793 -- it's >> handling of >> the security option is simply wrong, independent of this draft. I >> wonder -- what TCPs actually implement even 793? NetBSD doesn't; I >> strongly suspect that no BSDs do. Does Solaris? Linux? >> >> --Steve Bellovin, http://www.cs.columbia.edu/~smb >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-34--17023748 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAwNDA2NTUxMlowIwYJKoZI hvcNAQkEMRYEFIZ5voaaPaprOKRlRbbYp8ziZEeCMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQA61HNVlLhmeq4YEtOCPnPF+UQc aIorWOd4kqOPxSZzFyQDarESVaduEUrKoKNvGJ9lGWTmFQZ2CwAK7yGiR2PaxqZ54g+0R2ZwX9sm /yC0SWncOQrRECEF3dPz36x7X4Tb+I3IM4d3IEYfXrObbUit95oqPkvdZQZu2p9ljD9VT9KKs7f1 7eDU8ZXx6vua7h6Tzjso8tb4JOTTAARNTC5cw3OR54bOpz90NZY9XDiCTRGgjTGQ18cwiYvW9Xy6 xePEbhhU6pw4wswTXM1uQqOs66V3oW0QEiJb6ss6rnXX+eRaA5Uqf6LvlFTyA75d+ivSD9hSvYBr jTEod8JpczT8AAAAAAAA --Apple-Mail-34--17023748-- --===============1397074206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============1397074206==-- From tcpm-bounces@ietf.org Sat Oct 4 21:48:17 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09FF23A68F9; Sat, 4 Oct 2008 21:48:17 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614243A68F9 for ; Sat, 4 Oct 2008 21:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.684 X-Spam-Level: X-Spam-Status: No, score=-0.684 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X44tiwEKaxem for ; Sat, 4 Oct 2008 21:48:13 -0700 (PDT) Received: from mail.ocarinanetworks.com (h-69-3-29-18.snvacaid.covad.net [69.3.29.18]) by core3.amsl.com (Postfix) with ESMTP id 3E5F33A68DE for ; Sat, 4 Oct 2008 21:48:13 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Sat, 4 Oct 2008 21:48:45 -0700 From: Murali Bashyam To: David Borman , Murali Bashyam Date: Sat, 4 Oct 2008 21:48:37 -0700 Thread-Topic: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document Thread-Index: AcklnA2e2MXArg1GSAaMUO85RtQh+AAHXndQ Message-ID: References: <53797EED-2C93-4E20-AF60-E3C0EF8F85AC@windriver.com> <1e41a3230809292310o591b7f98l5048083b9e0966f2@mail.gmail.com> <20081003183726.GD27519@zod.isi.edu> <9c8209a10810031237y470b9cd3ha8ad6cbc3e17e422@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "Anantha Ramaiah \(ananth\)" , "tcpm@ietf.org" , Ted Faber Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: David Borman [mailto:david.borman@windriver.com] > Sent: Friday, October 03, 2008 2:05 PM > To: Murali Bashyam > Cc: Ted Faber; tcpm@ietf.org; Anantha Ramaiah (ananth); Murali Bashyam > Subject: Re: [tcpm] draft-ananth-tcpm-persist-00.txt as a WG document > > > On Oct 3, 2008, at 2:37 PM, Murali Bashyam wrote: > > > > My intent was that even where TCP implementations have a scheme for > > dropping connections in the event > > of resource exhaustion (such as the Linux one does), they have > > excluded connections in this state. > > The point i am trying to convey is that the 1122 portion has > > (mis)guided them in that direction. > > If this is true, it should be clarified. 1122 does not in any way say > that ABORT does not apply to connections in persist state (probing a > zero window). > > ... > >> In light of that I think that the sentence about "TCP itself SHOULD > >> not[sic] take any action..." is more confusing than the 1122 > section. > >> It seems to imply that TCP might react differently to an abort than > >> the single paragraph in 793, and I don't think that's the case. > > > > What's meant here is that it's okay for the connection to get > > aborted in this state, whatever the mechanism for doing > > so maybe: TCP can abort the connection and inform the application, > > similar to the retransmit/persist timeout mechanisms > > already in place, or the application can choose to abort the > > connection based policy, or the OS can do so based > > on resource management criteria. We can re-word that sentence and > > paragraph to reflect this. > > Just to be clear: TCP DOES NOT ABORT THE CONNECTION! The OS or the > application can choose to ABORT the connection, but TCP does not make > this decision. TCP does have retransmit timers, and it is allowed to > terminate unresponsive connections, but it does not abort connections > just because they are in persist state for long periods of time. > Until you are running out of resources there is no good reason to > terminate connections in persist state, and when you are running out > of resources, it is the OS that is deciding whether or not to ABORT > any TCP connections. I agree that the retransmit/persist timeout analogy doesn't apply to this situation. It is ONLY the OS or resource manager or the application that can terminate the connection In this state. > > > >> Now, a strictly defined abort command seems to somewhat contradict > my > >> earlier comments about allowing implementers some freedom. This is > a > >> spot where the standards body has required a specific tool to be > >> available to applications (and OSes and resource managers): there > >> must > >> be a way to annihilate a TCP connection from outside without regard > >> to > >> its state or anything else. The standard is silent about how the > >> command is used; that's the flexibility here. > > > > The abort semantics as specified by 793 are clear, they are not > > specific to a particular state, it's the opinion > > of the authors that 1122 excludes it from being applied in this > state. > > Yes, that is an opinion, but it is wrong. In no way does 1122 say > that connections in persist state cannot be ABORTed. What 1122 does > say is that a connection being in persist state for a long time is not > sufficient reason *by itself* to terminate a TCP connection, i.e., > don't time it out like you would a connection to a non-responsive host. Just so that we are all clear, i want to summarize the goals of the draft here once again: 1. Clarify the 1122 ambiguity/stance on the sender behavior in persist state. 2. Document (for informational purpose) the consequence of this behavior leading to the DoS possibility. 3. Specify that the OS/application can terminate the connection in this state using the 793 ABORT interface. We are NOT documenting the various memory management considerations/issues surrounding the DoS scenario, that's left to the implementers discretion. We will change the section that's ambiguous regarding the sentence that goes "TCP itself should not take any action...". _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 14 08:24:21 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847673A6B36; Tue, 14 Oct 2008 08:24:21 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8244B3A6B36 for ; Tue, 14 Oct 2008 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q80ev9PXhzUd for ; Tue, 14 Oct 2008 08:24:16 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id CA3B63A659A for ; Tue, 14 Oct 2008 08:24:16 -0700 (PDT) Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 422D93281C8 for ; Tue, 14 Oct 2008 10:24:20 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt02.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m9EFOF7A029709 for ; Tue, 14 Oct 2008 10:24:19 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 10:24:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 10:24:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 73 session Thread-Index: AckuEOtsr2TuGQDgSruiPvG9mA3/Ew== From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 14 Oct 2008 15:24:17.0027 (UTC) FILETIME=[EBFBC530:01C92E10] Subject: [tcpm] IETF 73 session X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org There will be a TCPM meeting at IETF 73 in Minneapolis November 16-21: http://www.ietf.org/meetings/73/ Currently, the secretariat has scheduled TCPM for a 2 hour session on Thursday afternoon from 1-3. We'll be creating an agenda in the next few weeks, so if there is something that you'd like to present on, please let David Borman and/or myself know as soon as possible. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Oct 24 09:58:58 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29273A6A65; Fri, 24 Oct 2008 09:58:58 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40BD3A6A65 for ; Fri, 24 Oct 2008 09:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVhZg2jJvLZR for ; Fri, 24 Oct 2008 09:58:56 -0700 (PDT) Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id DA14D3A687D for ; Fri, 24 Oct 2008 09:58:56 -0700 (PDT) Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 182BDA8265 for ; Fri, 24 Oct 2008 12:00:03 -0500 (CDT) Received: from ndjsxgw04.ndc.nasa.gov (ndjsxgw04.ndc.nasa.gov [129.166.32.112]) by ndjsppt03.ndc.nasa.gov (8.14.1/8.14.1) with ESMTP id m9OH02g1004160 for ; Fri, 24 Oct 2008 12:00:02 -0500 Received: from NDJSEVS25A.ndc.nasa.gov ([129.166.32.124]) by ndjsxgw04.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 12:00:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 12:00:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCPM - Requested session has been scheduled for IETF 73 Thread-Index: Ack1aQF5HGeqRPAeTKWu5vrisu59+wAkMc1A From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" To: X-OriginalArrivalTime: 24 Oct 2008 17:00:02.0937 (UTC) FILETIME=[F4F18E90:01C935F9] Subject: [tcpm] FW: TCPM - Requested session has been scheduled for IETF 73 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org FYI, the TCPM meeting at IETF 73 is currently scheduled for Tuesday (11/18) at 3:20 PM. Keep the agenda requests flowing to David and myself if you have them! >-----Original Message----- >From: IETF Secretariat [mailto:agenda@ietf.org] >Sent: Thursday, October 23, 2008 7:41 PM >To: weddy@grc.nasa.gov >Cc: david.borman@windriver.com; david.borman@windriver.com; >magnus.westerlund@ericsson.com; lars.eggert@nokia.com; >session-request@ietf.org >Subject: TCPM - Requested session has been scheduled for IETF 73 > >Dear Wesley Eddy, > >The sessions that you have requested have been scheduled. >Below is the scheduled session information followed by >the information of sessions that you have requested. > >TCPM Session 1 (2 hours) >Tuesday, Afternoon Session II 1520-1700 >Room Name: Meeting Room _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 10:15:48 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946A73A6804; Mon, 27 Oct 2008 10:15:48 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A363A67C0 for ; Mon, 27 Oct 2008 10:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7pWpad4YjpA for ; Mon, 27 Oct 2008 10:15:46 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id ADAD13A6358 for ; Mon, 27 Oct 2008 10:15:46 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2114110rvf.49 for ; Mon, 27 Oct 2008 10:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=xo0VSMvL+9H/rshcaB8Wfg/LBH3sLMZ31m3Y0KCCH0g=; b=ly64r18Z/JeEywf7gS4MRHcWffSP4na+TyM8JHufSoxJbK8VewmN5j11Cf04CFZXPF OHjuJLE52Um6ZBMWCG8qGciSOz+/HMN8KGvvYxCS8JFJYNFLqIs7I3c789tGpeIzIm3f PzIVu163Yaj01kLArtH/qZN7wNnH+ZVTC9lgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=jNFHOlUWkEDx7bNCwsbcIDgaODmwB52mDMiS/NfR+/upvR70GIuSxUulyGk5dqekAw mbn3Gl4IfLe8mbQULKmPQMRqcBKikmdaQ9oEfue2EI/s/LAj4ADzsh3pgRlUseWQJowQ yUZ7VOuvWECZMJ5w7E/v6zzzoXeQgtOlQFPFQ= Received: by 10.141.206.13 with SMTP id i13mr3378436rvq.211.1225127745891; Mon, 27 Oct 2008 10:15:45 -0700 (PDT) Received: by 10.141.48.20 with HTTP; Mon, 27 Oct 2008 10:15:45 -0700 (PDT) Message-ID: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> Date: Mon, 27 Oct 2008 10:15:45 -0700 From: "Adam Langley" To: tcpm@ietf.org MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 1c9e4deafd742b2f Subject: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The general fact that ordering of TCP options can be important is probably old news to many here. However, the specifics may be interesting. With Linux 2.6.27 the kernel changed the default ordering of options. With the default sysctls the ordering changed from: To This was my fault and it broke the world :( Many routers dropped the new packets on the floor, breaking connectivity for many people: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264019 http://www.ubuntu.com/getubuntu/releasenotes/810 https://qa.mandriva.com/show_bug.cgi?id=43372 http://wiki.mandriva.com/en/2009.0_Errata#TCP_timestamps Disabling the timestamps sysctl fixes the issue. The options in this case looked like: And that is seemingly ok with these routers. It seems that SACK PERM cannot be the first option. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 11:07:46 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A283A6AD0; Mon, 27 Oct 2008 11:07:46 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163BF3A6804 for ; Mon, 27 Oct 2008 11:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXKT3mVJ0mYy for ; Mon, 27 Oct 2008 11:07:44 -0700 (PDT) Received: from mail.fit.nokia.com (unknown [IPv6:2001:2060:40:1::123]) by core3.amsl.com (Postfix) with ESMTP id 4062C3A6AD0 for ; Mon, 27 Oct 2008 11:07:43 -0700 (PDT) Received: from [192.168.255.2] (a88-114-157-111.elisa-laajakaista.fi [88.114.157.111]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id m9RI7XiT005620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2008 20:07:35 +0200 (EET) (envelope-from lars.eggert@nokia.com) Message-Id: <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> From: Lars Eggert To: ext Adam Langley In-Reply-To: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 20:07:32 +0200 References: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV 0.94/8509/Mon Oct 27 18:23:56 2008 on fit.nokia.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (mail.fit.nokia.com [212.213.221.39]); Mon, 27 Oct 2008 20:07:41 +0200 (EET) Cc: tcpm@ietf.org Subject: Re: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0449910301==" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --===============0449910301== Content-Type: multipart/signed; boundary=Apple-Mail-9--136966891; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-9--136966891 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2008-10-27, at 19:15, ext Adam Langley wrote: > This was my fault and it broke the world :( Many routers dropped the > new packets on the floor, breaking connectivity for many people: Could you clarify if by "routers" you mean IP routers or cable/DSL modems? Thanks, Lars --Apple-Mail-9--136966891 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyNzE4MDczMlowIwYJKoZI hvcNAQkEMRYEFOiuL9Fp2yco7tT3mtBQadO0zUGAMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQCYa83AgEFPJhNELb5kYsAhWqUR RHP8t4JDOTboKFT0Y0nw2JIOOIh9p0mC7dv1HFzvsvpjdJc5ci+ggMkLAtyCL7qONTIjlJ+6uUti euSEuXM7UX9wXozBsr/aksHe4PDfc2X+oj72HBhOEZtLMqG0obOOtJ+CZlauK/cBMflnEQNe5z+0 n8m9iEi6AkylC487LvLrDkKUcXMa8D0F/28NJa2qpmiUaidwOeWjdaJ0qVLXQgr/961uOjP79ttw XZDNaZl8wwK3L3ovN2P3lHMr3xtnkuSxTuA/SUm5YmgOa5Ij3+hncDucVNM05phJRxLWa/Hadnw5 vavbBYohwhsuAAAAAAAA --Apple-Mail-9--136966891-- --===============0449910301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --===============0449910301==-- From tcpm-bounces@ietf.org Mon Oct 27 11:52:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 919873A68D0; Mon, 27 Oct 2008 11:52:04 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19363A67A1 for ; Mon, 27 Oct 2008 11:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLZqaiz1UMTR for ; Mon, 27 Oct 2008 11:52:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 095BE3A68D0 for ; Mon, 27 Oct 2008 11:52:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2151762rvf.49 for ; Mon, 27 Oct 2008 11:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=eEaQ2OK94AdoAZHJnx7MNcnQn0umwbYfgcP4pFyT6EQ=; b=icBGnTYjijZVGk4Jvs64iOKZFRkFPxSe/7NVrgUZdHhoW0K6xdQYQ8AOTcqpQ2/YgO x4V/S5I7iDjd55Sc3kNcLok7Ze88fauXGbbM4+AsSxYT8+z6cG/+F77K2fUFx7ug5EY6 6SUjnNJiQdU0wdSWbu7zP1ZLUMjCbO3pMBMwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mmc0LCWeyfinHnBiWp6VURfhhhUsssh+GcPA6Ey3HBi6yHiZoK/mn1CymQgM4nOBWm mRh8bnidxwtXt6TpGYOd6ycXcvgzWtHQmOLkZLatGqvzCLwkDZ4WkF82ojfOu3DiR0CT o0Ppw8rZVypk8uaCy4imu+eCgGXSTmo0L6CmA= Received: by 10.141.168.16 with SMTP id v16mr3438262rvo.233.1225133522531; Mon, 27 Oct 2008 11:52:02 -0700 (PDT) Received: by 10.141.48.20 with HTTP; Mon, 27 Oct 2008 11:52:02 -0700 (PDT) Message-ID: <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> Date: Mon, 27 Oct 2008 11:52:02 -0700 From: "Adam Langley" To: "Lars Eggert" In-Reply-To: <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> X-Google-Sender-Auth: b17adf732621884d Cc: tcpm@ietf.org Subject: Re: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, Oct 27, 2008 at 11:07 AM, Lars Eggert wrote: > Could you clarify if by "routers" you mean IP routers or cable/DSL modems? It's not clear. The only source of information that I have are the user bug reports listed above. Certainly some "consumer moderm"/NAT/wireless access point type of hardware broke. However, there were also a number of reports of Verizon DSL breaking with some diversity of consumer modems so it may be that something bigger broke there. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 13:30:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3B13A6C01; Mon, 27 Oct 2008 13:30:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC893A6C00 for ; Mon, 27 Oct 2008 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpM9zJ4BFszf for ; Mon, 27 Oct 2008 13:30:10 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 624973A6BFB for ; Mon, 27 Oct 2008 13:30:09 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m9RKU1gs020867; Mon, 27 Oct 2008 13:30:03 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:30:01 -0700 Received: from [147.11.4.189] ([147.11.4.189]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 13:30:01 -0700 Message-Id: From: David Borman To: Adam Langley In-Reply-To: <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 15:30:00 -0500 References: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 27 Oct 2008 20:30:01.0210 (UTC) FILETIME=[C956B5A0:01C93872] Cc: tcpm@ietf.org Subject: Re: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Well, the implementations are broken if re-ordering TCP options causes them to break. TCP options can be in any order, and have any alignment. Sure, there might be some suggestions for common ordering to allow efficient processing, but those are only recommendations and cannot be relied on. -David Borman On Oct 27, 2008, at 1:52 PM, Adam Langley wrote: > On Mon, Oct 27, 2008 at 11:07 AM, Lars Eggert > wrote: >> Could you clarify if by "routers" you mean IP routers or cable/DSL >> modems? > > It's not clear. The only source of information that I have are the > user bug reports listed above. Certainly some "consumer > moderm"/NAT/wireless access point type of hardware broke. However, > there were also a number of reports of Verizon DSL breaking with some > diversity of consumer modems so it may be that something bigger broke > there. > > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 15:03:24 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C3228C1B2; Mon, 27 Oct 2008 15:03:24 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E8B3A68C6 for ; Mon, 27 Oct 2008 15:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9IXN4SAi2nB for ; Mon, 27 Oct 2008 15:03:22 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 15D1F3A6A2C for ; Mon, 27 Oct 2008 15:03:20 -0700 (PDT) Received: from wrl-59.cs.helsinki.fi (wrl-59.cs.helsinki.fi [128.214.166.179]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 28 Oct 2008 00:03:18 +0200 id 0005BEAA.49063AA6.00005788 Received: by wrl-59.cs.helsinki.fi (Postfix, from userid 50795) id A1FC1A009F; Tue, 28 Oct 2008 00:03:18 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by wrl-59.cs.helsinki.fi (Postfix) with ESMTP id 8FB63A0098; Tue, 28 Oct 2008 00:03:18 +0200 (EET) Date: Tue, 28 Oct 2008 00:03:18 +0200 (EET) From: "=?ISO-8859-1?Q?Ilpo_J=E4rvinen?=" X-X-Sender: ijjarvin@wrl-59.cs.helsinki.fi To: Adam Langley In-Reply-To: <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> Message-ID: References: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> Mime-Version: 1.0 Cc: tcpm@ietf.org Subject: Re: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 27 Oct 2008, Adam Langley wrote: > On Mon, Oct 27, 2008 at 11:07 AM, Lars Eggert wrote: > > Could you clarify if by "routers" you mean IP routers or cable/DSL modems? > > It's not clear. The only source of information that I have are the > user bug reports listed above. Certainly some "consumer > moderm"/NAT/wireless access point type of hardware broke. However, > there were also a number of reports of Verizon DSL breaking with some > diversity of consumer modems so it may be that something bigger broke > there. Here's at least one known device: http://marc.info/?l=linux-netdev&m=122509030019980&w=2 -- i. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 16:30:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345E428C240; Mon, 27 Oct 2008 16:30:04 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 345E828C234; Mon, 27 Oct 2008 16:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027233001.345E828C234@core3.amsl.com> Date: Mon, 27 Oct 2008 16:30:01 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : ICMP attacks against TCP Author(s) : F. Gont Filename : draft-ietf-tcpm-icmp-attacks-04.txt Pages : 38 Date : 2008-10-27 This document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP) and other similar protocols. Additionally, describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-icmp-attacks-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27162424.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Mon Oct 27 17:01:18 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC13828C262; Mon, 27 Oct 2008 17:01:18 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB12B28C260 for ; Mon, 27 Oct 2008 17:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK3ppALG56Wl for ; Mon, 27 Oct 2008 17:01:17 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B7B2728C269 for ; Mon, 27 Oct 2008 17:01:01 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C2B1C6B66B5 for ; Mon, 27 Oct 2008 21:01:03 -0300 (ART) Received: from notebook.gont.com.ar (201-254-27-192.speedy.com.ar [201.254.27.192] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m9S00h4C029878 for ; Mon, 27 Oct 2008 22:00:44 -0200 Message-Id: <200810280000.m9S00h4C029878@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 20:52:14 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 27 Oct 2008 21:00:59 -0300 (ART) Subject: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-tcp-timestamps-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, folks, I have published a new Internet-draft entitled "On the generation of TCP timestamps". The draft is available at: http://tools.ietf.org/id/draft-gont-tcpm-tcp-timestamps-00.txt . (See the details bellow). Any comments will be more than welcome. Thanks! Fernando >A new version of I-D, draft-gont-tcpm-tcp-timestamps-00.txt has been >successfuly submitted by Fernando Gont and posted to the IETF repository. > >Filename: draft-gont-tcpm-tcp-timestamps >Revision: 00 >Title: On the generation of TCP timestamps >Creation_date: 2008-10-28 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >This document describes an algorithm for selecting the timestamps (TS >value) used for TCP connections that use the TCP timestamp option, >such that the resulting timestamps are monotonically-increasing >across connections that involve the same four-tuple {local IP >address, local TCP port, remote IP address, remote TCP port}. The >properties of the algorithm are such the possibility of an attacker >guessing the exact value is reduced. Additionally, it describes an >algorithm for processing incoming SYN segments to allow a higher >connection establishment rates to any TCP end-point. > > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 17:08:53 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454633A6B9A; Mon, 27 Oct 2008 17:08:53 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E6D3A6813 for ; Mon, 27 Oct 2008 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.637 X-Spam-Level: X-Spam-Status: No, score=-0.637 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wp1IoqPrqcr for ; Mon, 27 Oct 2008 17:08:51 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 0A4E03A6A2C for ; Mon, 27 Oct 2008 17:08:50 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id C8ACF6B66DA; Mon, 27 Oct 2008 21:01:04 -0300 (ART) Received: from notebook.gont.com.ar (201-254-27-192.speedy.com.ar [201.254.27.192] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m9S00h4E029878; Mon, 27 Oct 2008 22:00:48 -0200 Message-Id: <200810280000.m9S00h4E029878@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 20:54:57 -0300 To: tcpm@ietf.org From: Fernando Gont Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 27 Oct 2008 21:01:04 -0300 (ART) Cc: ayourtch@cisco.com Subject: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, folks, FYI, we have published a new Internet-Draft entitled "On the implementation of TCP urgent data". The draft is available at: http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-00.txt (see the Abstract on other details bellow). Any comments will be more than welcome. Thanks! Kind regards, Fernando >A new version of I-D, draft-gont-tcpm-urgent-data-00.txt has been >successfuly submitted by Fernando Gont and posted to the IETF repository. > >Filename: draft-gont-tcpm-urgent-data >Revision: 00 >Title: On the implementation of TCP urgent data >Creation_date: 2008-10-28 >WG ID: Independent Submission >Number_of_pages: 10 > >Abstract: >This document analyzes the current practices for handling TCP urgent >data in the current Internet. It describes how popular TCP >implementations process urgent data, and also describes how a number >of middle-boxes affect how urgent data is processed by end systems. >Additionally, it includes a survey of the processing of urgent data >by popular TCP implementations. This document updates the relevant >specifications such that they accommodate current practice in >processing TCP urgent data. -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 18:01:31 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5480428C240; Mon, 27 Oct 2008 18:01:31 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C17528C240 for ; Mon, 27 Oct 2008 18:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJSqqTNAdMeh for ; Mon, 27 Oct 2008 18:01:29 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id 85A643A6859 for ; Mon, 27 Oct 2008 18:01:29 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m9S11HZM026417; Mon, 27 Oct 2008 18:01:18 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 18:01:17 -0700 Received: from [147.11.4.189] ([147.11.4.189]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 18:01:17 -0700 Message-Id: From: David Borman To: Fernando Gont In-Reply-To: <200810280000.m9S00h4E029878@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 27 Oct 2008 20:01:17 -0500 References: <200810280000.m9S00h4E029878@venus.xmundo.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 28 Oct 2008 01:01:17.0527 (UTC) FILETIME=[AEC79670:01C93898] Cc: tcpm@ietf.org, ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org I've done a quick scan of this document, and it indicates to me a misunderstanding of urgent data. First, despite what 793 and 1122 say, TCP does *not* have urgent data in the sense that people think. TCP has an urgent *pointer*, that indicates an interesting point in the data stream. *All* the data prior to, and including, the Urgent pointer is the urgent data. It is up to the application to decide what that means, and which data relative to the urgent pointer is interesting, but typically it would be the data just after the urgent pointer. The application can't say "these x bytes of data are the urgent data". If a TCP data stream writes some data in normal mode and the data gets lost, then there is a successive write in urgent mode, then when the lost packet is re-transmitted it'll now be transmitted with the URG bit and the urgent pointer, turning that data into "urgent data" by the 793 definition. That's not what people think when they first hear the term "urgent data", but that's how it works. It is much easier to understand if you don't use the term "urgent data", and just think about the urgent pointer. The reader goes into urgent mode reading data until it gets to the urgent pointer, at which point it goes back into normal mode. All the data is delivered to the application in sequence. TCP does not have an out-of-band data delivery mechanism, and this is where the original BSD code got into trouble, because it took one byte out of the data stream and delivered it to the application out-of-band. To fix that, the SO_OOBINLINE socket option was introduced, and is still around today. All applications that use urgent data should be using the SO_OOBINLINE option, there's no excuse for using the old, broken BSD interpretation about urgent data. There isn't anything wrong with the 793/1122 definition of the Urgent Pointer. It might be useful to clarify the description if people are still implementing and/or using it wrong, but the definition in 793/1122 is still correct. -David Borman On Oct 27, 2008, at 6:54 PM, Fernando Gont wrote: > Hello, folks, > > FYI, we have published a new Internet-Draft entitled "On the > implementation of TCP urgent data". The draft is available at: http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-00.txt > (see the Abstract on other details bellow). > > Any comments will be more than welcome. > > Thanks! > > Kind regards, > Fernando > > > > >> A new version of I-D, draft-gont-tcpm-urgent-data-00.txt has been >> successfuly submitted by Fernando Gont and posted to the IETF >> repository. >> >> Filename: draft-gont-tcpm-urgent-data >> Revision: 00 >> Title: On the implementation of TCP urgent data >> Creation_date: 2008-10-28 >> WG ID: Independent Submission >> Number_of_pages: 10 >> >> Abstract: >> This document analyzes the current practices for handling TCP urgent >> data in the current Internet. It describes how popular TCP >> implementations process urgent data, and also describes how a number >> of middle-boxes affect how urgent data is processed by end systems. >> Additionally, it includes a survey of the processing of urgent data >> by popular TCP implementations. This document updates the relevant >> specifications such that they accommodate current practice in >> processing TCP urgent data. > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 19:04:03 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EBA3A6BCD; Mon, 27 Oct 2008 19:04:03 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620C03A693F for ; Mon, 27 Oct 2008 19:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8K4feRfA5zx for ; Mon, 27 Oct 2008 19:04:01 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 185903A694A for ; Mon, 27 Oct 2008 19:04:00 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 72DF06B657D; Mon, 27 Oct 2008 23:04:03 -0300 (ART) Received: from notebook.gont.com.ar (201-254-27-192.speedy.com.ar [201.254.27.192] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m9S23foZ023071; Tue, 28 Oct 2008 00:03:42 -0200 Message-Id: <200810280203.m9S23foZ023071@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Oct 2008 22:58:08 -0300 To: David Borman From: Fernando Gont In-Reply-To: References: <200810280000.m9S00h4E029878@venus.xmundo.net> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 27 Oct 2008 23:04:02 -0300 (ART) Cc: tcpm@ietf.org, ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello, David, Thanks for your timely response. You'll find my comments inline.... >First, despite what 793 and 1122 say, TCP does *not* have urgent data >in the sense that people think. TCP has an urgent *pointer*, that >indicates an interesting point in the data stream. *All* the data >prior to, and including, the Urgent pointer is the urgent data. Agreed. However, there are two issues here: Firstly, the recv(2) with MSG_OOB only returns a single byt of urgent data, whereas according to your explanation it should return all data prior to, and including, the Urgent pointer. Secondly, virtually all implementations intepret that the Urgent pointer point to the byte following the last byte of urgent data. And this is what RFC 1122 aims at correcting. (However, this correction didn't reflect into actual implementations.) >It is >up to the application to decide what that means, and which data >relative to the urgent pointer is interesting, but typically it would >be the data just after the urgent pointer. The application can't say >"these x bytes of data are the urgent data". mmm... why couldn't it say, e.g., that all the bytes up to the urgent pointer are urgent data? (currently, only the byte before the Urgent Pointer is interpreted as Urgent data... which does not seem to agree with what the RFCs specify....) >If a TCP data stream writes some data in normal mode and the data gets >lost, then there is a successive write in urgent mode, then when the >lost packet is re-transmitted it'll now be transmitted with the URG >bit and the urgent pointer, turning that data into "urgent data" by >the 793 definition. That's not what people think when they first hear >the term "urgent data", but that's how it works. Agreed. >it to the application out-of-band. To fix that, the SO_OOBINLINE >socket option was introduced, and is still around today. All >applications that use urgent data should be using the SO_OOBINLINE >option, there's no excuse for using the old, broken BSD interpretation >about urgent data. Well, this seems to be the default for all major TCP implementations (see our survey). >There isn't anything wrong with the 793/1122 definition of the Urgent >Pointer. The specific issue we are discussing is that the Urgent pointer is defined in RFC 793 as pointing "to the byte following the last byte of urgent data". RFC 1122 later corrected this definitation, stating that it points to "the last byte of urgent data". > It might be useful to clarify the description if people are >still implementing and/or using it wrong, but the definition in >793/1122 is still correct. Section 4.2.2.4 of RFC 1122 states: "The second sentence is in error: the urgent pointer points to the sequence number of the LAST octet (not LAST+1) in a sequence of urgent data. The description on page 56 (last sentence) is correct." This is where I'm saying that RFC 1122 differs from RFC 793. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 20:46:59 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488953A688A; Mon, 27 Oct 2008 20:46:59 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2EFB3A6979 for ; Mon, 27 Oct 2008 20:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWe6-iXA0x-2 for ; Mon, 27 Oct 2008 20:46:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 90BBA3A688A for ; Mon, 27 Oct 2008 20:46:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9S3ksq07713; Tue, 28 Oct 2008 04:46:54 +0100 (CET) Received: from kk-son (dhcp-peg3-vl30-144-254-7-191.cisco.com [144.254.7.191]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id m9S3kbG07615; Tue, 28 Oct 2008 04:46:37 +0100 (CET) Date: Tue, 28 Oct 2008 04:46:36 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@zippy.stdio.be To: Fernando Gont In-Reply-To: <200810280203.m9S23foZ023071@venus.xmundo.net> Message-ID: References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> MIME-Version: 1.0 Cc: tcpm@ietf.org, David Borman Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ayourtch@cisco.com List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org Hello David, thanks a lot for the comments. Addition to Fernando's comments inline. On Mon, 27 Oct 2008, Fernando Gont wrote: >> it to the application out-of-band. To fix that, the SO_OOBINLINE >> socket option was introduced, and is still around today. All >> applications that use urgent data should be using the SO_OOBINLINE >> option, there's no excuse for using the old, broken BSD interpretation >> about urgent data. > > Well, this seems to be the default for all major TCP implementations (see our > survey). > Just to add - the code I created for testing was deliberately without the SO_OOBINLINE - under the "naive" premise that indeed this protocol implementation bug would've been corrected by now and the "standards-compliant" behaviour would be the default. >> All applications that use >>urgent data should be using the SO_OOBINLINE option, there's no excuse for >>using the old, broken BSD interpretation about urgent data. Again, the deliberate "naive expectation" was that the old and known broken implementation is *not* the default in the today's TCP stacks, but would require a configuration tweak to fallback to buggy behaviour used in the legacy applications. > >> There isn't anything wrong with the 793/1122 definition of the Urgent >> Pointer. > > The specific issue we are discussing is that the Urgent pointer is defined in > RFC 793 as pointing "to the byte following the last byte of urgent data". RFC > 1122 later corrected this definitation, stating that it points to "the last > byte of urgent data". > So, we have three options: - "old and buggy" semantics -> default with no additional effort - the incorrect semantics from the RFC793 - correct by the RFC1122 -> default after adding the additional code to set the socket to SO_OOBINLINE to get away from the "old and buggy" one - the "standard" RFC1122 semantics -> achievable with SO_OOBINLINE setsockopt *and* the host-global configuration switch. The latter two are split because at least in one scenario within the set that we tested there was an observable difference in the behaviour - while again this can be classified as a "bug", it pretty much leaves the reasonable answer to the question "How to interoperably use the urgent pointer/data in TCP for my application?" to be "Don't" ? thanks, andrew _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 22:43:12 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349B83A6979; Mon, 27 Oct 2008 22:43:12 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6E1C3A6979 for ; Mon, 27 Oct 2008 22:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h23oPG4Q3BsD for ; Mon, 27 Oct 2008 22:43:10 -0700 (PDT) Received: from mail.wrs.com (mail.windriver.com [147.11.1.11]) by core3.amsl.com (Postfix) with ESMTP id AD6D63A68B9 for ; Mon, 27 Oct 2008 22:43:10 -0700 (PDT) Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m9S5gutC024775; Mon, 27 Oct 2008 22:42:56 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 22:42:56 -0700 Received: from [147.11.4.189] ([147.11.4.189]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Oct 2008 22:42:55 -0700 Message-Id: <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> From: David Borman To: Fernando Gont In-Reply-To: <200810280203.m9S23foZ023071@venus.xmundo.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 28 Oct 2008 00:42:55 -0500 References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 28 Oct 2008 05:42:56.0180 (UTC) FILETIME=[07296740:01C938C0] Cc: tcpm@ietf.org, ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Oct 27, 2008, at 8:58 PM, Fernando Gont wrote: > Hello, David, > > Thanks for your timely response. You'll find my comments inline.... > > >> First, despite what 793 and 1122 say, TCP does *not* have urgent data >> in the sense that people think. TCP has an urgent *pointer*, that >> indicates an interesting point in the data stream. *All* the data >> prior to, and including, the Urgent pointer is the urgent data. > > Agreed. However, there are two issues here: > > Firstly, the recv(2) with MSG_OOB only returns a single byt of > urgent data, whereas according to your explanation it should return > all data prior to, and including, the Urgent pointer. No, applications shouldn't be using recv() with MSG_OOB on TCP sockets. That is the interface for the old, broken BSD interpretation of the urgent pointer. TCP does not have out of band data. The SO_OOBINLINE option was added so that new applications (new, circa 1989, the date of RFC 1122) could turn this broken interface off and leave the data in the data stream where it belongs. It was felt that we couldn't just change the BSD TCP implementation to the new behavior, because that would break all the existing applications. With SO_OOBINLINE, applications could switch over without there needing to be a flag day. > Secondly, virtually all implementations intepret that the Urgent > pointer point to the byte following the last byte of urgent data. > And this is what RFC 1122 aims at correcting. (However, this > correction didn't reflect into actual implementations.) > > >> It is >> up to the application to decide what that means, and which data >> relative to the urgent pointer is interesting, but typically it would >> be the data just after the urgent pointer. The application can't say >> "these x bytes of data are the urgent data". > > mmm... why couldn't it say, e.g., that all the bytes up to the > urgent pointer are urgent data? (currently, only the byte before the > Urgent Pointer is interpreted as Urgent data... which does not seem > to agree with what the RFCs specify....) The RFC more or less does say that. The moment you get a packet with the URG bit, you enter urgent mode for all data until you get past the urgent pointer, hence that is all urgent data. The key things are: 1) The urgent pointer only tells you where the urgent data ends 2) Urgent pointers are cumulative, a new urgent pointer updates where you leave urgent mode. 3) The urgent pointer can point beyond the data in the packet in which it is sent. The problem is that (most of) the urgent data, as defined in RFC 793, is typically the uninteresting data. For example, in telnet the urgent data is the data you want to read and flush, until you get to the Telnet Sync command. >> If a TCP data stream writes some data in normal mode and the data >> gets >> lost, then there is a successive write in urgent mode, then when the >> lost packet is re-transmitted it'll now be transmitted with the URG >> bit and the urgent pointer, turning that data into "urgent data" by >> the 793 definition. That's not what people think when they first >> hear >> the term "urgent data", but that's how it works. > > Agreed. > > >> it to the application out-of-band. To fix that, the SO_OOBINLINE >> socket option was introduced, and is still around today. All >> applications that use urgent data should be using the SO_OOBINLINE >> option, there's no excuse for using the old, broken BSD >> interpretation >> about urgent data. > > Well, this seems to be the default for all major TCP implementations > (see our survey). Ok, there are two issues here. First, SO_OOBINLINE turns off the old, broken BSD interpretation that removed a byte of data from the data stream and presented it to the application with the recv()/MSG_OOB call. The second issue is which byte is indicated in the packet with the urgent pointer. If the application knows what the kernel does, it can adjust accordingly so that the correct byte gets marked in the TCP data stream. >> There isn't anything wrong with the 793/1122 definition of the Urgent >> Pointer. > > The specific issue we are discussing is that the Urgent pointer is > defined in RFC 793 as pointing "to the byte following the last byte > of urgent data". RFC 1122 later corrected this definitation, stating > that it points to "the last byte of urgent data". That's why I said 793/1122. RFC 793 defined it both ways, and in RFC 1122 we clarified that the definition on page 56 is correct, and the one on page 17 is wrong. >> It might be useful to clarify the description if people are >> still implementing and/or using it wrong, but the definition in >> 793/1122 is still correct. > > Section 4.2.2.4 of RFC 1122 states: > "The second sentence is in error: the urgent pointer points > to the sequence number of the LAST octet (not LAST+1) in a > sequence of urgent data. The description on page 56 (last > sentence) is correct." > > This is where I'm saying that RFC 1122 differs from RFC 793. Yes, of course. RFC 1122 says that this definition is wrong. In RFC 793 the urgent pointer is also defined on page 56: If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the urgent pointer in the outgoing segments. which conflicts with the definition on page 17. RFC 1122 clarifies that this definition on page 56 is the correct definition. I'll also point out that RFC 961 also says that the definition on page 17 is wrong; RFC 1122 re-enforces what was already documented. I will say that using the recv()/MSG_OOB interface is the bigger issue. You just have to look at the BSD Telnet implementation and the dances that it does if SO_OOBINLINE isn't defined to understand why that broken interface is such a bad idea. -David Borman > > > Thanks! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Oct 27 23:21:15 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C460A3A6BBA; Mon, 27 Oct 2008 23:21:15 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86EA43A6BCD for ; Mon, 27 Oct 2008 23:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wMamFXEWYIw for ; Mon, 27 Oct 2008 23:21:13 -0700 (PDT) Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id 6B9FD3A6803 for ; Mon, 27 Oct 2008 23:21:13 -0700 (PDT) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m9S6L82t017274; Tue, 28 Oct 2008 08:21:08 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m9S6L7hj017271; Tue, 28 Oct 2008 08:21:08 +0200 Date: Tue, 28 Oct 2008 08:21:07 +0200 (EET) From: Pekka Savola To: Adam Langley In-Reply-To: <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> Message-ID: References: <396556a20810271015s636f0585p41e413c4c37888e0@mail.gmail.com> <3C4D15BA-30EE-4CF6-85BE-B945BC995D14@nokia.com> <396556a20810271152h21cd0eb6s9fff99e629c0c17e@mail.gmail.com> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 X-Virus-Scanned: ClamAV 0.94/8516/Tue Oct 28 00:33:09 2008 on otso.netcore.fi X-Virus-Status: Clean Cc: tcpm@ietf.org Subject: Re: [tcpm] Beware the ordering of TCP options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org On Mon, 27 Oct 2008, Adam Langley wrote: > On Mon, Oct 27, 2008 at 11:07 AM, Lars Eggert wrote: >> Could you clarify if by "routers" you mean IP routers or cable/DSL modems? > > It's not clear. The only source of information that I have are the > user bug reports listed above. Certainly some "consumer > moderm"/NAT/wireless access point type of hardware broke. However, > there were also a number of reports of Verizon DSL breaking with some > diversity of consumer modems so it may be that something bigger broke > there. My guess would be a large percentage of routers (mainly in CPE market but maybe larger as well) which implement MSS inspection and clamping mechanisms. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Oct 28 19:27:32 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796323A68A0; Tue, 28 Oct 2008 19:27:32 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC7F3A68A0 for ; Tue, 28 Oct 2008 19:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPEEDY_AR=0.808] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzRYZhmzdufn for ; Tue, 28 Oct 2008 19:27:30 -0700 (PDT) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9F5E83A676A for ; Tue, 28 Oct 2008 19:27:28 -0700 (PDT) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 2665E6B6590; Tue, 28 Oct 2008 23:27:32 -0300 (ART) Received: from notebook.gont.com.ar (201-254-27-192.speedy.com.ar [201.254.27.192] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m9T2RAHQ001594; Wed, 29 Oct 2008 00:27:11 -0200 Message-Id: <200810290227.m9T2RAHQ001594@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Oct 2008 23:21:04 -0300 To: David Borman From: Fernando Gont In-Reply-To: <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> Mime-Version: 1.0 X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 28 Oct 2008 23:27:30 -0300 (ART) Cc: tcpm@ietf.org, ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org At 02:42 a.m. 28/10/2008, David Borman wrote: >>Firstly, the recv(2) with MSG_OOB only returns a single byt of >>urgent data, whereas according to your explanation it should return >>all data prior to, and including, the Urgent pointer. > >No, applications shouldn't be using recv() with MSG_OOB on TCP >sockets. That is the interface for the old, broken BSD interpretation >of the urgent pointer. TCP does not have out of band data. The >SO_OOBINLINE option was added so that new applications (new, circa >1989, the date of RFC 1122) could turn this broken interface off and >leave the data in the data stream where it belongs. By default, the byte pointer byte (UP-1) is till kept OOB, nowadays. Even worse, it has been reported to me that some major operating system did things even worse: it would queue what it thought was urgent data until the application read it by a recv(")/MSG_OOBB-like call. If the app didn't recv() this "OOB", then the urg data would pile up, until a DoS condition.... > It was felt that >we couldn't just change the BSD TCP implementation to the new >behavior, because that would break all the existing applications. >With SO_OOBINLINE, applications could switch over without there >needing to be a flag day. I believe this should be clarified. Do you? I will prepare some text to update our draft before the non-00-version deadline.... >>>it to the application out-of-band. To fix that, the SO_OOBINLINE >>>socket option was introduced, and is still around today. All >>>applications that use urgent data should be using the SO_OOBINLINE >>>option, there's no excuse for using the old, broken BSD >>>interpretation >>>about urgent data. >> >>Well, this seems to be the default for all major TCP implementations >>(see our survey). > >Ok, there are two issues here. First, SO_OOBINLINE turns off the old, >broken BSD interpretation that removed a byte of data from the data >stream and presented it to the application with the recv()/MSG_OOB >call. Agreed. I believe this should be clarified. >The second issue is which byte is indicated in the packet with >the urgent pointer. If the application knows what the kernel does, it >can adjust accordingly so that the correct byte gets marked in the TCP >data stream. Not sure what you mean. The issue here is how the *remote* TCP sets the urgent pointer. How could you know whether the remote TCP set the UP such that it points to the last byte of urgent data (RFC1122) or to the byte following the last byte of urgent data? Considering that even SO_OOBINLINE doesn't change the semantics of the UP, I think RFC 1122 could be updated to reflect what current implementations are doing. (this is one of the "updates" that our draft was aiming) >I will say that using the recv()/MSG_OOB interface is the bigger >issue. You just have to look at the BSD Telnet implementation and the >dances that it does if SO_OOBINLINE isn't defined to understand why >that broken interface is such a bad idea. So we have to issues: * Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which you seem to agree) * Update RFC 793/RFC1122 wrt where the UP points to, to reflect what everybody does and has been doing. (with which I don't know whether you agree or not). Please let me know what you think, so that we can update our draft accordingly. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Oct 29 08:30:11 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124ED3A690E; Wed, 29 Oct 2008 08:30:11 -0700 (PDT) X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 065643A68DB for ; Wed, 29 Oct 2008 08:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQs5U-byazSB for ; Wed, 29 Oct 2008 08:30:08 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C84FF3A690E for ; Wed, 29 Oct 2008 08:30:08 -0700 (PDT) Received: from [192.168.1.45] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m9TFTQGD008107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Oct 2008 08:29:28 -0700 (PDT) Message-ID: <49088156.6020305@isi.edu> Date: Wed, 29 Oct 2008 08:29:26 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fernando Gont References: <200810280000.m9S00h4E029878@venus.xmundo.net> <200810280203.m9S23foZ023071@venus.xmundo.net> <523175BF-A76B-4A4C-B726-AE4274BE9A44@windriver.com> <200810290227.m9T2RAHQ001594@venus.xmundo.net> In-Reply-To: <200810290227.m9T2RAHQ001594@venus.xmundo.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, David Borman , ayourtch@cisco.com Subject: Re: [tcpm] Fwd: New Version Notification for draft-gont-tcpm-urgent-data-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: ... > So we have to issues: > > * Deprecate recv(2)/MSG_OOB and encourage SO_OOBINLINE. (with which you > seem to agree) That sounds like a Unix man page update, not an RFC. > * Update RFC 793/RFC1122 wrt where the UP points to, to reflect what > everybody does and has been doing. (with which I don't know whether you > agree or not). Either this is an implementation error or it updates our definition of PUSH. If the former, it can be noted in the next version of the TCP implementation errors doc. If the latter, it would update 1122 - NOT 793. As Dave noted, 1122 supercedes 793 on this issue. I don't like the idea of continuing to document implementations that do not comply with current specs without either stating a) this is BAD and should be fixed b) this is GOOD and we're changing our spec FWIW, so far, this looks to me like an implementation error, not a reason to change the spec. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkIgVYACgkQE5f5cImnZrsmjwCfU0E45TefTK2VfZzdhBeLNkhT sV4AniB+V8YKrYCiWTSw5wWY1CzLCVma =v9/G -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Oct 30 02:15:04 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3976B28C20B; Thu, 30 Oct 2008 02:15:04 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2BF7A3A67D0; Thu, 30 Oct 2008 02:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081030091502.2BF7A3A67D0@core3.amsl.com> Date: Thu, 30 Oct 2008 02:15:02 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] I-D Action:draft-ietf-tcpm-rfc4138bis-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP Author(s) : P. Sarolahti, et al. Filename : draft-ietf-tcpm-rfc4138bis-04.txt Pages : 21 Date : 2008-10-30 The purpose of this document is to move the F-RTO functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F- RTO support for SCTP in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138. Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tcpm-rfc4138bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-30020023.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --NextPart-- From tcpm-bounces@ietf.org Thu Oct 30 06:59:50 2008 Return-Path: X-Original-To: tcpm-archive@megatron.ietf.org Delivered-To: ietfarch-tcpm-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FAA3A69FA; Thu, 30 Oct 2008 06:59:50 -0700 (PDT) X-Original-To: tcpm@ietf.org Delivered-To: tcpm@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5EA5F3A6987; Thu, 30 Oct 2008 06:59:49 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081030135949.5EA5F3A6987@core3.amsl.com> Date: Thu, 30 Oct 2008 06:59:49 -0700 (PDT) Cc: tcpm@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-rfc4138bis (Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: tcpm-bounces@ietf.org Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP ' as a Proposed Standard 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 2008-11-13. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc4138bis-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16094&rfc_flag=0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm