From tcpm-bounces@ietf.org Fri Mar 03 05:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7cT-0006jG-8k; Fri, 03 Mar 2006 05:34:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7cS-0006f1-GE for tcpm@ietf.org; Fri, 03 Mar 2006 05:34:44 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF7cR-0006ki-Mk for tcpm@ietf.org; Fri, 03 Mar 2006 05:34:44 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EEF3E4F0044 for ; Fri, 3 Mar 2006 11:34:42 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:34:42 +0100 Received: from eed.ericsson.se ([164.48.133.33]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 11:34:42 +0100 Received: from [164.48.135.211] (dhcp5-211.eed.ericsson.se [164.48.135.211]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id LAA07828 for ; Fri, 3 Mar 2006 11:34:42 +0100 (MET) Message-ID: <44081BC2.9050509@ericsson.com> Date: Fri, 03 Mar 2006 11:34:42 +0100 From: Reiner Ludwig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-roadmap-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Mar 2006 10:34:42.0344 (UTC) FILETIME=[14F48A80:01C63EAE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Hi, one comment ... The I-D says: RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) This document [RFC3522] suggests using timestamps to detect spurious timeouts. Please change to: RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) This document [RFC3522] suggests using timestamps to detect when loss recovery has been spuriously entered. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ///Reiner Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : A Roadmap for TCP Specification Documents > Author(s) : M. Duke, et al. > Filename : draft-ietf-tcpm-tcp-roadmap-06.txt > Pages : 42 > Date : 2006-2-28 > > This document contains a "roadmap" to the Requests for Comments (RFC) > documents relating to the Internet's Transmission Control Protocol > (TCP). This roadmap provides a brief summary of the documents > defining TCP and various TCP extensions that have accumulated in the > RFC series. This serves as a guide and quick reference for both TCP > implementers and other parties who desire information contained in > the TCP-related RFCs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-tcpm-tcp-roadmap-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Mar 07 14:27:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhps-0000s2-NQ; Tue, 07 Mar 2006 14:27:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGhpr-0000rx-DG for tcpm@ietf.org; Tue, 07 Mar 2006 14:27:07 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGhpq-00085M-2o for tcpm@ietf.org; Tue, 07 Mar 2006 14:27:07 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k27JQvpN026690; Tue, 7 Mar 2006 11:26:57 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id D2A9877AB77; Tue, 7 Mar 2006 14:26:55 -0500 (EST) To: Reiner Ludwig From: Mark Allman Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-roadmap-06.txt In-Reply-To: <44081BC2.9050509@ericsson.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Heavy Fuel MIME-Version: 1.0 Date: Tue, 07 Mar 2006 14:26:55 -0500 Message-Id: <20060307192655.D2A9877AB77@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0339786129==" Errors-To: tcpm-bounces@ietf.org --===============0339786129== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Reiner- > one comment ... The document is in the IESG's hands now and this comment isn't significant enough that we really want to yank it back and rev it while they are working on it. We have asked Jon (& the IESG) to consider asking the RFC editor to clarify the words when they forward the document. Given the nature of the change and the lateness of the request, that seems like the best approach. Thanks, allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFEDd5/WyrrWs4yIs4RAsogAJ0VLz+sRoD1/Ir2l0e9icb6ba/BqgCeM7IY aX1A3COZ889+Axx/xZ5iag4= =35LQ -----END PGP SIGNATURE----- --=_bOundary-- --===============0339786129== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0339786129==-- From tcpm-bounces@ietf.org Tue Mar 07 15:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiSn-0000sS-KP; Tue, 07 Mar 2006 15:07:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGiSl-0000qd-Fe for tcpm@ietf.org; Tue, 07 Mar 2006 15:07:19 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGiSj-0000i0-Oq for tcpm@ietf.org; Tue, 07 Mar 2006 15:07:19 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 966C73B6; Tue, 7 Mar 2006 21:07:16 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 21:07:16 +0100 Received: from eed.ericsson.se ([164.48.133.33]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Mar 2006 21:07:16 +0100 Received: from [164.48.139.7] ([164.48.139.7]) by eed.ericsson.se (8.8.8p2+Sun/1.1.mit) with ESMTP id VAA07518; Tue, 7 Mar 2006 21:07:14 +0100 (MET) Message-ID: <440DE7F2.8050802@ericsson.com> Date: Tue, 07 Mar 2006 21:07:14 +0100 From: Reiner Ludwig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mallman@icir.org Subject: Re: [tcpm] I-D ACTION:draft-ietf-tcpm-tcp-roadmap-06.txt References: <20060307192655.D2A9877AB77@guns.icir.org> In-Reply-To: <20060307192655.D2A9877AB77@guns.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Mar 2006 20:07:16.0207 (UTC) FILETIME=[BB1B07F0:01C64222] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org OK. Since it's such a small incompleteness, I guess, it could also be fixed during the authors' 48 hours call. Sorry for the lateness. On the other hand, a copy/paste of the first 2-3 sentences of the RFC3522 abstract would have done the job. ///Reiner Mark Allman wrote: > Reiner- > > >>one comment ... > > > The document is in the IESG's hands now and this comment isn't > significant enough that we really want to yank it back and rev it while > they are working on it. We have asked Jon (& the IESG) to consider > asking the RFC editor to clarify the words when they forward the > document. Given the nature of the change and the lateness of the > request, that seems like the best approach. > > Thanks, > allman > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 09 14:59:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRII-0003mM-P1; Thu, 09 Mar 2006 14:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRIH-0003mH-KO for tcpm@ietf.org; Thu, 09 Mar 2006 14:59:29 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRIG-0005hH-Dx for tcpm@ietf.org; Thu, 09 Mar 2006 14:59:29 -0500 Received: from [128.237.236.170] (CMU-168400.WV.CC.cmu.edu [128.237.236.170]) (authenticated bits=0) by mailer2.psc.edu (8.13.4/8.13.3) with ESMTP id k29JxJfT010668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 14:59:22 -0500 (EST) Message-ID: <44108927.3060600@psc.edu> Date: Thu, 09 Mar 2006 14:59:35 -0500 From: John Heffner User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tcpm@ietf.org Subject: [tcpm] comment on rfc2581bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org One question: Why is the MAY changed to a SHOULD in "The initial value of ssthresh SHOULD be arbitrarily high (for example, some implementations use the size of the advertised window)"? A SHOULD doesn't quite make sense to me there. It seems like it would require something more definite than an "arbitrarily high" value. Also, I like the indefiniteness of the MAY, since implementations can have any number of reasons to use various ssthresh values for different connections. (For example, they may have some out-of-band information about the path, or use cached parameters from a previous connection.) Incidentally, I'd actually like to see the phrase in parentheses removed. I think setting ssthresh to rwin is almost certainly not a good idea, as implementations (e.g., linux) don't always advertise their maximum possible rwin right away. Thanks, -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 09 15:31:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRmr-0007Rn-K8; Thu, 09 Mar 2006 15:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRmq-0007Pq-2w for tcpm@ietf.org; Thu, 09 Mar 2006 15:31:04 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHRmo-0006kb-SX for tcpm@ietf.org; Thu, 09 Mar 2006 15:31:04 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer1.psc.edu (8.13.4/8.13.3) with ESMTP id k29KUwpM016805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Mar 2006 15:30:58 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.12.10) with ESMTP id k29KUwrj020202; Thu, 9 Mar 2006 15:30:58 -0500 Date: Thu, 9 Mar 2006 15:30:58 -0500 (EST) From: Matt Mathis To: John Heffner Subject: Re: [tcpm] comment on rfc2581bis In-Reply-To: <44108927.3060600@psc.edu> Message-ID: References: <44108927.3060600@psc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: eblanton@cs.purdue.edu, tcpm@ietf.org, Vern Paxson , Mark Allman X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Incidentally, I'd actually like to see the phrase in parentheses > removed. I think setting ssthresh to rwin is almost certainly not a > good idea, as implementations (e.g., linux) don't always advertise their > maximum possible rwin right away. John is being gracious: If the receiver is doing autotuning, as does Linux (and we are told Vista as well), setting ssthresh to the advertised window guarantees seriously sub-optimal performance. It is not unreasonable to set ssthresh to the maximum permitted by the receiver's window scale. Does this qualify an a editorial change? Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 09 23:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZgX-00081c-17; Thu, 09 Mar 2006 23:57:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZgV-00081X-VF for tcpm@ietf.org; Thu, 09 Mar 2006 23:57:03 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZgU-0008Gm-Gk for tcpm@ietf.org; Thu, 09 Mar 2006 23:57:03 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2A4uv2t086375; Thu, 9 Mar 2006 20:56:57 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 22EFC77ACAD; Thu, 9 Mar 2006 23:56:55 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 25F4B3DA2E5; Thu, 9 Mar 2006 23:56:10 -0500 (EST) To: John Heffner From: Mark Allman In-Reply-To: <44108927.3060600@psc.edu> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Born to Run MIME-Version: 1.0 Date: Thu, 09 Mar 2006 23:56:09 -0500 Message-Id: <20060310045610.25F4B3DA2E5@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: eblanton@cs.purdue.edu, tcpm@ietf.org, vern@icir.org Subject: [tcpm] Re: comment on rfc2581bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0023984489==" Errors-To: tcpm-bounces@ietf.org --===============0023984489== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline John- Thanks for the note! > One question: Why is the MAY changed to a SHOULD in "The initial > value of ssthresh SHOULD be arbitrarily high (for example, some > implementations use the size of the advertised window)"? A SHOULD > doesn't quite make sense to me there. It seems like it would > require something more definite than an "arbitrarily high" value. > Also, I like the indefiniteness of the MAY, since implementations > can have any number of reasons to use various ssthresh values for > different connections. (For example, they may have some out-of-band > information about the path, or use cached parameters from a previous > connection.) It seems to me like SHOULD is right here and in my mind you are describing a "SHOULD" above. I.e., unless you have a good reason you really ought to use a very large initial ssthresh such that the network dictates when slow start ends and some arbitrary limit is not imposed. E.g., some hosts have been known to set ssthresh to 64KB ... which was infinity at one point, but no longer is. If I remember correctly, I believe that such notions fueled the comments that made us re-think the word choice. I think your examples are nice and am inclined to think SHOULD is right, but that we goofed in not calling out cases whereby one might not want to take the advice of the SHOULD. > Incidentally, I'd actually like to see the phrase in parentheses > removed. I think setting ssthresh to rwin is almost certainly not a > good idea, as implementations (e.g., linux) don't always advertise > their maximum possible rwin right away. Yep, good catch. I think this is a case whereby the world has moved past that advice and that example is actually not correct any more. I like Matt's subsequent sketch of setting ssthresh to the maximum advertised window allowed by the current window scale. That would seem like a good basis for a replacement example. Thoughts? (From anyone, obviously.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEEQbpWyrrWs4yIs4RAimTAJ9fz4ehJYgym1rXycDNTfg39DwjWgCeK5f/ 02cFIIVjuAN6ZM0//FHiQiY= =YUsu -----END PGP SIGNATURE----- --=_bOundary-- --===============0023984489== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0023984489==-- From tcpm-bounces@ietf.org Thu Mar 16 16:51:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Nv-0005Ic-LR; Thu, 16 Mar 2006 16:51:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK0Nu-0005IQ-Oq for tcpm@ietf.org; Thu, 16 Mar 2006 16:51:54 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK0Nt-0002Jl-Fz for tcpm@ietf.org; Thu, 16 Mar 2006 16:51:54 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Mar 2006 13:51:53 -0800 X-IronPort-AV: i="4.02,198,1139212800"; d="scan'208"; a="262420514:sNHT28990864" Received: from [128.107.163.101] (dhcp-128-107-163-101.cisco.com [128.107.163.101]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2GLpqYg029331 for ; Thu, 16 Mar 2006 13:51:52 -0800 (PST) Message-ID: <4419DDF9.2010006@cisco.com> Date: Thu, 16 Mar 2006 13:51:53 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] draft-weis-tcp-auth-auto-ks-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Greetings, The TCP Extended Authentication draft (draft-bonica-tcp-auth-04.txt) describes key lists, where keys are manually added to the key lists. There are operational and security advantages for TCP endpoints automatically deriving TCP Extended Authentication session keys. The following draft proposes a light-weight mechanism for automatically deriving these keys. http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto-ks-00.txt The abstract in the I-D says: This memo describes an automated key selection extension for the TCP [RFC0793] authentication option [I-D.bonica-tcp-auth]. This key selection extension allows two TCP endpoints to authenticate TCP segments using a Message Authentication Code (MAC) key chosen dynamically by an endpoint, rather than using a pre-configured MAC key. Comments are appreciated. Thanks, Brian -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 16 22:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK5om-0007a2-Gc; Thu, 16 Mar 2006 22:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK5ol-0007YU-Ic for tcpm@ietf.org; Thu, 16 Mar 2006 22:39:59 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK5ok-0006Lf-7t for tcpm@ietf.org; Thu, 16 Mar 2006 22:39:59 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2H3duCR049153 for ; Thu, 16 Mar 2006 19:39:57 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 3465B77AD89 for ; Thu, 16 Mar 2006 22:39:54 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 009A73E08F7 for ; Thu, 16 Mar 2006 22:39:07 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Drift Away MIME-Version: 1.0 Date: Thu, 16 Mar 2006 22:39:07 -0500 Message-Id: <20060317033907.009A73E08F7@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [tcpm] tcpm agenda for next week X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1853032829==" Errors-To: tcpm-bounces@ietf.org --===============1853032829== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline We convene on Monday to talk about a few things. We have extra time, so if anyone has anything else that needs talking about let me know. allman TCP - IETF 65 Dallas, TX 20 Mar 2006 * Agenda bashing * Chair comments 10 mins - Mark Allman * TCP authentication and encryption * Ron Bonica - 15 minutes - draft-bonica-tcp-auth-04.txt * Brian Weis - 15 minutes - draft-weis-tcp-auth-auto-ks-00.txt * Old business * Lars Eggert - UTO - 10 Minutes - draft-ietf-tcpm-tcp-uto-02.txt * Joe Touch - 10 minutes - draft-ietf-tcpm-tcp-antispoof-03.txt * New business * Mark Allman - 10 minutes - 2581 update --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEGi9bWyrrWs4yIs4RAnUgAJ93Ocow3Jvz5P35UXjtRHpRnQcWkACcCEIF 9QEe8YailTc5pHZhfN+rPds= =JF0c -----END PGP SIGNATURE----- --=_bOundary-- --===============1853032829== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1853032829==-- From tcpm-bounces@ietf.org Fri Mar 17 12:20:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIcx-0008Qx-NR; Fri, 17 Mar 2006 12:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKIcw-0008Qs-GC for tcpm@ietf.org; Fri, 17 Mar 2006 12:20:38 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKIcv-0006fN-2j for tcpm@ietf.org; Fri, 17 Mar 2006 12:20:38 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2HHKZr8061957 for ; Fri, 17 Mar 2006 09:20:36 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 6258177B042 for ; Fri, 17 Mar 2006 12:20:34 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Who Are You MIME-Version: 1.0 Date: Fri, 17 Mar 2006 12:20:34 -0500 Message-Id: <20060317172034.6258177B042@guns.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [tcpm] updated agenda X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0465361000==" Errors-To: tcpm-bounces@ietf.org --===============0465361000== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline I have updated the agenda for Monday a bit. It is attached. Please throw these drafts in your carryon so we can have a good discussion. allman .Agenda bashing .WG status .TCP authentication and encryption .draft-bonica-tcp-auth-04.txt - Bonica (15 min) .draft-weis-tcp-auth-auto-ks-00.txt - Weis (15 min) .UTO: draft-ietf-tcpm-tcp-uto-02.txt - Eggert (10 min) .2581bis: draft-ietf-tcpm-rfc2581bis-00.txt - Allman (10 min) .ECN-SYN: draft-ietf-tcpm-ecnsyn-00.txt - Floyd (15-20 min) .Anti-Spoof: draft-ietf-tcpm-tcp-antispoof-03.txt - Touch (10 min) --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGu/iWyrrWs4yIs4RAjnpAJ9rNlV30p6X8F+qFSo/q/7Mu+d8vwCgjB2R 5/wM4waNuQsDiHvFkUyEezw= =f0/w -----END PGP SIGNATURE----- --=_bOundary-- --===============0465361000== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0465361000==-- From tcpm-bounces@ietf.org Fri Mar 17 13:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJXM-0005KM-Dg; Fri, 17 Mar 2006 13:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJXK-0005KH-HV for tcpm@ietf.org; Fri, 17 Mar 2006 13:18:54 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJXK-0000BK-6E for tcpm@ietf.org; Fri, 17 Mar 2006 13:18:54 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 7FF11C269 for ; Fri, 17 Mar 2006 13:18:53 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k2HIIr3C028632 for ; Fri, 17 Mar 2006 13:18:53 -0500 (EST) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k2HIIqWe004322 for ; Fri, 17 Mar 2006 13:18:52 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k2HIImOq004278 for ; Fri, 17 Mar 2006 13:18:48 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 688354FE3A; Fri, 17 Mar 2006 13:17:54 -0500 (EST) Date: Fri, 17 Mar 2006 13:17:54 -0500 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20060317181754.GD27410@grc.nasa.gov> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [tcpm] small bit on ecnsyn-00 and syn cookies X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684036846==" Errors-To: tcpm-bounces@ietf.org --===============1684036846== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw" Content-Disposition: inline --jy6Sn24JjFx/iggw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just a slight bit more discussion of syn cookies is required in the ecnsyn draft as it stands. The issue is that the listening (cookie-generating) host doesn't keep a TCB for the connection, so it doesn't keep an ecn-capable bit set for the connection. With current algorithms for generating the cookie, the ECN bit doesn't factor in, so it is not recovered into the rebuilt TCB when the listener gets the ACK. So if ECN signalling is to be used for the connection (and for the SYN-ACK segment), the listening host has a couple of options: 1) Incorporate the ECN-capable bit into the cookie, so that it can be recovered. 2) Infer the ECN-capability of the connection from either of the ECT codepoints in the IP-header on the ACK. If none of these mechanisms are in the host (which they currently aren't) then a host that uses syn cookies can't use ECN for the SYN-ACK. I guess this issue is not really specific to the ecnsyn draft, but moreso to the general combination of syn cookies and ECN. If that combination were defined, then ecnsyn and syn cookies would have no friction. I could add some text to the draft on syn flooding and defenses to address this, if it = is desirable: http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-01.txt -Wes --=20 Wesley M. Eddy Verizon Federal Network Systems --jy6Sn24JjFx/iggw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEGv1RzBuYqbnj3IwRAoS0AJ4+xfllvp5bM4uDzCzKsFQ32v7W6gCfWOvA Q0GN/qeJlU05l8LnaN9NkPs= =ABBH -----END PGP SIGNATURE----- --jy6Sn24JjFx/iggw-- --===============1684036846== 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://www1.ietf.org/mailman/listinfo/tcpm --===============1684036846==-- From tcpm-bounces@ietf.org Fri Mar 17 13:33:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJli-0001Rk-4P; Fri, 17 Mar 2006 13:33:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJlh-0001H3-0b for tcpm@ietf.org; Fri, 17 Mar 2006 13:33:45 -0500 Received: from mailer2.psc.edu ([128.182.66.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJlf-0000Zr-Mz for tcpm@ietf.org; Fri, 17 Mar 2006 13:33:44 -0500 Received: from tesla.psc.edu (tesla.psc.edu [128.182.61.233]) by mailer2.psc.edu (8.13.4/8.13.3) with ESMTP id k2HIXcwx001894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 13:33:38 -0500 (EST) Received: from localhost.psc.edu (localhost.psc.edu [127.0.0.1]) by tesla.psc.edu (8.13.1/8.12.10) with ESMTP id k2HIXcqr000509; Fri, 17 Mar 2006 13:33:38 -0500 Date: Fri, 17 Mar 2006 13:33:38 -0500 (EST) From: Matt Mathis To: Wesley Eddy Subject: Re: [tcpm] small bit on ecnsyn-00 and syn cookies In-Reply-To: <20060317181754.GD27410@grc.nasa.gov> Message-ID: References: <20060317181754.GD27410@grc.nasa.gov> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org A TCP implementation that uses syn-cookies is technically "non-compliant" - for that reason many (most?) stacks use some sort of light weight "embryonic" TCB instead. It can be fully protocol compliant, and provides essentially the same protection from syn floods. I would prefer not do design ECN signaling around problems that exist only for non-compliant implementations. Their implementors have more direct methods to solve the problem. Thanks, --MM-- ------------------------------------------- Matt Mathis http://www.psc.edu/~mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by people who think they know "The Truth" and use force to apply it to others. On Fri, 17 Mar 2006, Wesley Eddy wrote: > Just a slight bit more discussion of syn cookies is required in the > ecnsyn draft as it stands. > > The issue is that the listening (cookie-generating) host doesn't keep a > TCB for the connection, so it doesn't keep an ecn-capable bit set for > the connection. With current algorithms for generating the cookie, the > ECN bit doesn't factor in, so it is not recovered into the rebuilt TCB > when the listener gets the ACK. > > So if ECN signalling is to be used for the connection (and for the > SYN-ACK segment), the listening host has a couple of options: > > 1) Incorporate the ECN-capable bit into the cookie, so that it can be > recovered. > > 2) Infer the ECN-capability of the connection from either of the ECT > codepoints in the IP-header on the ACK. > > If none of these mechanisms are in the host (which they currently aren't) > then a host that uses syn cookies can't use ECN for the SYN-ACK. > > I guess this issue is not really specific to the ecnsyn draft, but moreso > to the general combination of syn cookies and ECN. If that combination were > defined, then ecnsyn and syn cookies would have no friction. I could add > some text to the draft on syn flooding and defenses to address this, if it is > desirable: > http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-01.txt > > -Wes > > -- > Wesley M. Eddy > Verizon Federal Network Systems > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 17 13:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJwE-0000yr-Lc; Fri, 17 Mar 2006 13:44:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJwD-0000vC-2c for tcpm@ietf.org; Fri, 17 Mar 2006 13:44:37 -0500 Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKJwB-0000pH-R6 for tcpm@ietf.org; Fri, 17 Mar 2006 13:44:37 -0500 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 5F4DCC29D for ; Fri, 17 Mar 2006 13:44:35 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id k2HIiY3C004321; Fri, 17 Mar 2006 13:44:35 -0500 (EST) Received: from apataki.grc.nasa.gov (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k2HIiYN4020189; Fri, 17 Mar 2006 13:44:34 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id k2HIiXRb020174; Fri, 17 Mar 2006 13:44:33 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 46CAE4FE3A; Fri, 17 Mar 2006 13:43:39 -0500 (EST) Date: Fri, 17 Mar 2006 13:43:39 -0500 From: Wesley Eddy To: Matt Mathis Subject: Re: [tcpm] small bit on ecnsyn-00 and syn cookies Message-ID: <20060317184339.GG27410@grc.nasa.gov> References: <20060317181754.GD27410@grc.nasa.gov> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0147626999==" Errors-To: tcpm-bounces@ietf.org --===============0147626999== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 17, 2006 at 01:33:38PM -0500, Matt Mathis wrote: > A TCP implementation that uses syn-cookies is technically "non-compliant"= - for > that reason many (most?) stacks use some sort of light weight "embryonic"= TCB > instead. It can be fully protocol compliant, and provides essentially th= e same > protection from syn floods. I believe you're referring to what is commonly called a syn cache. =20 > I would prefer not do design ECN signaling around problems that exist onl= y for > non-compliant implementations. Their implementors have more direct metho= ds to > solve the problem. > The changes I mentioned only apply to the "non-compliant" host, and do not affect the design of the ECN signaling. -Wes=20 --=20 Wesley M. Eddy Verizon Federal Network Systems --xA/XKXTdy9G3iaIz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEGwNazBuYqbnj3IwRAujzAJ9DZkSr/hT0CIsEc/Jl9WkXz3RX4gCfZzWn Vpuuw9mV/idNsCGwF+sK6fI= =5+OY -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz-- --===============0147626999== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0147626999==-- From tcpm-bounces@ietf.org Fri Mar 17 15:46:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLqc-0006dR-2s; Fri, 17 Mar 2006 15:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKLqb-0006dM-KF for tcpm@ietf.org; Fri, 17 Mar 2006 15:46:57 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKLqZ-0004pu-Dd for tcpm@ietf.org; Fri, 17 Mar 2006 15:46:57 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FKLqO-0005PG-00; Fri, 17 Mar 2006 15:46:44 -0500 From: Tim Shepard To: mallman@icir.org Subject: Re: [tcpm] updated agenda In-reply-to: Your message of Fri, 17 Mar 2006 12:20:34 -0500. <20060317172034.6258177B042@guns.icir.org> Date: Fri, 17 Mar 2006 15:46:44 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Unfortunate that tcpm is scheduled in the same slot as btns *and* intarea. 3-way conflict for me, and I imagine at least a 2-way conflict for many regular tcpm attendees. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 17 17:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKNO5-000847-0k; Fri, 17 Mar 2006 17:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKNO3-000842-IJ for tcpm@ietf.org; Fri, 17 Mar 2006 17:25:35 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKNO2-00082q-4t for tcpm@ietf.org; Fri, 17 Mar 2006 17:25:35 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2HMOEG26568; Fri, 17 Mar 2006 14:24:14 -0800 (PST) Message-ID: <441B3696.3040103@isi.edu> Date: Fri, 17 Mar 2006 14:22:14 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tcpm@ietf.org References: <4419DDF9.2010006@cisco.com> In-Reply-To: <4419DDF9.2010006@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [tcpm] regarding the TCP/MD5 updates X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, There are three documents that currently propose changes to TCP/MD5: draft-weis-tcp-auth-auto-ks draft-weis-tcp-mac-option draft-bonica-tcp-auth Due to some extraordinary scheduling, I will not be able to participate in TCPM when these are discussed, so I figured I'd post my comments in advance. I've read the three, and my general impression (intended to be simplistic) is that all three extend TCP/MD5 (RFC2385) as follows: draft-weis-tcp-mac-option provides for 4 other MACs, all HMACs (superset of draft-bonica) provides for in-band *rekeying* uses the key as 'direct input' to the HMAC, rather than as part of the digest draft-weis-tcp-auth-auto-ks describes the specific mechanism for inband rekeying as spected in weis-tcp-mac draft-bonica-tcp-auth provides for two other MACs, both HMACs provides for time-based key rollover this seems like a bad idea, and appears to be based on the need to rekey I sincerely hope that the authors of these documents can get together and document a single, coherent solution. MY requirements for that would be: - clear delineation between these and 2385 I would prefer reuse of option 19 (2385) with use of a different length (where 18 refers to the depricated 2385 version); this would ensure that the new TCP auth could not be used where TCP/MD5 is used, and would avoid unncessary waste of TCP option space - initial session key establishment needs to be addressed - algorithm/parameter establishment/agreement needs to be addressed - I prefer the Weis' IKE-style rekeying to Bonica's time-based keys, since the former maps better to TCP semantics and would be simpler and more secure to implement (see below) I would be glad to work with the authors to help accomplish the following (which I would be glad for them to author, but I have a lot of interest in making this happen cleanly): a) set out a reasonable list of reqiurements b) help determine the best way to merge the best parts of the existing work to make this happen c) help determine how to factor the documents out usefully (rather than issuing a single, monolithic doc) I would prefer this course to having either (or, gasp, both) of these proposals moving forward independently. I will be glad to meet with the authors and/or WG chairs interested to help this happen, anytime EXCEPT during TCPM/INT/BTNS ;-( and TRILL. Joe - --------------------------------------- My specific concerns are as follows: - - weis-tcp-mac 'direct input' issue I'm not a cryptographer, but if there's a difference between direct input and using the key as part of the data to be digested I'd highly suspect the MAC; this is a subtle issue that is only recently published and I'd like to understand if there's consensus in the security community. It seems like this is more like defining a new HMAC (KMAC?), at which point it should be defined in a separate document. - - both docs use both key IDs and alg IDs in the option header It seems a bad idea to expose the algorithm in the clear, and it seems unnecessary since a sufficiently large key ID space could be used instead, where the key ID indicates both the key value and the key algorithm (i.e., like an SPI does). - - time-based keying is not a good idea, because TCP has no notion of absolute time shared between the endpoints, so this needs to rely on NTP or somesuch as well as TCP, which presents a separate vulnerability, as well as substantially complicating the TCP implementation. - - neither document discusses initial keying - - neither document discusses agreement on algorithm Perhaps this is because the alg is indicated in the option; it would be preferable to negotiate this during the connection establishment - preferably securely (i.e., not in the clear). I see no reason to change the algorithm during a connection; that could be included in the rekey exchange without too much extra effort if desired. - - neither document discusses the initial key exchange In particular neither document addresses the use of DH for the initial exchange. There may be concerns about the overhead of DH and the resulting opportunity for SYN attack, but this should be overcome by allowing DH to be optional, rather than by ignoring it. I would also suggest that the initial key exchange allow BTNS-style unauthenticated DH, i.e.: - master-keyed (2385-mode) - DH based on master key (authenticated DH) - DH without authentication (BTNS mode) - - both documents discuss 'unused' fields in the proposed option, but need to be more specific about how that field is handled - under the proposed specs, senders MUST set them to zero - under the proposed specs, receivers MUST ignore them - - I would prefer/hope that some of the signalling information between the endpoints was ALWAYS encrypted, e.g., indicating whether a new key is enclosed. I don't like the fact that this info is passed in the clear. - ----------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEGzaVE5f5cImnZrsRAudhAJ41nIIZNphLH8owPevoU8WkHQOq9gCguzAr LJTjNc3lNuSrk2sN49p6tzc= =Ow64 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Mar 19 22:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAe7-0001Im-QP; Sun, 19 Mar 2006 22:01:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLAe6-0001Ih-NU for tcpm@ietf.org; Sun, 19 Mar 2006 22:01:26 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLAe5-0005xo-9B for tcpm@ietf.org; Sun, 19 Mar 2006 22:01:26 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2K31N2Q008571 for ; Sun, 19 Mar 2006 19:01:24 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 8C07677B1E1 for ; Sun, 19 Mar 2006 22:01:20 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id F3B093E3283 for ; Sun, 19 Mar 2006 17:16:55 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hammer to Fall MIME-Version: 1.0 Date: Sun, 19 Mar 2006 17:16:55 -0500 Message-Id: <20060319221655.F3B093E3283@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [tcpm] IETF Secretariat: Text Conferencing at IETF 65 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2047726534==" Errors-To: tcpm-bounces@ietf.org --===============2047726534== Content-Type: multipart/signed; boundary="==_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --==_bOundary Content-Type: multipart/mixed; boundary="=_bOundary" --=_bOundary Content-Type: text/plain Content-Disposition: inline In case there are folk on here that intend to participate remotely and are not on the announce list, see the attached. Also, everything in these rooms is logged and subject to the standard IETF IPR rules (the "Note Well"). Speakers- If you haven't already, remember to send me your slides. The slides will be posted at the standard meeting materials place before the meeting tomorrow. I'll send another note with the URL (am currently disconnected and so can't go off and find it). allman --=_bOundary Content-Type: message/rfc822 Content-Disposition: attachment; filename=2860 Content-Description: forwarded message Return-Path: ietf-secretariat@ietf.org Delivery-Date: Sat Mar 18 19:00:13 2006 Return-Path: X-Original-To: mallman@localhost Delivered-To: mallman@localhost.icir.org Received: from localhost (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 655DF77AA40 for ; Sat, 18 Mar 2006 19:00:13 -0500 (EST) Received: from mailhost.icsi.berkeley.edu [192.150.186.11] by localhost with IMAP (fetchmail-6.2.4) for mallman@localhost (single-drop); Sat, 18 Mar 2006 19:00:13 -0500 (EST) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by fruitcake.ICSI.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id k2J0002d000151 for ; Sat, 18 Mar 2006 16:00:00 -0800 (PST) Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2INxxkw087514 for ; Sat, 18 Mar 2006 15:59:59 -0800 (PST) (envelope-from ietf-announce-bounces@ietf.org) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKlFw-0001Se-9f; Sat, 18 Mar 2006 18:54:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKlFu-0001SY-AX; Sat, 18 Mar 2006 18:54:46 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKlFt-0004If-3J; Sat, 18 Mar 2006 18:54:46 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2INsivP017389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Mar 2006 23:54:44 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FKlFs-0006GZ-Ns; Sat, 18 Mar 2006 18:54:44 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list Cc: From: IETF Secretariat Message-Id: Date: Sat, 18 Mar 2006 18:54:44 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: Text Conferencing at IETF 65 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: ietf-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org X-ClamAV: OK X-SpamProbe: GOOD 0.0000360 20dc777d719d260339d9d2939abe5baa X-mallman-sequence: ietf The Secretariat is pleased to announce a new Instant Messaging service. This service will provide jabber chat rooms to all IETF working groups for their text conferencing at IETF 65 and future meetings. The new jabber server is located at rooms.jabber.ietf.org and is currently accessible. For those who are interested, please visit the above location to join any of the available chat rooms. Please note: All traffic within the defined rooms (except "noc") is being logged and updated every 5 minutes to the ietf.org website. To view the log directories, point your browser to http://www3.ietf.org/meetings/ietf-logs/. If you click on a room directory, you will see one or more files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you click on one of those files, you will see all logged traffic for that day. Please visit the IETF Text Conferencing Web page (http://www.ietf.org/meetings/text_conf.html) for more information. The IETF Secretariat. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce --=_bOundary-- --==_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEHdhXWyrrWs4yIs4RAldiAJ9vS+o1aRx2x3cR8DFeRN7TR8OiDACeObgx x/9ZgaVJatveGDbeTWd3aYw= =WM9u -----END PGP SIGNATURE----- --==_bOundary-- --===============2047726534== 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://www1.ietf.org/mailman/listinfo/tcpm --===============2047726534==-- From tcpm-bounces@ietf.org Mon Mar 20 12:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLO3y-0000P6-FZ; Mon, 20 Mar 2006 12:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLO3x-0000P1-HD for tcpm@ietf.org; Mon, 20 Mar 2006 12:21:01 -0500 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLO3w-0002YD-6h for tcpm@ietf.org; Mon, 20 Mar 2006 12:21:01 -0500 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.11/8.12.11) with ESMTP id k2KHKt43014362; Mon, 20 Mar 2006 09:20:55 -0800 (PST) (envelope-from floyd@cougar.icir.org) Message-Id: <200603201720.k2KHKt43014362@cougar.icir.org> To: weddy@grc.nasa.gov From: Sally Floyd Subject: Re: [tcpm] small bit on ecnsyn-00 and syn cookies Date: Mon, 20 Mar 2006 09:20:55 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org >Just a slight bit more discussion of syn cookies is required in the >ecnsyn draft as it stands. Many thanks for the email. Clearly the draft needs to be clarified. I don't think it is necessary to incorporate the ECN-capable bit into the cookie, at least for using ECN for the SYN/ACK packet. * When host B sees an incoming SYN trying to negotiate ECN, it can send the syn-ack as ECN-capable. * If host B gets back an ACK for the SYN/ACK reporting ECN-Echo, then it has to respond appropriately (i.e., set cwnd to one packet, maybe wait for a timer, and set CWR on the first outgoing data packet.) Neither of these require much by way of maintaining state. I will add a discussion of this to the syn-ack draft. If you wanted to add something to the draft-eddy-syn-flood-01.txt, that would be good also. In general, here are the places where state is required for using ECN: * How long to send ECN-Echo: If host B receives packets marked as CE (Congestion Experienced), then it has to respond with ECN-Echo, and continuing sending ECN-Echo until it receives CWR (Congestion Window Reduced). * Whether to send data packets as ECN-Capable? Host B also has to know that it is ok to send data packets as ECN-Capable, if it is going to do so. So it has to remember that the other side has agreed to do ECN. - Sally _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Mar 20 15:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQlm-0007Up-QY; Mon, 20 Mar 2006 15:14:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLQll-0007PF-20 for tcpm@ietf.org; Mon, 20 Mar 2006 15:14:25 -0500 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLQlj-00018u-Ml for tcpm@ietf.org; Mon, 20 Mar 2006 15:14:25 -0500 Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2KKEMmK023773 for ; Mon, 20 Mar 2006 12:14:22 -0800 (PST) (envelope-from mallman@icir.org) Received: from lawyers.icir.org (guns.icir.org [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id B238F77ACCB for ; Mon, 20 Mar 2006 15:14:20 -0500 (EST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 18F733E41B2 for ; Mon, 20 Mar 2006 15:13:33 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Hammer to Fall MIME-Version: 1.0 Date: Mon, 20 Mar 2006 15:13:32 -0500 Message-Id: <20060320201333.18F733E41B2@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [tcpm] remote participation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0712387580==" Errors-To: tcpm-bounces@ietf.org --===============0712387580== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Folks- I think this is a summary of the key information that remote folks will need to participate in today's meeting. Audio feed: http://videolab.uoregon.edu/events/ietf/ Jabber: HOST: rooms.jabber.ietf.org ROOM: tcpm Slides: http://www.icir.org/mallman/share/tcpm65/ (I tried to get this all on the IETF's meeting materials web page, but it was not cooperating with me.) Enjoy! allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEHwzsWyrrWs4yIs4RApDmAJ0Yxg6eO/NEVjX1Az9gfLrdGlJpdwCggiVb ZzeznCe1MeE7zsaLh4geTNs= =QbvA -----END PGP SIGNATURE----- --=_bOundary-- --===============0712387580== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0712387580==-- From tcpm-bounces@ietf.org Thu Mar 23 14:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVA0-00034R-5J; Thu, 23 Mar 2006 14:07:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMV9y-000334-UW for tcpm@ietf.org; Thu, 23 Mar 2006 14:07:50 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMV9x-0000RL-HD for tcpm@ietf.org; Thu, 23 Mar 2006 14:07:50 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 23 Mar 2006 11:07:39 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 930AC2B0; Thu, 23 Mar 2006 11:07:39 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 6B9EF2AE for ; Thu, 23 Mar 2006 11:07:39 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDQ17315; Thu, 23 Mar 2006 11:07:38 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C40C220501 for ; Thu, 23 Mar 2006 11:07:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Mar 2006 11:07:38 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1364B4D@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: draft-bonica and TCP segmentation Thread-Index: AcZOrQ0IPpPIxTbZTLGfkleZnwutLg== From: "Caitlin Bestler" To: tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032306; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343232463136332E303034382D412D; ENG=IBF; TS=20060323190742; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006032306_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683C2E713NG2631415-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [tcpm] draft-bonica and TCP segmentation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > Whenever TCP generates a segment, it searches the key-chain for an > active key. Section 6 of this document describes TCPs active key > selection criteria. Doesn't this imply that *only* the original sender can do TCP segmentation? I believe the precedent recently reaffirmed for MPA (RDDP WG) was that a protocl MUST NOT assume that the sender's segmetnation would be preserved by the network. If message boundaries are lost, a valid network occurrence, how could you interpret the content? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 14:32:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVXo-0005wi-PS; Thu, 23 Mar 2006 14:32:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVXb-0005py-0C for tcpm@ietf.org; Thu, 23 Mar 2006 14:32:15 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVJ0-0000jt-VM for tcpm@ietf.org; Thu, 23 Mar 2006 14:17:12 -0500 Received: from [130.129.132.63] (DHCP-Wireless-132-63.ietf65.org [130.129.132.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NJG4w08077; Thu, 23 Mar 2006 11:16:05 -0800 (PST) Message-ID: <4422F3ED.6000204@isi.edu> Date: Thu, 23 Mar 2006 11:15:57 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364B4D@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1364B4D@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: >> Whenever TCP generates a segment, it searches the key-chain for an >> active key. Section 6 of this document describes TCPs active key >> selection criteria. > > Doesn't this imply that *only* the original sender can do TCP > segmentation? That's already part of the TCP spec - TCP is defined only between the TCP endpoints; there are no provisions for in-network resegmentation, which would affect ACK clocking, Nagle, etc. > I believe the precedent recently reaffirmed for > MPA (RDDP WG) was that a protocl MUST NOT assume that the > sender's segmetnation would be preserved by the network. Segmentation at the TCP layer must be preserved, or it's not TCP. Network layer re-'segmentation' is a network protocol issue, e.g., it is supported in IPv4 but not in IPv6. Other transport protocols can make other decisions. TCP could be proxied - i.e., terminated by an intermediate node and resegmented there - but a 'transparent' proxy that does so violates TCP. Further, we're talking about authenticated segments; resegmentation without resigning the message with the appropriate key is basically just an attack - one that fails. > If message boundaries are lost, a valid network occurrence, > how could you interpret the content? Can you clarify what you mean by 'message'? If you're talking about a message boundary within TCP, the application must place it there. TCP does not preserve application data units. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 14:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVdJ-0000Jm-Um; Thu, 23 Mar 2006 14:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVdI-0000Jg-J4 for tcpm@ietf.org; Thu, 23 Mar 2006 14:38:08 -0500 Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVdH-0001c2-BF for tcpm@ietf.org; Thu, 23 Mar 2006 14:38:08 -0500 Received: from dexter.psc.edu (dexter.psc.edu [128.182.58.232]) by mailer1.psc.edu (8.13.4/8.13.3) with ESMTP id k2NJc4DA020798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Mar 2006 14:38:04 -0500 (EST) Received: from localhost (dexter.psc.edu [128.182.58.232]) by dexter.psc.edu (8.13.1/8.12.10) with ESMTP id k2NJc4Op004396; Thu, 23 Mar 2006 14:38:04 -0500 From: John Heffner Organization: PSC To: tcpm@ietf.org Subject: Re: [tcpm] draft-bonica and TCP segmentation Date: Thu, 23 Mar 2006 14:37:50 -0500 User-Agent: KMail/1.9.1 References: <54AD0F12E08D1541B826BE97C98F99F1364B4D@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1364B4D@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603231437.50883.jheffner@psc.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Thursday 23 March 2006 14:07, Caitlin Bestler wrote: > > Whenever TCP generates a segment, it searches the key-chain for an > > active key. Section 6 of this document describes TCPs active key > > selection criteria. > > Doesn't this imply that *only* the original sender can do TCP > segmentation? I believe the precedent recently reaffirmed for > MPA (RDDP WG) was that a protocl MUST NOT assume that the > sender's segmetnation would be preserved by the network. That's contrary to my understanding. I just scanned over draft-ietf-rddp-mpa-02, and didn't see anything relating to this. Can you provide some more detail? -John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 14:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVjd-0000H6-Q3; Thu, 23 Mar 2006 14:44:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVjc-0000Ea-Q2 for tcpm@ietf.org; Thu, 23 Mar 2006 14:44:40 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVjb-0001w5-9n for tcpm@ietf.org; Thu, 23 Mar 2006 14:44:40 -0500 Received: from dhcp-wireless-132-237.ietf65.org (DHCP-Wireless-132-237.ietf65.org [130.129.132.237]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6CE9D1BAC4D; Thu, 23 Mar 2006 20:43:20 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by dhcp-wireless-132-237.ietf65.org (Postfix) with ESMTP id DD76A7A1FE2; Thu, 23 Mar 2006 13:44:36 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v746.3) To: tcpm@ietf.org Message-Id: <8A929969-329B-4346-94A6-232CB447DC36@netlab.nec.de> From: Lars Eggert Date: Thu, 23 Mar 2006 13:44:35 -0600 X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Dan Wing Subject: [tcpm] draft-ietf-behave-tcp-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0761119711==" Errors-To: tcpm-bounces@ietf.org --===============0761119711== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-41--520365306; protocol="application/pkcs7-signature" --Apple-Mail-41--520365306 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, the BEHAVE folks have a WG document (target: BCP) that talks about how well-behaved NATs should treat TCP. They'd like to get feedback from the TCPM folks on this, to check that they haven't overlooked something. The document is short and very readable! Are there one or two TCPM people that would volunteer send a review to ietf- behave@list.sipfoundry.org? http://tools.ietf.org/html?draft=draft-ietf-behave-tcp-00 Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-41--520365306 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2 usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDYwMzIzMTk0NDM1WjAjBgkqhkiG9w0BCQQxFgQUIpZeY2Uwaw9QlKrNwG9/ gof4tY0wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAIjQKQ2ZeZHtKA/wp43fkLYbW08NdzREhjrLxkq/k2klZq9A8z+HeJw+qwtgy9bHRhW6eud/ P8CQNXNZL0zyCGli4/h48ZLESCuizw6jgusJRT8HlKxvM29Q+hgWvz9ZxZgH2TH3/cHrOM4Or8VK TEPsHEmH9rqhbpk3lxplfxfreDNKVM5ZiD3biY1eODrQ7ARyxH3A/OFgM7cg17KCyVthRsHAebTH lDzb32Tr91IJQQkKRwZRPvxovn565DIQ8iA1GYh6WAfwC2I4e2LQv+eDpnSW345y5fh89ov3pwKi mPSSBEzC4NSJI7TtXSSh1lB8TObWSfSEhOlJnF0MlNoAAAAAAAA= --Apple-Mail-41--520365306-- --===============0761119711== 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://www1.ietf.org/mailman/listinfo/tcpm --===============0761119711==-- From tcpm-bounces@ietf.org Thu Mar 23 15:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWZ8-0000D0-HR; Thu, 23 Mar 2006 15:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMWZ8-0000Cv-0T for tcpm@ietf.org; Thu, 23 Mar 2006 15:37:54 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMWZ7-0004fI-Io for tcpm@ietf.org; Thu, 23 Mar 2006 15:37:53 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 23 Mar 2006 12:37:45 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 1AA612AF; Thu, 23 Mar 2006 12:37:45 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id E75C72AE; Thu, 23 Mar 2006 12:37:44 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDQ52806; Thu, 23 Mar 2006 12:37:41 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id D182E20502; Thu, 23 Mar 2006 12:37:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Thu, 23 Mar 2006 12:37:41 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZOrmlm890mQjTLSreTeyzEeM2xFgACrlIA From: "Caitlin Bestler" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032307; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230372E34343233303637462E303036382D412D; ENG=IBF; TS=20060323203747; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006032307_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683DD8930HW1302358-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Caitlin Bestler wrote: >>> Whenever TCP generates a segment, it searches the key-chain for an >>> active key. Section 6 of this document describes TCPs active key >>> selection criteria. >>=20 >> Doesn't this imply that *only* the original sender can do TCP >> segmentation? >=20 > That's already part of the TCP spec - TCP is defined only > between the TCP endpoints; there are no provisions for > in-network resegmentation, which would affect ACK clocking, Nagle, > etc.=20 >=20 >> I believe the precedent recently reaffirmed for MPA (RDDP WG) was >> that a protocl MUST NOT assume that the sender's segmetnation would >> be preserved by the network. >=20 > Segmentation at the TCP layer must be preserved, or it's not TCP. > Network layer re-'segmentation' is a network protocol issue, > e.g., it is supported in IPv4 but not in IPv6. >=20 > Other transport protocols can make other decisions. TCP could > be proxied > - i.e., terminated by an intermediate node and resegmented > there - but a 'transparent' proxy that does so violates TCP. >=20 > Further, we're talking about authenticated segments; > resegmentation without resigning the message with the > appropriate key is basically just an attack - one that fails. >=20 Meaning that a intermediate node that termianted and re-originated the TCP connections for purely network reasons would be interpreted as an "attacker". >> If message boundaries are lost, a valid network occurrence, how could >> you interpret the content? >=20 > Can you clarify what you mean by 'message'? If you're talking > about a message boundary within TCP, the application must > place it there. TCP does not preserve application data units. >=20 > Joe Doesn't the authentication option effectively makes a "message" out of each tcp segment, thereby requiring the 'message' boundaries to be preserved? MPA was specifically designed to avoid that assumption, despite the fact that assuming preservation of TCP segments on an end to end basis would have allowed signifigant design simplifications. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 16:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXcJ-0001Tt-Bz; Thu, 23 Mar 2006 16:45:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMXcH-0001To-He for tcpm@ietf.org; Thu, 23 Mar 2006 16:45:13 -0500 Received: from [207.14.217.166] (helo=server) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMXcG-0008IV-84 for tcpm@ietf.org; Thu, 23 Mar 2006 16:45:13 -0500 Received: from [204.96.114.143] ([204.96.114.143]) by server (8.12.8/8.12.8) with SMTP id k2NKI02w011624; Thu, 23 Mar 2006 15:18:01 -0500 Message-ID: <442316DD.4080500@isi.edu> Date: Thu, 23 Mar 2006 13:45:01 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Joe Touch wrote: ... >> Further, we're talking about authenticated segments; >> resegmentation without resigning the message with the >> appropriate key is basically just an attack - one that fails. > > Meaning that a intermediate node that termianted and > re-originated the TCP connections for purely network > reasons would be interpreted as an "attacker". That's what it _is_. Esp. if signed, there's no other possibility. > Doesn't the authentication option effectively makes a "message" out > of each tcp segment, thereby requiring the 'message' boundaries > to be preserved? TCP considers each segment to be a message between its endpoints; resegmenting those messages is a violation of the protocol. Unfortunately, that's detectable only if they're protected (TCP/MD5, IPsec). > MPA was specifically designed to avoid that assumption, despite > the fact that assuming preservation of TCP segments on an end > to end basis would have allowed signifigant design simplifications. If MPA is used with a different transport protocol, that's fine. If MPA is used with TCP and it allows resegmentation, all you have is a protocol that protects the _data_ of TCP without protecting the segments. Which won't protect TCP segments from attack (RST, SYN, FIN). It would provide similar protection that SSL provides - perhaps allowing / encouraging so-called 'transparent proxies'. So MPA then protects the data in a way that is "TCP-attacker friendly". That's a silly optimization IMO. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 17:25:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYEt-0000gq-8K; Thu, 23 Mar 2006 17:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYEr-0000gl-Q9 for tcpm@ietf.org; Thu, 23 Mar 2006 17:25:05 -0500 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYEq-0001uS-8R for tcpm@ietf.org; Thu, 23 Mar 2006 17:25:05 -0500 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.3/8.13.3) with ESMTP id k2NMOwnr026749; Thu, 23 Mar 2006 14:24:58 -0800 (PST) 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, 23 Mar 2006 14:24:58 -0800 Received: from [204.96.115.111] ([147.11.233.107]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 14:24:57 -0800 In-Reply-To: <442316DD.4080500@isi.edu> References: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> <442316DD.4080500@isi.edu> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <757481C7-89CC-44C5-A686-8287862C9E03@windriver.com> Content-Transfer-Encoding: 7bit From: David Borman Subject: Re: [tcpm] draft-bonica and TCP segmentation Date: Thu, 23 Mar 2006 16:24:54 -0600 To: Joe Touch X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 23 Mar 2006 22:24:57.0854 (UTC) FILETIME=[9E0A51E0:01C64EC8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On Mar 23, 2006, at 3:45 PM, Joe Touch wrote: > >> Doesn't the authentication option effectively makes a "message" out >> of each tcp segment, thereby requiring the 'message' boundaries >> to be preserved? > > TCP considers each segment to be a message between its endpoints; > resegmenting those messages is a violation of the protocol. > Unfortunately, that's detectable only if they're protected (TCP/ > MD5, IPsec). > >> MPA was specifically designed to avoid that assumption, despite >> the fact that assuming preservation of TCP segments on an end >> to end basis would have allowed signifigant design simplifications. > > If MPA is used with a different transport protocol, that's fine. > > If MPA is used with TCP and it allows resegmentation, all you have > is a > protocol that protects the _data_ of TCP without protecting the > segments. MPA doesn't protect anything. It identifies record boundaries. > > Which won't protect TCP segments from attack (RST, SYN, FIN). It would > provide similar protection that SSL provides - perhaps allowing / > encouraging so-called 'transparent proxies'. > > So MPA then protects the data in a way that is "TCP-attacker > friendly". > That's a silly optimization IMO. I believe the RDDP working group was explicitly told that they couldn't change TCP, specifically with regards to segmentation. MPA sits between DDP and TCP, and no assumptions could be made about how TCP would segment the data. MPA does not protect the data, it provides a framing mechanism to detect record boundaries, even when packets arrive out of order and the records begin in the middle of a TCP packet. It was not a "silly optimization". The TCP Enhanced Authentication Option would be part of TCP, and so the rules are different. You can't compare MPA and the TCP Enhanced Authentication Option. -David Borman _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 17:29:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYIo-0004ps-Ek; Thu, 23 Mar 2006 17:29:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYIn-0004pn-Hw for tcpm@ietf.org; Thu, 23 Mar 2006 17:29:09 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYIm-00022o-6u for tcpm@ietf.org; Thu, 23 Mar 2006 17:29:09 -0500 Received: from [130.129.132.63] (DHCP-Wireless-132-63.ietf65.org [130.129.132.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NMR1w26912; Thu, 23 Mar 2006 14:27:01 -0800 (PST) Message-ID: <442320AE.9010000@isi.edu> Date: Thu, 23 Mar 2006 14:26:54 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Joe Touch Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> <442316DD.4080500@isi.edu> In-Reply-To: <442316DD.4080500@isi.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org To be a little more clear: if you're using MPA from 'end-to-end' and TCP hop by hop, such as would be the case with a explicit proxy, then: - you're protecting data, not TCP segments - there's no guarantee that a single MPA message goes in a single TCP segment if it's not a TCP option, then it's considered the 'user' layer to TCP, and there's no assurance of boundary preservation of user messages at the TCP layer - there's no E2E reliability or in-order delivery guaranteed i.e., you can't know that the proxy in the middle didn't drop or reorder If that's what you _really_ want, why not just use TCP over TCP? I.e., TCP-Auth end-to-end and TCP(with or without auth) hop by hop? Joe Joe Touch wrote: > > Caitlin Bestler wrote: >> Joe Touch wrote: > ... >>> Further, we're talking about authenticated segments; >>> resegmentation without resigning the message with the >>> appropriate key is basically just an attack - one that fails. >> Meaning that a intermediate node that termianted and >> re-originated the TCP connections for purely network >> reasons would be interpreted as an "attacker". > > That's what it _is_. Esp. if signed, there's no other possibility. > >> Doesn't the authentication option effectively makes a "message" out >> of each tcp segment, thereby requiring the 'message' boundaries >> to be preserved? > > TCP considers each segment to be a message between its endpoints; > resegmenting those messages is a violation of the protocol. > Unfortunately, that's detectable only if they're protected (TCP/MD5, IPsec). > >> MPA was specifically designed to avoid that assumption, despite >> the fact that assuming preservation of TCP segments on an end >> to end basis would have allowed signifigant design simplifications. > > If MPA is used with a different transport protocol, that's fine. > > If MPA is used with TCP and it allows resegmentation, all you have is a > protocol that protects the _data_ of TCP without protecting the segments. > > Which won't protect TCP segments from attack (RST, SYN, FIN). It would > provide similar protection that SSL provides - perhaps allowing / > encouraging so-called 'transparent proxies'. > > So MPA then protects the data in a way that is "TCP-attacker friendly". > That's a silly optimization IMO. > > Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 17:29:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYJW-0005rN-8k; Thu, 23 Mar 2006 17:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYJU-0005nd-OS for tcpm@ietf.org; Thu, 23 Mar 2006 17:29:52 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYJT-00024u-DG for tcpm@ietf.org; Thu, 23 Mar 2006 17:29:52 -0500 Received: from [130.129.132.63] (DHCP-Wireless-132-63.ietf65.org [130.129.132.63]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2NMTDw27737; Thu, 23 Mar 2006 14:29:13 -0800 (PST) Message-ID: <44232132.9000900@isi.edu> Date: Thu, 23 Mar 2006 14:29:06 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Borman Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364B7E@NT-SJCA-0751.brcm.ad.broadcom.com> <442316DD.4080500@isi.edu> <757481C7-89CC-44C5-A686-8287862C9E03@windriver.com> In-Reply-To: <757481C7-89CC-44C5-A686-8287862C9E03@windriver.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org David Borman wrote: > > On Mar 23, 2006, at 3:45 PM, Joe Touch wrote: > >> >>> Doesn't the authentication option effectively makes a "message" out >>> of each tcp segment, thereby requiring the 'message' boundaries >>> to be preserved? >> >> TCP considers each segment to be a message between its endpoints; >> resegmenting those messages is a violation of the protocol. >> Unfortunately, that's detectable only if they're protected (TCP/MD5, >> IPsec). >> >>> MPA was specifically designed to avoid that assumption, despite >>> the fact that assuming preservation of TCP segments on an end >>> to end basis would have allowed signifigant design simplifications. >> >> If MPA is used with a different transport protocol, that's fine. >> >> If MPA is used with TCP and it allows resegmentation, all you have is a >> protocol that protects the _data_ of TCP without protecting the segments. > > MPA doesn't protect anything. It identifies record boundaries. Thanks. Others had discussed this as if it did. >> Which won't protect TCP segments from attack (RST, SYN, FIN). It would >> provide similar protection that SSL provides - perhaps allowing / >> encouraging so-called 'transparent proxies'. >> >> So MPA then protects the data in a way that is "TCP-attacker friendly". >> That's a silly optimization IMO. > > I believe the RDDP working group was explicitly told that they couldn't > change TCP, specifically with regards to segmentation. MPA sits between > DDP and TCP, and no assumptions could be made about how TCP would > segment the data. MPA does not protect the data, it provides a framing > mechanism to detect record boundaries, even when packets arrive out of > order and the records begin in the middle of a TCP packet. It was not a > "silly optimization". I was referring to 'protecting the data in a way that's TCP-attacker friendly' being silly. Record boundaries are very useful. > The TCP Enhanced Authentication Option would be part of TCP, and so the > rules are different. You can't compare MPA and the TCP Enhanced > Authentication Option. Agreed. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Mar 23 17:33:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYN3-0008LE-QY; Thu, 23 Mar 2006 17:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMYN2-0008KO-Oa for tcpm@ietf.org; Thu, 23 Mar 2006 17:33:32 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMYN1-0002Aq-Cg for tcpm@ietf.org; Thu, 23 Mar 2006 17:33:32 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 23 Mar 2006 14:33:23 -0800 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id CE9312AF; Thu, 23 Mar 2006 14:33:22 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id A89A02AE; Thu, 23 Mar 2006 14:33:22 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDR07645; Thu, 23 Mar 2006 14:32:23 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 951D220502; Thu, 23 Mar 2006 14:32:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Thu, 23 Mar 2006 14:32:22 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1364BAC@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZOyMmFR9GujDKyRYSZNZhLzxsS2wAAE3tw From: "Caitlin Bestler" To: "David Borman" , "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032308; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230332E34343233323139382E303037452D412D; ENG=IBF; TS=20060323223323; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006032308_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683DFDB917452007-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org David Borman wrote: > On Mar 23, 2006, at 3:45 PM, Joe Touch wrote: >=20 >>=20 >>> Doesn't the authentication option effectively makes a "message" out >>> of each tcp segment, thereby requiring the 'message' boundaries to >>> be preserved? >>=20 >> TCP considers each segment to be a message between its endpoints; >> resegmenting those messages is a violation of the protocol. >> Unfortunately, that's detectable only if they're protected (TCP/ >> MD5, IPsec).=20 >>=20 >>> MPA was specifically designed to avoid that assumption, despite the >>> fact that assuming preservation of TCP segments on an end to end >>> basis would have allowed signifigant design simplifications. >>=20 >> If MPA is used with a different transport protocol, that's fine. >>=20 >> If MPA is used with TCP and it allows resegmentation, all you have is >> a protocol that protects the _data_ of TCP without protecting the >> segments. >=20 > MPA doesn't protect anything. It identifies record boundaries. >=20 >>=20 >> Which won't protect TCP segments from attack (RST, SYN, FIN). It >> would provide similar protection that SSL provides - perhaps >> allowing / encouraging so-called 'transparent proxies'. >>=20 >> So MPA then protects the data in a way that is "TCP-attacker >> friendly". That's a silly optimization IMO. >=20 > I believe the RDDP working group was explicitly told that > they couldn't change TCP, specifically with regards to > segmentation. MPA sits between DDP and TCP, and no > assumptions could be made about how TCP would segment the > data. MPA does not protect the data, it provides a framing > mechanism to detect record boundaries, even when packets > arrive out of order and the records begin in the middle of a > TCP packet. It was not a "silly optimization". >=20 > The TCP Enhanced Authentication Option would be part of TCP, > and so the rules are different. You can't compare MPA and > the TCP Enhanced Authentication Option. >=20 > -David Borman In theory that is correct. In practice, TCP Enhanced Authentication is likely to be implemented above the layer where MPA is implemented. As annoying as it was to define MPA *over* TCP, the reason for the restriction was a valid desire to keep TCP simple and not cram new bells and whistles in for upper layers. TCP Auth is exactly that. It is a solution that meets only one need and will not be supported in general purpose stacks because general purpose stacks will be focusing on optimizing IPSEC and/or TLS. Having "encryption/authentication solution du jour" is not the way to encourage development of efficient cost-effective solutions. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 00:31:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMetM-0008RW-0L; Fri, 24 Mar 2006 00:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMetK-0008Mg-CK for tcpm@ietf.org; Fri, 24 Mar 2006 00:31:18 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMetJ-0005eZ-0O for tcpm@ietf.org; Fri, 24 Mar 2006 00:31:18 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 23 Mar 2006 21:31:16 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2O5VGw1022286; Thu, 23 Mar 2006 21:31:16 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Mar 2006 21:31:16 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Thu, 23 Mar 2006 21:31:14 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC58015995DC@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZOrQ0IPpPIxTbZTLGfkleZnwutLgAFFiHg From: "Anantha Ramaiah \(ananth\)" To: "Caitlin Bestler" , X-OriginalArrivalTime: 24 Mar 2006 05:31:16.0355 (UTC) FILETIME=[2C03D530:01C64F04] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org It is well known that TCP segments containing the TCP MD5 option (as it is today) will work on a purely end-to-end principle and cannot be subject to any further segmentation/proxying at the transport layer by in-between proxies. Simply because the proxies don't have the keys to regenerate the TCP segments. By proxies what I mean here is the "trusted middleboxes" OR NAT's which can rewrite the IP headers and not the "attacker". But the TCP MD5 option (and the further revisions that are proposed in draft-bonica and draft-weis) are mainly for the routing applications and these connections never find themselves behind a NAT/firewall or a proxy device which modifies the TCP segment or the psuedo-header used for the MD5/new auth option in any manner whatsoever. This is one of the reasons why there is a 'T' bit present in the TCP header which tells that whether the TCP options have been omitted while forming the authentication digest or not. Since we felt that there are some genuine cases wherein the TCP MSS option can be modified in-between. -Anantha > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com]=20 > Sent: Thursday, March 23, 2006 11:08 AM > To: tcpm@ietf.org > Subject: [tcpm] draft-bonica and TCP segmentation >=20 > > Whenever TCP generates a segment, it searches the key-chain for an > > active key. Section 6 of this document describes TCPs active key > > selection criteria. >=20 > Doesn't this imply that *only* the original sender can do TCP=20 > segmentation? I believe the precedent recently reaffirmed for=20 > MPA (RDDP WG) was that a protocl MUST NOT assume that the=20 > sender's segmetnation would be preserved by the network. >=20 > If message boundaries are lost, a valid network occurrence,=20 > how could you interpret the content? >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 16:59:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuJX-0003YT-9z; Fri, 24 Mar 2006 16:59:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuJW-0003Tg-7f for tcpm@ietf.org; Fri, 24 Mar 2006 16:59:22 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMuJV-0005Kf-RT for tcpm@ietf.org; Fri, 24 Mar 2006 16:59:22 -0500 Received: from [70.197.230.157] (157.sub-70-197-230.myvzw.com [70.197.230.157]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2OLvqw10143; Fri, 24 Mar 2006 13:57:52 -0800 (PST) Message-ID: <44246B5A.5000803@isi.edu> Date: Fri, 24 Mar 2006 13:57:46 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <0C53DCFB700D144284A584F54711EC58015995DC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC58015995DC@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > It is well known that TCP segments containing the TCP MD5 option (as it > is today) will work on a purely end-to-end principle and cannot be > subject to any further segmentation/proxying at the transport layer by > in-between proxies. Simply because the proxies don't have the keys to > regenerate the TCP segments. By proxies what I mean here is the "trusted > middleboxes" OR NAT's which can rewrite the IP headers and not the > "attacker". Any modification of an IP packet in flight - excepting fragmentation of IPv4, or IP forwarding processing - is equivalent to (and should be treated as) an attack. > But the TCP MD5 option (and the further revisions that are proposed in > draft-bonica and draft-weis) are mainly for the routing applications and > these connections never find themselves behind a NAT/firewall or a > proxy device which modifies the TCP segment or the psuedo-header used > for the MD5/new auth option in any manner whatsoever. If these 'trusted middleboxes' can be placed anywhere, and if they are intended to operate transparently to the ends of a connection, then this assumption is invalid. While it's reasonable to assume that NATs shouldn't be placed on a routing path, other "performance enhancing proxies" (PEPs) can be, and they are the worry. > This is one of the reasons why there is a 'T' bit present in the TCP > header which tells that whether the TCP options have been omitted while > forming the authentication digest or not. Since we felt that there are > some genuine cases wherein the TCP MSS option can be modified > in-between. TCP options are part of TCP, and protecting TCP means protecting its options. If you want that sort of data inspected and modified in the network, it belongs in the IP header, not TCP. Joe > -Anantha > >> -----Original Message----- >> From: Caitlin Bestler [mailto:caitlinb@broadcom.com] >> Sent: Thursday, March 23, 2006 11:08 AM >> To: tcpm@ietf.org >> Subject: [tcpm] draft-bonica and TCP segmentation >> >>> Whenever TCP generates a segment, it searches the key-chain for an >>> active key. Section 6 of this document describes TCPs active key >>> selection criteria. >> Doesn't this imply that *only* the original sender can do TCP >> segmentation? I believe the precedent recently reaffirmed for >> MPA (RDDP WG) was that a protocl MUST NOT assume that the >> sender's segmetnation would be preserved by the network. >> >> If message boundaries are lost, a valid network occurrence, >> how could you interpret the content? >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www1.ietf.org/mailman/listinfo/tcpm >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 17:02:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuMt-00074h-5e; Fri, 24 Mar 2006 17:02:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMuMr-000745-Oy for tcpm@ietf.org; Fri, 24 Mar 2006 17:02:49 -0500 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMuMq-0005ZD-DZ for tcpm@ietf.org; Fri, 24 Mar 2006 17:02:49 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 24 Mar 2006 14:02:38 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 14BCE2AE; Fri, 24 Mar 2006 14:02:38 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id D8B142AE; Fri, 24 Mar 2006 14:02:37 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDV83484; Fri, 24 Mar 2006 14:02:37 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 68B4E20501; Fri, 24 Mar 2006 14:02:37 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Fri, 24 Mar 2006 14:02:36 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1364CE4@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZPjjlc9HEDSsnLRhyELSI2lGAi9AAADWLg From: "Caitlin Bestler" To: "Joe Touch" , "Anantha Ramaiah (ananth)" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032407; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343234364244442E303032392D412D; ENG=IBF; TS=20060324220239; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006032407_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683AB3F40HW1595472-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Anantha Ramaiah (ananth) wrote: >> It is well known that TCP segments containing the TCP MD5 option (as >> it is today) will work on a purely end-to-end principle and cannot be >> subject to any further segmentation/proxying at the transport layer >> by in-between proxies. Simply because the proxies don't have the >> keys to regenerate the TCP segments. By proxies what I mean here is >> the "trusted middleboxes" OR NAT's which can rewrite the IP headers >> and not the "attacker". >=20 > Any modification of an IP packet in flight - excepting > fragmentation of IPv4, or IP forwarding processing - is > equivalent to (and should be treated as) an attack. >=20 >> But the TCP MD5 option (and the further revisions that are proposed >> in draft-bonica and draft-weis) are mainly for the routing >> applications and these connections never find themselves behind a >> NAT/firewall or a proxy device which modifies the TCP segment or the >> psuedo-header used for the MD5/new auth option in any manner >> whatsoever.=20 >=20 > If these 'trusted middleboxes' can be placed anywhere, and if > they are intended to operate transparently to the ends of a > connection, then this assumption is invalid. While it's > reasonable to assume that NATs shouldn't be placed on a > routing path, other "performance enhancing proxies" (PEPs) > can be, and they are the worry. >=20 That assumption should be documented in the draft, along with noting that this implies that TCP-AUTH is NOT applicable for applications other than router-to-router communication. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 17:30:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMun8-0004GN-BB; Fri, 24 Mar 2006 17:29:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMun6-0004EV-JJ for tcpm@ietf.org; Fri, 24 Mar 2006 17:29:56 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMun5-0006fH-8D for tcpm@ietf.org; Fri, 24 Mar 2006 17:29:56 -0500 Received: from [70.197.230.157] (157.sub-70-197-230.myvzw.com [70.197.230.157]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2OMSww16692; Fri, 24 Mar 2006 14:28:59 -0800 (PST) Message-ID: <442472A7.3040102@isi.edu> Date: Fri, 24 Mar 2006 14:28:55 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364CE4@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1364CE4@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Joe Touch wrote: ... >> If these 'trusted middleboxes' can be placed anywhere, and if >> they are intended to operate transparently to the ends of a >> connection, then this assumption is invalid. While it's >> reasonable to assume that NATs shouldn't be placed on a >> routing path, other "performance enhancing proxies" (PEPs) >> can be, and they are the worry. > > That assumption should be documented in the draft, along with > noting that this implies that TCP-AUTH is NOT applicable for > applications other than router-to-router communication. Actually, it applies more as a limitation of PEPs in general, that they do not work where they would alter protected contents, and so MUST NOT modify those sorts of packets. The issue is whether *they* are compliant, rather than TCP-AUTH (or TCP/MD5), because this limitation (of PEPs) applies to any transport or network layer protection mechanism. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 18:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvO4-0004a9-TJ; Fri, 24 Mar 2006 18:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvO3-0004ZX-T7 for tcpm@ietf.org; Fri, 24 Mar 2006 18:08:07 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMvO2-0007dR-C6 for tcpm@ietf.org; Fri, 24 Mar 2006 18:08:07 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 24 Mar 2006 15:07:52 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 76C252B0; Fri, 24 Mar 2006 15:07:52 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 497CE2AE; Fri, 24 Mar 2006 15:07:52 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DDW03123; Fri, 24 Mar 2006 15:07:51 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 7CD7A20501; Fri, 24 Mar 2006 15:07:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Fri, 24 Mar 2006 15:07:53 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F1364D04@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZPkn/0D5JgCPI+TBmzMy+eKCz0nQABTZ4w From: "Caitlin Bestler" To: "Joe Touch" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006032409; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343234374232412E303031442D412D; ENG=IBF; TS=20060324230756; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006032409_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683AA4423NG2920610-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: > Caitlin Bestler wrote: >> Joe Touch wrote: > ... >>> If these 'trusted middleboxes' can be placed anywhere, and if they >>> are intended to operate transparently to the ends of a connection, >>> then this assumption is invalid. While it's reasonable to assume >>> that NATs shouldn't be placed on a routing path, other "performance >>> enhancing proxies" (PEPs) can be, and they are the worry. >>=20 >> That assumption should be documented in the draft, along with noting >> that this implies that TCP-AUTH is NOT applicable for applications >> other than router-to-router communication. >=20 > Actually, it applies more as a limitation of PEPs in general, > that they do not work where they would alter protected > contents, and so MUST NOT modify those sorts of packets. >=20 > The issue is whether *they* are compliant, rather than > TCP-AUTH (or TCP/MD5), because this limitation (of PEPs) > applies to any transport or network layer protection mechanism. >=20 > Joe Of course that restriction is *far* more obvious if the=20 protection mechanism is IPSEC. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 19:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMws0-0000jB-IC; Fri, 24 Mar 2006 19:43:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwry-0000j6-OK for tcpm@ietf.org; Fri, 24 Mar 2006 19:43:06 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMwrx-0003B8-Bz for tcpm@ietf.org; Fri, 24 Mar 2006 19:43:06 -0500 Received: from [70.196.41.252] (252.sub-70-196-41.myvzw.com [70.196.41.252]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2P0gVw13879; Fri, 24 Mar 2006 16:42:32 -0800 (PST) Message-ID: <442491EE.4070006@isi.edu> Date: Fri, 24 Mar 2006 16:42:22 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <54AD0F12E08D1541B826BE97C98F99F1364D04@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1364D04@NT-SJCA-0751.brcm.ad.broadcom.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Caitlin Bestler wrote: > Joe Touch wrote: >> Caitlin Bestler wrote: >>> Joe Touch wrote: >> ... >>>> If these 'trusted middleboxes' can be placed anywhere, and if they >>>> are intended to operate transparently to the ends of a connection, >>>> then this assumption is invalid. While it's reasonable to assume >>>> that NATs shouldn't be placed on a routing path, other "performance >>>> enhancing proxies" (PEPs) can be, and they are the worry. >>> That assumption should be documented in the draft, along with noting >>> that this implies that TCP-AUTH is NOT applicable for applications >>> other than router-to-router communication. >> Actually, it applies more as a limitation of PEPs in general, >> that they do not work where they would alter protected >> contents, and so MUST NOT modify those sorts of packets. >> >> The issue is whether *they* are compliant, rather than >> TCP-AUTH (or TCP/MD5), because this limitation (of PEPs) >> applies to any transport or network layer protection mechanism. >> >> Joe > > Of course that restriction is *far* more obvious if the > protection mechanism is IPSEC. IP at least supports fragmentation and reassembly. TCP _does NOT_. Consider existing security protocols at IP and TCP: IP security protects the IP header AND the payload. TCP/MD5 security protects the TCP header (which includes, via pseudoheader, the IP header) AND the payload. Neither protocol protects fields _intended_ to be mutable en-route; both protocols protect ALL fields _intended_ to be immutable. It doesn't seem advisable to define a new security extension for a protocol that violates _that_ protocol's notion of what is mutable and what is not. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 24 21:17:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyLS-0000qb-9D; Fri, 24 Mar 2006 21:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyLR-0000qW-A5 for tcpm@ietf.org; Fri, 24 Mar 2006 21:17:37 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMyLQ-0006ZF-SP for tcpm@ietf.org; Fri, 24 Mar 2006 21:17:37 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 24 Mar 2006 18:17:36 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2P2HRH3015306; Fri, 24 Mar 2006 18:17:36 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Mar 2006 18:17:30 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Fri, 24 Mar 2006 18:17:29 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5801599909@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZPjjR/LAKt0pdgQHWunakzQga1jAAF2Qag From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 25 Mar 2006 02:17:30.0317 (UTC) FILETIME=[44C4F7D0:01C64FB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe,=20 > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Friday, March 24, 2006 1:58 PM > To: Anantha Ramaiah (ananth) > Cc: Caitlin Bestler; tcpm@ietf.org > Subject: Re: [tcpm] draft-bonica and TCP segmentation >=20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > > It is well known that TCP segments containing the TCP MD5=20 > option (as=20 > > it is today) will work on a purely end-to-end principle and=20 > cannot be=20 > > subject to any further segmentation/proxying at the=20 > transport layer by=20 > > in-between proxies. Simply because the proxies don't have=20 > the keys to=20 > > regenerate the TCP segments. By proxies what I mean here is the=20 > > "trusted middleboxes" OR NAT's which can rewrite the IP headers and=20 > > not the "attacker". >=20 > Any modification of an IP packet in flight - excepting=20 > fragmentation of IPv4, or IP forwarding processing - is=20 > equivalent to (and should be treated as) an attack. There are middleboxes out there today which intercepts and completes the 3 way HS with the client and then does the same with the server. After the connection goes to ESTAB state, the seq# and Ack# are adjusted with the approproiate "delta". I am not arguing whether this is the right thing to do or not but yes we have all these PEP's, TCP interceptors prevailing in today's internet. >=20 > > But the TCP MD5 option (and the further revisions that are=20 > proposed in=20 > > draft-bonica and draft-weis) are mainly for the routing=20 > applications=20 > > and these connections never find themselves behind a =20 > NAT/firewall or=20 > > a proxy device which modifies the TCP segment or the psuedo-header=20 > > used for the MD5/new auth option in any manner whatsoever. >=20 > If these 'trusted middleboxes' can be placed anywhere, and if=20 > they are intended to operate transparently to the ends of a=20 > connection, then this assumption is invalid. While it's=20 > reasonable to assume that NATs shouldn't be placed on a=20 > routing path, other "performance enhancing proxies" (PEPs)=20 > can be, and they are the worry. Point taken. >=20 > > This is one of the reasons why there is a 'T' bit present=20 > in the TCP=20 > > header which tells that whether the TCP options have been omitted=20 > > while forming the authentication digest or not. Since we felt that=20 > > there are some genuine cases wherein the TCP MSS option can be=20 > > modified in-between. >=20 > TCP options are part of TCP, and protecting TCP means=20 > protecting its options. If you want that sort of data=20 > inspected and modified in the network, it belongs in the IP=20 > header, not TCP. Strictly speaking, yes but again there are boxes out there today (very common) in some environments doing the adjustment of TCP MSS option in the middle. Theory and practice are 2 different things. -Anantha >=20 > Joe >=20 > > -Anantha > >=20 > >> -----Original Message----- > >> From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > >> Sent: Thursday, March 23, 2006 11:08 AM > >> To: tcpm@ietf.org > >> Subject: [tcpm] draft-bonica and TCP segmentation > >> > >>> Whenever TCP generates a segment, it searches the=20 > key-chain for an > >>> active key. Section 6 of this document describes TCPs=20 > active key > >>> selection criteria. > >> Doesn't this imply that *only* the original sender can do TCP=20 > >> segmentation? I believe the precedent recently reaffirmed for MPA=20 > >> (RDDP WG) was that a protocl MUST NOT assume that the sender's=20 > >> segmetnation would be preserved by the network. > >> > >> If message boundaries are lost, a valid network=20 > occurrence, how could=20 > >> you interpret the content? > >> > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www1.ietf.org/mailman/listinfo/tcpm > >> > >=20 > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www1.ietf.org/mailman/listinfo/tcpm >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 25 01:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN2La-0005ne-LJ; Sat, 25 Mar 2006 01:34:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FN2LZ-0005ja-CP for tcpm@ietf.org; Sat, 25 Mar 2006 01:34:01 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FN2Ji-000847-U7 for tcpm@ietf.org; Sat, 25 Mar 2006 01:32:08 -0500 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2P6VJw28631; Fri, 24 Mar 2006 22:31:19 -0800 (PST) Message-ID: <4424E3B0.3020002@isi.edu> Date: Fri, 24 Mar 2006 22:31:12 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <0C53DCFB700D144284A584F54711EC5801599909@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801599909@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha, Anantha Ramaiah (ananth) wrote: ... >> Any modification of an IP packet in flight - excepting >> fragmentation of IPv4, or IP forwarding processing - is >> equivalent to (and should be treated as) an attack. > > There are middleboxes out there today which intercepts and completes the > 3 way HS with the client and then does the same with the server. After > the connection goes to ESTAB state, the seq# and Ack# are adjusted with > the approproiate "delta". That's called a TCP endpoint. The rest is a matter of intent. TCP/MD5 and IPsec don't work beyond TCP endpoints or IP destinations, respectively - whether the endpoint that terminates either is 'authorized' to do so or not. ... >> TCP options are part of TCP, and protecting TCP means >> protecting its options. If you want that sort of data >> inspected and modified in the network, it belongs in the IP >> header, not TCP. > > Strictly speaking, yes but again there are boxes out there today (very > common) in some environments doing the adjustment of TCP MSS option in > the middle. Theory and practice are 2 different things. And so are compliance and noncompliance. To protect TCP but not protect TCP - to support noncompliant transits that silently modify packet contents - is to not provide security at the TCP layer. This is the sort of thing TCP needs protection from. TCP options can be used as attack vectors. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 25 13:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNDSm-0003Zm-1q; Sat, 25 Mar 2006 13:26:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNDSk-0003XH-Fy for tcpm@ietf.org; Sat, 25 Mar 2006 13:26:10 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNDSj-0002N7-6Y for tcpm@ietf.org; Sat, 25 Mar 2006 13:26:10 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2006 10:26:08 -0800 X-IronPort-AV: i="4.03,128,1141632000"; d="scan'208"; a="420097552:sNHT30988256" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2PIQ8Gv017397; Sat, 25 Mar 2006 10:26:08 -0800 (PST) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Mar 2006 10:26:08 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Sat, 25 Mar 2006 10:26:06 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5801599950@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZP1daZ+5Nn0zjTQG6SHyRiKVQrOQAYZHqw From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 25 Mar 2006 18:26:08.0486 (UTC) FILETIME=[95E5C860:01C65039] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Friday, March 24, 2006 10:31 PM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] draft-bonica and TCP segmentation >=20 > Anantha, >=20 > Anantha Ramaiah (ananth) wrote: > ... > >> Any modification of an IP packet in flight - excepting=20 > fragmentation=20 > >> of IPv4, or IP forwarding processing - is equivalent to=20 > (and should=20 > >> be treated as) an attack. > >=20 > > There are middleboxes out there today which intercepts and=20 > completes=20 > > the > > 3 way HS with the client and then does the same with the=20 > server. After=20 > > the connection goes to ESTAB state, the seq# and Ack# are adjusted=20 > > with the approproiate "delta". >=20 > That's called a TCP endpoint. The rest is a matter of intent. Hmm.. I don't understand which one you are referring as end-point. My above statement was referring to the TCP interceptors in the middle : "which takes care of the TCP 3 way handshake on behalf of the client and then completes the same with the server and after that each and every segment for the flow needs to be adjusted for the seq# and ack# by the interceptor". The below diagram is what I am talking about [Client]-------------TCP interceptor box------------------[Server] (TCP endpoint) (Middle box) (TCP endpoint) Of course if some segments take a different route then we are hosed, but this works today in the field :) In the above scenario MD5/IPsec cannot be used. I am not sure if we both are saying the same thing. Question becomes:=20 Do you guys want to make sure we add some text in the draft which explicitly states this assumption? -Anantha >=20 > TCP/MD5 and IPsec don't work beyond TCP endpoints or IP=20 > destinations, respectively - whether the endpoint that=20 > terminates either is 'authorized' to do so or not. >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 25 13:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNDbP-000099-Ap; Sat, 25 Mar 2006 13:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNDbO-00008w-LV for tcpm@ietf.org; Sat, 25 Mar 2006 13:35:06 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNDbM-0002fs-6P for tcpm@ietf.org; Sat, 25 Mar 2006 13:35:06 -0500 Received: from [128.9.176.73] ([128.9.176.73]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2PIY0w23663; Sat, 25 Mar 2006 10:34:00 -0800 (PST) Message-ID: <44258D11.3060606@isi.edu> Date: Sat, 25 Mar 2006 10:33:53 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <0C53DCFB700D144284A584F54711EC5801599950@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801599950@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 1.1 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: >> -----Original Message----- >> From: Joe Touch [mailto:touch@ISI.EDU] >> Sent: Friday, March 24, 2006 10:31 PM >> To: Anantha Ramaiah (ananth) >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] draft-bonica and TCP segmentation >> >> Anantha, >> >> Anantha Ramaiah (ananth) wrote: >> ... >>>> Any modification of an IP packet in flight - excepting >> fragmentation >>>> of IPv4, or IP forwarding processing - is equivalent to >> (and should >>>> be treated as) an attack. >>> There are middleboxes out there today which intercepts and >> completes >>> the >>> 3 way HS with the client and then does the same with the >> server. After >>> the connection goes to ESTAB state, the seq# and Ack# are adjusted >>> with the approproiate "delta". >> That's called a TCP endpoint. The rest is a matter of intent. > > Hmm.. I don't understand which one you are referring as end-point. Endpoint, as far as IP is concerned, is the IP destination address. Ditto for TCP - in particular, for TCP, it's the end with which state is shared and synchronized. > My > above statement was referring to the TCP interceptors in the middle : > "which takes care of the TCP 3 way handshake on behalf of the client and > then completes the same with the server and after that each and every > segment for the flow needs to be adjusted for the seq# and ack# by the > interceptor". Anything that terminates the TCP handshake on behalf of another endpoint IS the endpoint of that TCP connection... > The below diagram is what I am talking about > > [Client]-------------TCP interceptor box------------------[Server] > (TCP endpoint) (Middle box) (TCP endpoint) If the middlebox terminates the client's TCP connection, then what you have is a proxy system: client-------------------middlebox The rest of the connection is irrelevant to that TCP connection. TCP provides E2E reliable byte-stream communication only between _its_ endpoints. > Of course if some segments take a different route then we are hosed, but > this works today in the field :) > > In the above scenario MD5/IPsec cannot be used. That depends: - if the middlebox has the right keys, then MD5 or IPsec _can_ be used. In that case, the middlebox _is_ the endpoint of either layer. - if the middlebox does not have the right keys, then MD5/IPsec has _correctly_ prevented a man-in-the-middle _attack_ on TCP/IP (respectively). ... > Question becomes: > > Do you guys want to make sure we add some text in the draft which > explicitly states this assumption? This isn't needed. The fact is that security designed to prevent man-in-the-middle attacks prevents them. Whether 'attack' is how the middlebox behavior is intended isn't relevant; any unauthorized (lacking delegated keys) modification of these packets between the endpoints of the intended connection _is_ a de-facto attack. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 25 14:45:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNEhW-00071m-KZ; Sat, 25 Mar 2006 14:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNEhV-00071h-A9 for tcpm@ietf.org; Sat, 25 Mar 2006 14:45:29 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNEhU-0005D4-VR for tcpm@ietf.org; Sat, 25 Mar 2006 14:45:29 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 25 Mar 2006 11:45:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2PJjS7T007030; Sat, 25 Mar 2006 11:45:28 -0800 (PST) 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.211); Sat, 25 Mar 2006 11:45:28 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] draft-bonica and TCP segmentation Date: Sat, 25 Mar 2006 11:45:28 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5801599959@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] draft-bonica and TCP segmentation Thread-Index: AcZQOtU1MTP/pPENTV6VrxBvZ9+i0AABlwFw From: "Anantha Ramaiah \(ananth\)" To: "Joe Touch" X-OriginalArrivalTime: 25 Mar 2006 19:45:28.0161 (UTC) FILETIME=[AAE28D10:01C65044] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Comments inline... > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU]=20 > Sent: Saturday, March 25, 2006 10:34 AM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] draft-bonica and TCP segmentation >=20 >=20 >=20 > Anantha Ramaiah (ananth) wrote: > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Friday, March 24, 2006 10:31 PM > >> To: Anantha Ramaiah (ananth) > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] draft-bonica and TCP segmentation > >> > >> Anantha, > >> > >> Anantha Ramaiah (ananth) wrote: > >> ... > >>>> Any modification of an IP packet in flight - excepting > >> fragmentation > >>>> of IPv4, or IP forwarding processing - is equivalent to > >> (and should > >>>> be treated as) an attack. > >>> There are middleboxes out there today which intercepts and > >> completes > >>> the > >>> 3 way HS with the client and then does the same with the > >> server. After > >>> the connection goes to ESTAB state, the seq# and Ack# are=20 > adjusted=20 > >>> with the approproiate "delta". > >> That's called a TCP endpoint. The rest is a matter of intent. > >=20 > > Hmm.. I don't understand which one you are referring as end-point. >=20 > Endpoint, as far as IP is concerned, is the IP destination address. > Ditto for TCP - in particular, for TCP, it's the end with=20 > which state is shared and synchronized. Well I have seen and heard several ways of describing the endpoint clause. If we take layering into consideration, for TCP it is qualified by the 4 tuple (or a 5 tuple) [src addr and port, dest addr and port + VRF in some cases] But I don't intend to digress here. >=20 > > My > > above statement was referring to the TCP interceptors in=20 > the middle : > > "which takes care of the TCP 3 way handshake on behalf of=20 > the client=20 > > and then completes the same with the server and after that each and=20 > > every segment for the flow needs to be adjusted for the=20 > seq# and ack#=20 > > by the interceptor". >=20 > Anything that terminates the TCP handshake on behalf of=20 > another endpoint IS the endpoint of that TCP connection... >=20 > > The below diagram is what I am talking about > >=20 > > [Client]-------------TCP interceptor box------------------[Server] > > (TCP endpoint) (Middle box) =20 > (TCP endpoint) >=20 > If the middlebox terminates the client's TCP connection, then=20 > what you have is a proxy system: Nope.=20 TCP interceptor box in the diagram below doesn't "terminate" the TCP connection. In other words, the middle box doesn't create 2 TCB's for that "flow"=20 The middle box cleverly adjusts the seq# and ack#'s after the connection goes to ESTAB.. the state info which is kept here is very minimal... You may chose to call it as a light weight proxy, but it doesn't really terminate connections. >=20 > client-------------------middlebox >=20 > The rest of the connection is irrelevant to that TCP connection. >=20 > TCP provides E2E reliable byte-stream communication only=20 > between _its_ endpoints. >=20 > > Of course if some segments take a different route then we=20 > are hosed,=20 > > but this works today in the field :) > >=20 > > In the above scenario MD5/IPsec cannot be used. >=20 > That depends: >=20 > - if the middlebox has the right keys, then MD5 or IPsec=20 > _can_ be used. > In that case, the middlebox _is_ the endpoint of either layer. >=20 > - if the middlebox does not have the right keys, then=20 > MD5/IPsec has _correctly_ prevented a man-in-the-middle=20 > _attack_ on TCP/IP (respectively). Same thoughts here. When I meant IPsec/MD5 cannot be used, I assumed that the middle box doesn't possess the necessary keys. >=20 > ... > > Question becomes:=20 > >=20 > > Do you guys want to make sure we add some text in the draft which=20 > > explicitly states this assumption? >=20 > This isn't needed. The fact is that security designed to=20 > prevent man-in-the-middle attacks prevents them. Whether=20 > 'attack' is how the middlebox behavior is intended isn't=20 > relevant; any unauthorized (lacking delegated keys)=20 > modification of these packets between the endpoints of the=20 > intended connection _is_ a de-facto attack. Ok. I wasn't sure since it was pointed out in the thread that this needs to be added somewhere in the draft. Thanks for the discussion. -Anantha >=20 > Joe >=20 _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Mar 25 16:45:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGZP-0004fG-42; Sat, 25 Mar 2006 16:45:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNGZN-0004ar-7i for tcpm@ietf.org; Sat, 25 Mar 2006 16:45:13 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNGZL-0001tZ-Ok for tcpm@ietf.org; Sat, 25 Mar 2006 16:45:13 -0500 Received: from [128.9.176.73] ([128.9.176.73]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2PLiqw01670; Sat, 25 Mar 2006 13:44:52 -0800 (PST) Message-ID: <4425B9CD.5060804@isi.edu> Date: Sat, 25 Mar 2006 13:44:45 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" Subject: Re: [tcpm] draft-bonica and TCP segmentation References: <0C53DCFB700D144284A584F54711EC5801599959@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5801599959@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Anantha Ramaiah (ananth) wrote: > Comments inline... >> Endpoint, as far as IP is concerned, is the IP destination address. >> Ditto for TCP - in particular, for TCP, it's the end with >> which state is shared and synchronized. > > Well I have seen and heard several ways of describing the endpoint > clause. If we take layering into consideration, for TCP it is qualified > by the 4 tuple (or a 5 tuple) [src addr and port, dest addr and port + Point taken. > VRF in some cases] Not for TCP. TCP is endpoint-based; it attaches to IP addresses. If you want to support a weak host model for routing, that's fine, but it does not impact TCP. ... >> Anything that terminates the TCP handshake on behalf of >> another endpoint IS the endpoint of that TCP connection... >> >>> The below diagram is what I am talking about >>> >>> [Client]-------------TCP interceptor box------------------[Server] >>> (TCP endpoint) (Middle box) >> (TCP endpoint) >> >> If the middlebox terminates the client's TCP connection, then >> what you have is a proxy system: > > Nope. > > TCP interceptor box in the diagram below doesn't "terminate" the TCP > connection. Did it reply to the SYN? Then it terminated the connection. How it implemented that internally is its own business. > In other words, the middle box doesn't create 2 TCB's for > that "flow" > The middle box cleverly adjusts the seq# and ack#'s after the connection > goes to ESTAB.. the state info which is kept here is very minimal... You > may chose to call it as a light weight proxy, but it doesn't really > terminate connections. "cleverly adjusts" = uses some algorithm - which isn't relevant as far as the client is concerned = to determine how to emulate the behavior of the destination. It doesn't matter how - or more specifically why - the midbox is acting as the destination. It IS. On the rest of the points we seem to be agreeing ;-) Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Mar 29 11:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdXc-00010S-1e; Wed, 29 Mar 2006 11:29:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOdXa-000102-TB; Wed, 29 Mar 2006 11:29:02 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOdXa-0004qf-MD; Wed, 29 Mar 2006 11:29:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2TGSxBX031010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2006 16:28:59 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FOdXX-0006cj-8y; Wed, 29 Mar 2006 11:28:59 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 29 Mar 2006 11:28:59 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tcpm mailing list , Internet Architecture Board , tcpm chair , tcpm chair , RFC Editor Subject: [tcpm] Document Action: 'A Roadmap for TCP Specification Documents' to Informational RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has approved the following document: - 'A Roadmap for TCP Specification Documents ' as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt Technical Summary This document contains a "roadmap" to the RFCs relating to the Internet's TCP. This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. Working Group Summary The advancement of this document is supported by the TCPM WG. Protocol Quality This protocol was reviewed for the IESG by Mark Allman and Jon Peterson Note to RFC Editor OLD: (from section 3.1) Since TCP traditionally (in the absence of ECN) uses losses to infer congestion, there is a rather intimate coupling between congestion control and loss recovery mechanisms. NEW: TCP traditionally treats lost packets as indicating congestion-related loss, and cannot distinguish between congestion-related loss and loss due to transmission errors. Even when ECN is in use, there is a rather intimate coupling between congestion control and loss recovery mechanisms. === OLD: (from section 3.3) A draft that is currently in the RFC Editor's queue for publication [tcpmd5app] deprecates TCP MD5 for use outside BGP. NEW: RFC 4278 deprecates the use of TCP MD5 outside BGP [RFC4278]. Please change [tcpmd5app] to reference RFC 4278. === OLD: (from section 6.4) RFC 2452 S: "IP Version 6 Management Information Base for the Transmission Control Protocol" (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. NEW: RFC 2452 S: "IP Version 6 Management Information Base for the Transmission Control Protocol" (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. RFC 2012 is now obsoleted by RFC 4022. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 14:07:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOxp-00061m-5u; Fri, 31 Mar 2006 14:07:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPOxo-00061e-86; Fri, 31 Mar 2006 14:07:16 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPOxn-00008H-26; Fri, 31 Mar 2006 14:07:16 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2VJ7EBX018293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Mar 2006 19:07:14 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FPOxm-0001uz-Qq; Fri, 31 Mar 2006 14:07:14 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 31 Mar 2006 14:07:14 -0500 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org Subject: [tcpm] Last Call: 'Improving the Robustness of TCP to Non-Congestion Events' to Experimental RFC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org The IESG has received a request from the TCP Maintenance and Minor Extensions WG to consider the following document: - 'Improving the Robustness of TCP to Non-Congestion Events ' as an Experimental RFC draft-ietf-tcpm-tcp-dcr-07.txt has been submitted for consideration as an Experimental RFC to enable implementation of and experimentation with the TCP-NCR extensions in limited scenarios, in order to determine their suitability for wider-scale deployment. TCP-NCR should not currently be deployed on a large scale in the Internet. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 16:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRMY-0007yp-6E; Fri, 31 Mar 2006 16:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRMW-0007yg-6y for tcpm@ietf.org; Fri, 31 Mar 2006 16:40:56 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRMV-0007cn-Us for tcpm@ietf.org; Fri, 31 Mar 2006 16:40:56 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1FPRMV-0000So-00 for ; Fri, 31 Mar 2006 16:40:55 -0500 Date: Fri, 31 Mar 2006 16:40:55 -0500 (EST) From: Scott Leibrand To: tcpm@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [tcpm] "TCP Multipath" with shim6 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org I recently had an idea that I've brought up to the shim6 list, and would also like to bring up here. The basic idea is to extend TCP to use shim6 and its context forking feature to allow a single TCP session to simultaneously transmit over two paths (defined by two locator pairs) and use the full bandwidth of each. Say you have two shim6-capable hosts, and at least one of them has two transit connections (say DSL + Cable) with two corresponding locators. Now say the two hosts establish a connection, start sending traffic, and establish shim6 state. Now say that the multihomed host has lots of data to send, and is in congestion avoidance on the default (ULID-ULID) path. Now say that he has implemented some TCP extensions that allow him to invoke shim6 context forking and simultaneously send packets with the shim6 context tag over the second locator pair while continuing to send packets over the ULID-ULID pair. The extended TCP stack would independently track the congestion windows (and run the TCP congestion avoidance algorithm) for each shim6 context (locator pair). This would allow the sending host to fully utilize the available bandwidth on both his links for a single TCP session, which otherwise would be impossible (without bonding the two links with some sort of per-packet load balancing, which has all kinds of problems). It would require some modifications to the sending host in order to keep a separate set of state variables for each context/path, but the receiving host need only do ordinary shim6, and TCP SACK to selectively ack packets as they came in. Since the shim would be in place, the recipient's TCP stack would be completely unaware of the fact that his packets are coming over two different paths. One obvious challenge the modified TCP stack would have to deal with is that the use of two paths with differing RTTs will all but guarantee lots of duplicate ACKs. The modified TCP sender would need to modify its duplicate ACK processing with some algorithms to keep track of which packets were sent over which path, and detect which duplicate ACKs actually indicate packet drops (which you would know when SACK says you've received at least 3 additional segments sent over the same path). In addition, the modified TCP receiver has to be careful not to confuse an unmodified TCP sender. The most straightforward way to accomplish this is to send all ACKs over the first context (the "normal" path), and only send data packets over the second context/path. This ensures that the unmodified TCP sender always measures RTT consistently, and doesn't get any out-of-order ACKs. Another optimization I've thought of is to steal SCTP's idea of doing all retransmissions over a different path/context from the one they were originally sent on, so as to not be held back by (or exacerbate) the congestion that caused the retransmission in the first place. All of this would of course require close integration of the modified TCP sender with the shim layer via the shim6 API, to do the context forking, pick a divergent pair of locators, be notified of and respond appropriately to any locator rehoming on either context, etc. Can anyone think of any problems with this approach? If not, should I start writing up an Internet-Draft on it? Would such an I-D eventually be considered by this WG, or elsewhere? (Dallas was my first IETF, so if anyone has any other newbie advice, feel free to speak up.) If I'm not missing anything big, and this is indeed workable, I think this could be a very popular feature, and could help push shim6 adoption onto a wide enough installed base to actually make it useful for multihoming as well. Thanks, Scott _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:00:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRfP-0006XE-Nt; Fri, 31 Mar 2006 17:00:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRfN-0006Ql-UN for tcpm@ietf.org; Fri, 31 Mar 2006 17:00:25 -0500 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRfN-0000E5-Hm for tcpm@ietf.org; Fri, 31 Mar 2006 17:00:25 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 31 Mar 2006 14:00:16 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id A1CE12AF; Fri, 31 Mar 2006 14:00:16 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7D4AD2AE; Fri, 31 Mar 2006 14:00:16 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DFA67525; Fri, 31 Mar 2006 14:00:16 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 0BA4020501; Fri, 31 Mar 2006 14:00:15 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] "TCP Multipath" with shim6 Date: Fri, 31 Mar 2006 14:00:15 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13C96B0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] "TCP Multipath" with shim6 Thread-Index: AcZVC9Y3SvHQ+wNcRKO/D/adv/hUIwAAkctA From: "Caitlin Bestler" To: "Scott Leibrand" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006033107; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230382E34343244413539432E303030412D412D; ENG=IBF; TS=20060331220019; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006033107_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683379FA3NG4429758-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Scott Leibrand wrote: > I recently had an idea that I've brought up to the shim6 > list, and would also like to bring up here. The basic idea > is to extend TCP to use shim6 and its context forking feature > to allow a single TCP session to simultaneously transmit over > two paths (defined by two locator pairs) and use the full bandwidth > of each.=20 >=20 > Say you have two shim6-capable hosts, and at least one of > them has two transit connections (say DSL + Cable) with two > corresponding locators. Now say the two hosts establish a > connection, start sending traffic, and establish shim6 state. > Now say that the multihomed host has lots of data to send, > and is in congestion avoidance on the default (ULID-ULID) path. > Now say that he has implemented some TCP extensions that > allow him to invoke shim6 context forking and simultaneously send > packets with the shim6 context tag over the second locator pair while > continuing to send packets over the ULID-ULID pair. The > extended TCP stack would independently track the congestion > windows (and run the TCP congestion avoidance algorithm) for > each shim6 context (locator pair). >=20 > This would allow the sending host to fully utilize the > available bandwidth on both his links for a single TCP > session, which otherwise would be impossible (without bonding > the two links with some sort of per-packet load balancing, > which has all kinds of problems). It would require some > modifications to the sending host in order to keep a separate > set of state variables for each context/path, but the > receiving host need only do ordinary shim6, and TCP SACK to > selectively ack packets as they came in. > Since the shim would be in place, the recipient's TCP stack > would be completely unaware of the fact that his packets are > coming over two different paths. >=20 > One obvious challenge the modified TCP stack would have to > deal with is that the use of two paths with differing RTTs > will all but guarantee lots of duplicate ACKs. The modified > TCP sender would need to modify its duplicate ACK processing > with some algorithms to keep track of which packets were sent > over which path, and detect which duplicate ACKs actually > indicate packet drops (which you would know when SACK says > you've received at least 3 additional segments sent over the same > path).=20 >=20 > In addition, the modified TCP receiver has to be careful not > to confuse an unmodified TCP sender. The most > straightforward way to accomplish this is to send all ACKs > over the first context (the "normal" path), and only send > data packets over the second context/path. This ensures that > the unmodified TCP sender always measures RTT consistently, > and doesn't get any out-of-order ACKs. >=20 > Another optimization I've thought of is to steal SCTP's idea > of doing all retransmissions over a different path/context > from the one they were originally sent on, so as to not be > held back by (or exacerbate) the congestion that caused the > retransmission in the first place. >=20 > All of this would of course require close integration of the > modified TCP sender with the shim layer via the shim6 API, to > do the context forking, pick a divergent pair of locators, be > notified of and respond appropriately to any locator rehoming on > either context, etc.=20 >=20 > Can anyone think of any problems with this approach? If not, > should I start writing up an Internet-Draft on it? Would > such an I-D eventually be considered by this WG, or > elsewhere? (Dallas was my first IETF, so if anyone has any > other newbie advice, feel free to speak up.) >=20 > If I'm not missing anything big, and this is indeed workable, > I think this could be a very popular feature, and could help > push shim6 adoption onto a wide enough installed base to > actually make it useful for multihoming as well. >=20 > Thanks, > Scott >=20 The only valid reason not to use SCTP for this type of problem is the ubiquitous deployment of low-end middleboxes that do not know how to NAT SCTP connections (beyond passing anything that they do not recognize to a single internal host). Has anyone conducted a survey to see how many of these boxes properly support IPv6? I would be pleasantly surprised if their limitations only impacted SCTP and that IPv6 was fully supported. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRgR-0007Yh-Bw; Fri, 31 Mar 2006 17:01:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRgP-0007Yc-TY for tcpm@ietf.org; Fri, 31 Mar 2006 17:01:29 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRgO-0000Ki-JJ for tcpm@ietf.org; Fri, 31 Mar 2006 17:01:29 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1FPRgO-0000UY-00 for ; Fri, 31 Mar 2006 17:01:28 -0500 Date: Fri, 31 Mar 2006 17:01:28 -0500 (EST) From: Scott Leibrand To: tcpm@ietf.org Subject: Re: [tcpm] "TCP Multipath" with shim6 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org One other thing I didn't mention: this idea looks to be very similar to a similar feature being developed for SCTP by the University of Delaware's Protocol Engineering laboratory: http://www.eecis.udel.edu/~amer/PEL/poc/index.html#sctp I came up with the TCP multipath idea (and name) independently, and another poster on the shim6 mailing list pointed me to the SCTP work, which looks very similar. I haven't read the journal articles yet (just the webpage), but I'm sure they address the same issues I enumerated below, and others I haven't thought of yet, so it looks like I'll be doing some reading this weekend. :) -Scott On 03/31/06 at 4:40pm -0500, Scott Leibrand wrote: > I recently had an idea that I've brought up to the shim6 list, and would > also like to bring up here. The basic idea is to extend TCP to use shim6 > and its context forking feature to allow a single TCP session to > simultaneously transmit over two paths (defined by two locator pairs) and > use the full bandwidth of each. > > Say you have two shim6-capable hosts, and at least one of them has two > transit connections (say DSL + Cable) with two corresponding locators. Now > say the two hosts establish a connection, start sending traffic, and > establish shim6 state. Now say that the multihomed host has lots of data > to send, and is in congestion avoidance on the default (ULID-ULID) path. > Now say that he has implemented some TCP extensions that allow him to > invoke shim6 context forking and simultaneously send packets with the > shim6 context tag over the second locator pair while continuing to send > packets over the ULID-ULID pair. The extended TCP stack would > independently track the congestion windows (and run the TCP congestion > avoidance algorithm) for each shim6 context (locator pair). > > This would allow the sending host to fully utilize the available bandwidth > on both his links for a single TCP session, which otherwise would be > impossible (without bonding the two links with some sort of per-packet > load balancing, which has all kinds of problems). It would require some > modifications to the sending host in order to keep a separate set of state > variables for each context/path, but the receiving host need only do > ordinary shim6, and TCP SACK to selectively ack packets as they came in. > Since the shim would be in place, the recipient's TCP stack would be > completely unaware of the fact that his packets are coming over two > different paths. > > One obvious challenge the modified TCP stack would have to deal with is > that the use of two paths with differing RTTs will all but guarantee lots > of duplicate ACKs. The modified TCP sender would need to modify its > duplicate ACK processing with some algorithms to keep track of which > packets were sent over which path, and detect which duplicate ACKs > actually indicate packet drops (which you would know when SACK says you've > received at least 3 additional segments sent over the same path). > > In addition, the modified TCP receiver has to be careful not to confuse an > unmodified TCP sender. The most straightforward way to accomplish this is > to send all ACKs over the first context (the "normal" path), and only send > data packets over the second context/path. This ensures that the > unmodified TCP sender always measures RTT consistently, and doesn't get > any out-of-order ACKs. > > Another optimization I've thought of is to steal SCTP's idea of doing all > retransmissions over a different path/context from the one they were > originally sent on, so as to not be held back by (or exacerbate) > the congestion that caused the retransmission in the first place. > > All of this would of course require close integration of the modified TCP > sender with the shim layer via the shim6 API, to do the context forking, > pick a divergent pair of locators, be notified of and respond > appropriately to any locator rehoming on either context, etc. > > Can anyone think of any problems with this approach? If not, should I > start writing up an Internet-Draft on it? Would such an I-D eventually be > considered by this WG, or elsewhere? (Dallas was my first IETF, so if > anyone has any other newbie advice, feel free to speak up.) > > If I'm not missing anything big, and this is indeed workable, I think this > could be a very popular feature, and could help push shim6 adoption onto a > wide enough installed base to actually make it useful for multihoming as > well. > > Thanks, > Scott > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www1.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRgh-0007cc-IY; Fri, 31 Mar 2006 17:01:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRgg-0007cX-RL for tcpm@ietf.org; Fri, 31 Mar 2006 17:01:46 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRgf-0000LB-Cg for tcpm@ietf.org; Fri, 31 Mar 2006 17:01:46 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2VM1GG00759; Fri, 31 Mar 2006 14:01:16 -0800 (PST) Message-ID: <442DA634.4050503@isi.edu> Date: Fri, 31 Mar 2006 13:59:16 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Scott Leibrand Subject: Re: [tcpm] "TCP Multipath" with shim6 References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Leibrand wrote: > I recently had an idea that I've brought up to the shim6 list, and would > also like to bring up here. The basic idea is to extend TCP to use shim6 > and its context forking feature to allow a single TCP session to > simultaneously transmit over two paths (defined by two locator pairs) and > use the full bandwidth of each. It sounds more like you want SCTP than TCP; see below... > Say you have two shim6-capable hosts, and at least one of them has two > transit connections (say DSL + Cable) with two corresponding locators. Now > say the two hosts establish a connection, start sending traffic, and > establish shim6 state. Now say that the multihomed host has lots of data > to send, and is in congestion avoidance on the default (ULID-ULID) path. > Now say that he has implemented some TCP extensions that allow him to > invoke shim6 context forking and simultaneously send packets with the > shim6 context tag over the second locator pair while continuing to send > packets over the ULID-ULID pair. The extended TCP stack would > independently track the congestion windows (and run the TCP congestion > avoidance algorithm) for each shim6 context (locator pair). > > This would allow the sending host to fully utilize the available bandwidth > on both his links for a single TCP session, which otherwise would be > impossible (without bonding the two links with some sort of per-packet > load balancing, which has all kinds of problems). It would require some > modifications to the sending host in order to keep a separate set of state > variables for each context/path, but the receiving host need only do > ordinary shim6, and TCP SACK to selectively ack packets as they came in. > Since the shim would be in place, the recipient's TCP stack would be > completely unaware of the fact that his packets are coming over two > different paths. Except for reordering at the receiver, which would be exacerbated. > One obvious challenge the modified TCP stack would have to deal with is > that the use of two paths with differing RTTs will all but guarantee lots > of duplicate ACKs. The modified TCP sender would need to modify its > duplicate ACK processing with some algorithms to keep track of which > packets were sent over which path, and detect which duplicate ACKs > actually indicate packet drops (which you would know when SACK says you've > received at least 3 additional segments sent over the same path). Different RTTs, different congestion windows, etc. I.e., it seems even more complicated than you're hinting at. > In addition, the modified TCP receiver has to be careful not to confuse an > unmodified TCP sender. The most straightforward way to accomplish this is > to send all ACKs over the first context (the "normal" path), and only send > data packets over the second context/path. This ensures that the > unmodified TCP sender always measures RTT consistently, and doesn't get > any out-of-order ACKs. ACKs can come out-of-order on a single TCP connection. And if the forward channel benefits from multipath, so would the reverse. More specifically, if the backward channel is simplified by using a single path, so is the forward - and you're back to existing TCP! ;-) > Another optimization I've thought of is to steal SCTP's idea of doing all > retransmissions over a different path/context from the one they were > originally sent on, so as to not be held back by (or exacerbate) > the congestion that caused the retransmission in the first place. Why not just use SCTP at that point? > All of this would of course require close integration of the modified TCP > sender with the shim layer via the shim6 API, to do the context forking, > pick a divergent pair of locators, be notified of and respond > appropriately to any locator rehoming on either context, etc. > > Can anyone think of any problems with this approach? You seem to have listed more than enough above. ;-) > If not, should I > start writing up an Internet-Draft on it? Would such an I-D eventually be > considered by this WG, or elsewhere? (Dallas was my first IETF, so if > anyone has any other newbie advice, feel free to speak up.) > > If I'm not missing anything big, and this is indeed workable, I think this > could be a very popular feature, and could help push shim6 adoption onto a > wide enough installed base to actually make it useful for multihoming as > well. Hacking TCP to provide something SCTP - or even BXXP over separate TCP connections - would provide seems like a poor way to justify the need for Shim6. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFELaY0E5f5cImnZrsRAlBhAKDVnFzcoFJm+cAdAViuhLDhLJOKZQCcCk10 1ZaQv6HDXc7uNjBjNR6XoFQ= =j5Vm -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:20:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRyZ-0005Nr-6w; Fri, 31 Mar 2006 17:20:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRyX-0005LT-PB for tcpm@ietf.org; Fri, 31 Mar 2006 17:20:13 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRxT-00014s-7x for tcpm@ietf.org; Fri, 31 Mar 2006 17:19:07 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1FPRxC-0000WI-00; Fri, 31 Mar 2006 17:18:50 -0500 Date: Fri, 31 Mar 2006 17:18:50 -0500 (EST) From: Scott Leibrand To: Joe Touch , Caitlin Bestler Subject: Re: [tcpm] "TCP Multipath" with shim6 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F13C96B4@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <54AD0F12E08D1541B826BE97C98F99F13C96B4@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 03/31/06 at 1:59pm -0800, Joe Touch wrote: > > Can anyone think of any problems with this approach? > > You seem to have listed more than enough above. ;-) Heh. On 03/31/06 at 2:07pm -0800, Caitlin Bestler wrote: > Joe Touch wrote: > > > Hacking TCP to provide something SCTP - or even BXXP over > > separate TCP connections - would provide seems like a poor > > way to justify the need for Shim6. > > More generally, any attempt to hack TCP to provide something > SCTP like is inherently an interim strategy to work around > middlebox shortcomings. Wouldn't it also be a way to get around the shortcoming that most operating systems don't support SCTP? Of course, most TCP/IP stacks don't support shim6 either, so we'll have to see which gets widespread support (particularly in Windows) first... > As long as you are playing that game, IPv4 support and NAT compatibility > is essential. Point taken. IPv4 support is on the roadmap for shim6, but not NAT (yet). > If you are dealing with how the network SHOULD work then you SHOULD use > SCTP and write a shim to pack byte streams into chunk streams (assuming > your application was truly byte-stream oriented in the first place, if > it was already truly message oriented then the shift to SCTP is even > simpler). Yeah. My background is in Network Operations and only recently Engineering, so my focus is to try to come up with solutions that can be unilaterally implemented and interoperate with the existing userbase. I agree that SCTP is better suited to multipath than TCP (although TCP+shim6 is close, it's a few years behind). Perhaps I should focus on SCTP for now, and keep this idea in my back pocket in case shim6 gets more widespread adoption than SCTP... -Scott _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRzh-0006Nw-CF; Fri, 31 Mar 2006 17:21:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRyo-0005Ze-Bh for tcpm@ietf.org; Fri, 31 Mar 2006 17:20:30 -0500 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRme-0000YL-N3 for tcpm@ietf.org; Fri, 31 Mar 2006 17:07:58 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 31 Mar 2006 14:07:45 -0800 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 93B412AE; Fri, 31 Mar 2006 14:07:45 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 141642B0; Fri, 31 Mar 2006 14:07:41 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id DFA69697; Fri, 31 Mar 2006 14:07:41 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 746C920501; Fri, 31 Mar 2006 14:07:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] "TCP Multipath" with shim6 Date: Fri, 31 Mar 2006 14:07:40 -0800 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13C96B4@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] "TCP Multipath" with shim6 Thread-Index: AcZVDr0IiJWZ63woTkqUCH/W5O1YSwAAE8CQ From: "Caitlin Bestler" To: "Joe Touch" , "Scott Leibrand" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006033108; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343244413735422E303031432D412D; ENG=IBF; TS=20060331220747; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006033108_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 683377BB1741971485-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org Joe Touch wrote: >=20 > Hacking TCP to provide something SCTP - or even BXXP over > separate TCP connections - would provide seems like a poor > way to justify the need for Shim6. >=20 More generally, any attempt to hack TCP to provide something SCTP like is inherently an interim strategy to work around middlebox shortcomings. As long as you are playing that game, IPv4 support and NAT compatability is essential. If you are dealing with how the network SHOULD work then you SHOULD use SCTP and write a shim to pack byte streams into chunk streams (assuming your application was truly byte-stream oriented in the first place, if it was already truly message oriented then the shift to SCTP is even simpler). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:21:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRzp-0006en-3f; Fri, 31 Mar 2006 17:21:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPRyn-0005Ze-Uu for tcpm@ietf.org; Fri, 31 Mar 2006 17:20:29 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPRn3-0000bG-QR for tcpm@ietf.org; Fri, 31 Mar 2006 17:08:22 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1FPRmy-0000V7-00; Fri, 31 Mar 2006 17:08:16 -0500 Date: Fri, 31 Mar 2006 17:08:16 -0500 (EST) From: Scott Leibrand To: Caitlin Bestler Subject: RE: [tcpm] "TCP Multipath" with shim6 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F13C96B0@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <54AD0F12E08D1541B826BE97C98F99F13C96B0@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 03/31/06 at 2:00pm -0800, Caitlin Bestler wrote: > The only valid reason not to use SCTP for this type of problem > is the ubiquitous deployment of low-end middleboxes that do not > know how to NAT SCTP connections (beyond passing anything that > they do not recognize to a single internal host). Do you know if support for multipath SCTP can be implemented independently on the sender side without support from the receiver side? (If you don't know, I'm sure I'll find out when I read those articles). If not, and SCTP multipath requires support on both ends, that might be another reason to use TCP multipath over shim6 instead of SCTP multipath. > Has anyone conducted a survey to see how many of these boxes > properly support IPv6? I would be pleasantly surprised if their > limitations only impacted SCTP and that IPv6 was fully supported. I haven't done any surveys, but others have expressed frustration with NAT boxes that doesn't support IPv6 (or allow "unknown" protocols to allow transitional strategies). However, I wonder if SCTP (or shim6, for that matter) will be supported when NAT vendors start to roll out "enhanced NAT" boxes that NAT IPv4 and also provide (non-NAT'd) IPv6 support. -Scott _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 17:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSLJ-00075F-CC; Fri, 31 Mar 2006 17:43:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSLI-00072t-4b for tcpm@ietf.org; Fri, 31 Mar 2006 17:43:44 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPSLG-00027G-Os for tcpm@ietf.org; Fri, 31 Mar 2006 17:43:44 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2VMh4G13067; Fri, 31 Mar 2006 14:43:04 -0800 (PST) Message-ID: <442DAFFF.7090900@isi.edu> Date: Fri, 31 Mar 2006 14:41:03 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Scott Leibrand Subject: Re: [tcpm] "TCP Multipath" with shim6 References: <54AD0F12E08D1541B826BE97C98F99F13C96B4@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scott Leibrand wrote: > On 03/31/06 at 1:59pm -0800, Joe Touch wrote: > >>> Can anyone think of any problems with this approach? >> You seem to have listed more than enough above. ;-) > > Heh. > > On 03/31/06 at 2:07pm -0800, Caitlin Bestler wrote: > >> Joe Touch wrote: >> >>> Hacking TCP to provide something SCTP - or even BXXP over >>> separate TCP connections - would provide seems like a poor >>> way to justify the need for Shim6. >> More generally, any attempt to hack TCP to provide something >> SCTP like is inherently an interim strategy to work around >> middlebox shortcomings. > > Wouldn't it also be a way to get around the shortcoming that most > operating systems don't support SCTP? Of course, most TCP/IP stacks don't > support shim6 either, so we'll have to see which gets widespread support > (particularly in Windows) first... That's the problem. You can't address the lack of SCTP deployment by introducing a new lack of TCP-multipath deployment ;-) Alternately, just call SCTP "TCP-multipath" and you're basically done, right? >> As long as you are playing that game, IPv4 support and NAT compatibility >> is essential. > > Point taken. IPv4 support is on the roadmap for shim6, but not NAT (yet). I'm not sure I agree with the issue of NATs; NATs are a moving target that wants to be taken seriously but also wants to silently violate whatever architectural principles it wants for its own benefit. It's impossible to design systems to work with that - it just ends up 'mutual escalation'. >> If you are dealing with how the network SHOULD work then you SHOULD use >> SCTP and write a shim to pack byte streams into chunk streams (assuming >> your application was truly byte-stream oriented in the first place, if >> it was already truly message oriented then the shift to SCTP is even >> simpler). > > Yeah. My background is in Network Operations and only recently > Engineering, so my focus is to try to come up with solutions that can be > unilaterally implemented and interoperate with the existing userbase. I > agree that SCTP is better suited to multipath than TCP (although TCP+shim6 > is close, it's a few years behind). Perhaps I should focus on SCTP for > now, and keep this idea in my back pocket in case shim6 gets more > widespread adoption than SCTP... The key question is what shim6 provides and for whom. Right now, we have competing solutions - shim6, HIP, SCTP - granted, at different layers, but still similar w.r.t. multihoming. The big question is how many solutions do we need or want? Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFELa//E5f5cImnZrsRAnYuAJ9sXDwZe1pum+DllL/fX+OI0kF4rQCglK1O tpSHEegi8vsLJXynzUBXxrI= =K/v6 -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 18:23:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSy8-00077c-3n; Fri, 31 Mar 2006 18:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPSy7-000772-0d for tcpm@ietf.org; Fri, 31 Mar 2006 18:23:51 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPSy5-00040P-NZ for tcpm@ietf.org; Fri, 31 Mar 2006 18:23:50 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FPSxc-0000jO-00; Fri, 31 Mar 2006 18:23:20 -0500 From: Tim Shepard To: Joe Touch Subject: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) In-reply-to: Your message of Fri, 31 Mar 2006 13:59:16 -0800. <442DA634.4050503@isi.edu> Date: Fri, 31 Mar 2006 18:23:20 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org For the past year or two, I've heard "SCTP" proffered by many people as the answer to a variety of questions. I've given the SCTP specification a very quick scan last week while in Dallas, and I've learned bits and pieces about it over the years. SCTP does indeed seem to be cool, and a better framework into which to put all sorts of desired functionality. So if SCTP is the answer (to multihoming, multipath, general locator agility, etc.), and the applications I want to use between my multi-homed laptop and the various servers that I use are things like ssh, imap, and xmpp, what steps do I need to take to start experiencing all of the wonderfulness that is SCTP? Are the various port numbers assigned by IANA for TCP use that sshd, imapd, and jabberd are already listening on implicitly assigned for SCTP use as well? Is the right thing to do to put something in the stack such that when a (perhaps legacy) daemon that opens a TCP listener on some port number to also have the stack listen on the same numbered SCTP port in case some client wants to use SCTP instead? Is there a document anywhere describing how the TCP to SCTP transition is supposed to be accomplished? Are we going to be running dual-stack for a number of years or decades while the transition is underway? I too have been thinking about adding locator agility awareness to TCP, and I've mentioned it to a few people over the past year. A few people have told me I should perhaps contribute my ideas to SCTP implementations instead of TCP implementations. But since most or perhaps all of the applications I care about making work better when there is locator agility stuff happening run on TCP, it seems that improving SCTP's behavior wouldn't help my stuff run better. What should I (or we) do? Should tcpm's charter be expanded to include similar tweaking of SCTP? Or should we have an sctpm WG? In the int-area meeting in Dallas, it was pointed out that some folks are designing protocols for IPv4 only, with no IPv6 story. It was suggested that drafts should have an "IPv6 considerations" section. Should the various drafts in tcpm WG for tweaks to TCP's behaviour have an "SCTP considerations" section? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Mar 31 21:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWBq-0005jO-JW; Fri, 31 Mar 2006 21:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWBo-0005jJ-SM for tcpm@ietf.org; Fri, 31 Mar 2006 21:50:12 -0500 Received: from sleibrand-ibm.acs.internap.com ([63.251.67.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPWBo-00064g-Kx for tcpm@ietf.org; Fri, 31 Mar 2006 21:50:12 -0500 Received: from sleibrand (helo=localhost) by sleibrand-ibm.acs.internap.com with local-esmtp (v3.35.1) id 1FPWBf-0000sE-00; Fri, 31 Mar 2006 21:50:03 -0500 Date: Fri, 31 Mar 2006 21:50:03 -0500 (EST) From: Scott Leibrand To: Joe Touch Subject: Re: [tcpm] "TCP Multipath" with shim6 In-Reply-To: <442DAFFF.7090900@isi.edu> Message-ID: References: <54AD0F12E08D1541B826BE97C98F99F13C96B4@NT-SJCA-0751.brcm.ad.broadcom.com> <442DAFFF.7090900@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: tcpm@ietf.org X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tcpm-bounces@ietf.org On 03/31/06 at 2:41pm -0800, Joe Touch wrote: > Scott Leibrand wrote: > > Wouldn't it also be a way to get around the shortcoming that most > > operating systems don't support SCTP? Of course, most TCP/IP stacks don't > > support shim6 either, so we'll have to see which gets widespread support > > (particularly in Windows) first... > > That's the problem. You can't address the lack of SCTP deployment by > introducing a new lack of TCP-multipath deployment ;-) More precisely, the lack of shim6 deployment. Because if the recipient doesn't support TCP-multipath, that's OK. He can still *receive* multipath (and not even know it, except that "it's faster") if he supports shim6. As a new layer 3 protocol, shim6 adoption may be easier than getting enough applications changed to call SCTP instead of TCP to make a difference. > Alternately, just call SCTP "TCP-multipath" and you're basically done, > right? No, because for that to work, both sides have to use SCTP *instead* of TCP. For TCP+shim6 multipath, OS's just have to be updated to be shim6 compatible. IMO it's easier to add shim6 to a TCP/IP stack, and just have it sitting there ready to spring into action upon receipt of a shim6 I1 message, than to try to convince every application developer out there of the benefits to rewriting their application (or the socket calls) to try SCTP first, and if that fails try TCP. > > Yeah. My background is in Network Operations and only recently > > Engineering, so my focus is to try to come up with solutions that can be > > unilaterally implemented and interoperate with the existing userbase. I > > agree that SCTP is better suited to multipath than TCP (although TCP+shim6 > > is close, it's a few years behind). Perhaps I should focus on SCTP for > > now, and keep this idea in my back pocket in case shim6 gets more > > widespread adoption than SCTP... > > The key question is what shim6 provides and for whom. Right now, we have > competing solutions - shim6, HIP, SCTP - granted, at different layers, > but still similar w.r.t. multihoming. The big question is how many > solutions do we need or want? Well, the reason we need or want multiple solutions is not so that they'll all get implemented on your grandmother's PC, but rather so that they can compete for early adopters, and you have a greater likelihood that at least one of them might prove useful enough to get widespread adoption. Put another way, different protocols were designed for different niche uses, and while they may be architecturally similar, in the real world of getting them to work well enough for people to actually use them, the fact that they operate at different layers, or have other subtle differences, can be the difference between viable for widespread use and a niche protocol which can never improve the Internet experience for your grandma (or your precocious nephew with a server farm in his basement). -Scott _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm