From tcpm-bounces@ietf.org Mon Apr 03 11:41:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRBJ-0000np-A0; Mon, 03 Apr 2006 11:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRBI-0000nj-H7 for tcpm@ietf.org; Mon, 03 Apr 2006 11:41:28 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRBH-0007gy-AF for tcpm@ietf.org; Mon, 03 Apr 2006 11:41:28 -0400 Received: from lion.bbn.com ([128.89.80.73]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FQRBH-0005Br-3O; Mon, 03 Apr 2006 11:41:27 -0400 Message-ID: <44314226.90205@bbn.com> Date: Mon, 03 Apr 2006 11:41:26 -0400 From: "Armando L. Caro, Jr." User-Agent: Mail/News 1.5 (X11/20060210) MIME-Version: 1.0 To: Tim Shepard Subject: Re: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 OpenPGP: id=A9CE816E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Tim Shepard wrote: > 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 am not aware of any document describing how the transition is *supposed* to be accomplish. However, Ryan Bickhart wrote a document describing a TCP-to-SCTP translation shim that he developed for assisting the transition. The idea is... 1. run dual-stack 2. specify which TCP apps make sense to use SCTP 3. then shim translates TCP calls to SCTP transparently a. attempts to talk SCTP to peer b. if peer doesn't support SCTP, falls back to TCP This shim makes it possible to run TCP apps over SCTP without any changes whatsoever to the application. http://www.cis.udel.edu/~amer/PEL/poc/pdf/BickhartMSthesis.pdf -- Armando _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Tue Apr 04 18:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuAA-0004A5-3e; Tue, 04 Apr 2006 18:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQuA9-0004A0-Ff for tcpm@ietf.org; Tue, 04 Apr 2006 18:38:13 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQuA8-0004UQ-36 for tcpm@ietf.org; Tue, 04 Apr 2006 18:38:13 -0400 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 k34MakG01623; Tue, 4 Apr 2006 15:36:46 -0700 (PDT) Message-ID: <4432F48A.2010406@isi.edu> Date: Tue, 04 Apr 2006 15:34:50 -0700 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> <442DAFFF.7090900@isi.edu> 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: cd26b070c2577ac175cd3a6d878c6248 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 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. Or things might silently break, e.g., if his receive side requires strict multihoming. > 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. L3 changes could be a LOT harder to deploy; L4 are at least supposed to be limited to the endpoints. >> 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. Updating the OS with shim6 is as easy as updating it with SCTP; having SCTP be the default with fallback seems simple enough (and someone else noted it had been implemented). > 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. If the socket is what's modified, it's transparent to the app. ... >> 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). A man with one clock always knows what time it is; a man with two is never sure. Right now (with apologies to Maslow) we have a handful of clocks wandering around looking for the nail. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEMvSJE5f5cImnZrsRAhDoAKD5vI7Agt3Z0BbdnzAlObCMdTVFXQCgyM33 f4YiFRE/iyU3WnM6U/Y5hZQ= =1iAd -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 05 16:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREKp-0004wk-Hp; Wed, 05 Apr 2006 16:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FREKo-0004w4-Ik for tcpm@ietf.org; Wed, 05 Apr 2006 16:10:34 -0400 Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FREKn-0002SJ-6H for tcpm@ietf.org; Wed, 05 Apr 2006 16:10:34 -0400 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 k35KANMp057341; Wed, 5 Apr 2006 13:10:24 -0700 (PDT) (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 E8D8677AB4C; Wed, 5 Apr 2006 16:10:20 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1E58E3EF488; Wed, 5 Apr 2006 16:09:32 -0400 (EDT) To: Tim Shepard From: Mark Allman Subject: Re: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) In-Reply-To: Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Small Town MIME-Version: 1.0 Date: Wed, 05 Apr 2006 16:09:31 -0400 Message-Id: <20060405200932.1E58E3EF488@lawyers.icir.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tcpm@ietf.org, Joe Touch 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="===============0869154374==" Errors-To: tcpm-bounces@ietf.org --===============0869154374== Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" --=_bOundary Content-Type: text/plain Content-Disposition: inline Tim- > 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 guess I don't quite follow this. You make it sound as if there is some grand plan or some great need to move all apps from TCP to SCTP. Mutliple transport protocols are just fine. (Note: I am *not* saying that particular apps should not switch. Clearly, there are apps that may be better matched to SCTP. I am just noting that we're above the waist of the hourglass here.) > Should tcpm's charter be expanded to include similar tweaking of SCTP? I hope not. :-) > Or should we have an sctpm WG? Certainly that is a possibility (and, I believe has been discussed). When TCPM was setup we noted that we needed at least some coordination with SCTP and DCCP when things were changed in the TCP algorithms, as these other protocols could need changed, as well. Further, if there was a draft that considered both protocols (e.g., RFC3708) then where it would be discussed (TCPM vs. TSVWG) would be figured out when the time came --- with both groups being kept in th loop. (TSVWG being the place where SCTP work has been done these days.) allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFENCP7WyrrWs4yIs4RArg9AJ9KyGHi5cQKF8SAMBR3lzcwAJAPrQCfb/Dg LdJA9/Kb7OR2NsUsooBQ4Ek= =GwAx -----END PGP SIGNATURE----- --=_bOundary-- --===============0869154374== 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 --===============0869154374==-- From tcpm-bounces@ietf.org Wed Apr 05 17:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFAh-0003NN-7Z; Wed, 05 Apr 2006 17:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFAf-0003M9-Cm for tcpm@ietf.org; Wed, 05 Apr 2006 17:04:09 -0400 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 1FRFAe-0004xP-5A for tcpm@ietf.org; Wed, 05 Apr 2006 17:04:09 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FRFAP-00050f-00; Wed, 05 Apr 2006 17:03:53 -0400 From: Tim Shepard To: mallman@icir.org Subject: Re: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) In-reply-to: Your message of Wed, 05 Apr 2006 16:09:31 -0400. <20060405200932.1E58E3EF488@lawyers.icir.org> Date: Wed, 05 Apr 2006 17:03:53 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tcpm@ietf.org, Joe Touch 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 > > 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 guess I don't quite follow this. You make it sound as if there is > some grand plan or some great need to move all apps from TCP to SCTP. I don't mean to say that there is. I'm asking if there is. (AFAIK, there is not.) It's just that in a few times in the past year (including on the thread I branched off of with this thread) when some improvement has been proposed for the networking stack that today usually contains TCP, often someone will dismiss the proposal with some statement about how if such improved functionality is needed, then SCTP should be used instead of TCP. I am curious to know how we should best direct our efforts. Should it be to transition applications to use SCTP? If so, let's get going and declare TCP a legacy protocol. If not, then I guess we will continue to work on improving TCP to do things that SCTP might already be capable of, bringing the benefits to applications that run over TCP (today, and in the future). I guess this is an architectural question. Perhaps I should restart this thread on arch-d. -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 05 17:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFLC-0003BB-V4; Wed, 05 Apr 2006 17:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRFLB-00038E-Kg for tcpm@ietf.org; Wed, 05 Apr 2006 17:15:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRFL7-0005Tj-82 for tcpm@ietf.org; Wed, 05 Apr 2006 17:15:01 -0400 Received: from [128.9.176.234] (c2-vpn11.isi.edu [128.9.176.234]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k35LD2F17691; Wed, 5 Apr 2006 14:13:02 -0700 (PDT) Message-ID: <443432D8.4090403@isi.edu> Date: Wed, 05 Apr 2006 14:12:56 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tim Shepard Subject: Re: is SCTP the answer? (was 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tcpm@ietf.org, mallman@icir.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 Tim Shepard wrote: >>> 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 guess I don't quite follow this. You make it sound as if there is >> some grand plan or some great need to move all apps from TCP to SCTP. > > > I don't mean to say that there is. I'm asking if there is. (AFAIK, > there is not.) > > It's just that in a few times in the past year (including on the > thread I branched off of with this thread) when some improvement has > been proposed for the networking stack that today usually contains > TCP, often someone will dismiss the proposal with some statement > about how if such improved functionality is needed, then SCTP should > be used instead of TCP. > > I am curious to know how we should best direct our efforts. Should > it be to transition applications to use SCTP? > > If so, let's get going and declare TCP a legacy protocol. Or, more specifically, not change TCP for niche uses that are already supported by other protocols. Just because we're recommending that these uses apply SCTP doesn't mean that a shift to SCTP is appropriate everywhere. > If not, then I guess we will continue to work on improving TCP to do > things that SCTP might already be capable of, bringing the benefits > to applications that run over TCP (today, and in the future). That would be appropriate IF the extensions were of general utility AND needed to be added at the transport layer. That isn't the case for a number of SCTP extensions, IMO. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Wed Apr 05 21:26:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJGQ-0006JY-Tr; Wed, 05 Apr 2006 21:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRJGP-0006JT-Sv for tcpm@ietf.org; Wed, 05 Apr 2006 21:26:21 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRJGO-0008E8-JB for tcpm@ietf.org; Wed, 05 Apr 2006 21:26:21 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k361QILi029100 for ; Wed, 5 Apr 2006 21:26:18 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k361MvOS273646 for ; Wed, 5 Apr 2006 19:22:57 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k361QHRk006594 for ; Wed, 5 Apr 2006 19:26:17 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-243-241.mts.ibm.com [9.65.243.241]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k361QDXO006519; Wed, 5 Apr 2006 19:26:15 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k361Q2Mv006077; Wed, 5 Apr 2006 21:26:08 -0400 Message-Id: <200604060126.k361Q2Mv006077@cichlid.raleigh.ibm.com> To: Tim Shepard Subject: Re: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) In-Reply-To: Message from Tim Shepard of "Wed, 05 Apr 2006 17:03:53 EDT." Date: Wed, 05 Apr 2006 21:26:02 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Joe Touch , tcpm@ietf.org, mallman@icir.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 Tim Shepard writes: > > > 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 guess I don't quite follow this. You make it sound as if there is > > some grand plan or some great need to move all apps from TCP to SCTP. > I don't mean to say that there is. I'm asking if there is. (AFAIK, > there is not.) IMO, there is no good reason to have such a transition. Let's be honest here. SCTP has some interesting (and useful features), but they are largely of interest only to specialized applications (that is, they are irrelevant to 95% of the applications that run on top of TCP today). Why on earth would they want to run on top of SCTP, much less "migrate" to SCTP? In the case of SCTP's "multihoming facilities", for example, they are AFAIK, primitive, and we have little real experience with them. Indeed, I viewed them (when I reviewed the original specs) as largely hooks for potential future work, but that the details needed to be sorted out. I'll probably get flamed for saying that. So, let me ask those that disagree to provide pointers to documents and research showing experience with those multihoming capabilities and what we have learned from them. Thomas _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 06 02:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNce-0005u3-UO; Thu, 06 Apr 2006 02:05:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNcc-0005rW-UO for tcpm@ietf.org; Thu, 06 Apr 2006 02:05:34 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRNcb-0000zY-FT for tcpm@ietf.org; Thu, 06 Apr 2006 02:05:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3663sIO024395; Thu, 6 Apr 2006 09:03:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 09:05:16 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 09:05:15 +0300 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: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Date: Thu, 6 Apr 2006 09:05:14 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C924B@esebe100.NOE.Nokia.com> In-Reply-To: <200604060126.k361Q2Mv006077@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Thread-Index: AcZZGS/gGoNmZr/oTOqG5oCbeNMg0AAJJd5Q From: To: , X-OriginalArrivalTime: 06 Apr 2006 06:05:15.0129 (UTC) FILETIME=[1296CE90:01C65940] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: tcpm@ietf.org, mallman@icir.org, touch@isi.edu 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 Thomas, >I'll probably get flamed for saying that. So, let me ask those=20 >that disagree to provide pointers to documents and research=20 >showing experience with those multihoming capabilities and=20 >what we have learned from them.=20 I'm not sure if I can provide pointers, but 3G radio networks are using SCTP for control plane signaling - this is not the traditional SS7 over IP. I can point to the specs if you are intersted. There is the SS7 over SCTP work, this is starting to resemble IP trunking - except for the control plane; so not the traditional SS7 backhaul over IP. Also, as I understand it is being used heavily for SMS transport=20 because of scalability needs - in many regions, the amount of SMS's sent is larger than emails. Some AAA & billing systems are running over SCTP and I have been seeing more RFPs for SIP over SCTP - proxy-to-proxy usage. However, these are a specific usage case of SCTP (but I'd like to suggest that many of the TCP enhancements also apply to usage of SCTP in these environments - as Mark Allman pointed out). We've been playing with SCTP on small, multi-interface devices and it seems to actually work quite well for non-realtime application scenarios, with the benefit that it doesn't require infrastructure (but we've had to make sure that firewalls let SCTP pass). I think this would be roughly the same usage as TCP-MH that some people are talking about. In terms of research findings, there are some good articles here: http://www.eecis.udel.edu/~amer/PEL/poc/index.html For example: http://www.cis.udel.edu/~amer/PEL/poc/pdf/MILCOM03-ladha.pdf A good summary here: http://www.cis.udel.edu/~amer/PEL/poc/pdf/IEEE.Computer.SCTP.pdf And some downloads here: http://www.eecis.udel.edu/~amer/PEL/ (I can send more ... but as Tim suggested, maybe this should be taken to the ARCH-D list). In following HIP, SCTP, SHIM6 and MIP as general solutions to multihoming, in my estimate, SCTP & MIP are probably the best understood solutions at this point. I don't want to say that either are more or less complete, nor put a priority on one or the other; but just that there is more=20 deployment experience with MIP & SCTP. John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 06 02:16:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNnI-000708-NL; Thu, 06 Apr 2006 02:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNnH-000702-7r for tcpm@ietf.org; Thu, 06 Apr 2006 02:16:35 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRNnD-0001QA-PE for tcpm@ietf.org; Thu, 06 Apr 2006 02:16:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k366EWii007207; Thu, 6 Apr 2006 09:14:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 09:16:16 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 09:16:16 +0300 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: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Date: Thu, 6 Apr 2006 09:16:16 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB0C924F@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Thread-Index: AcZVG/fDqfEMJz8RRsimRq65/9A6/QEJGMEA From: To: , X-OriginalArrivalTime: 06 Apr 2006 06:16:16.0041 (UTC) FILETIME=[9C85F990:01C65941] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Tim, Re-ordering your mail slightly: =20 >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=20 >behaviour have an "SCTP considerations" section? I would support including support for SCTP in TCPM - in many cases it requires little-to-no extra work. >For the past year or two, I've heard "SCTP" proffered by many=20 >people as the answer to a variety of questions. > >I've given the SCTP specification a very quick scan last week=20 >while in Dallas, and I've learned bits and pieces about it=20 >over the years. >SCTP does indeed seem to be cool, and a better framework into=20 >which to put all sorts of desired functionality. For some light reading, you might want to look at: http://www.ietf.org/rfc/rfc3257.txt=09 >So if SCTP is the answer (to multihoming, multipath, general=20 >locator agility, etc.), and the applications I want to use=20 >between my multi-homed laptop and the various servers that I=20 >use are things like ssh, imap, and xmpp, what steps do I need=20 >to take to start experiencing all of the wonderfulness that is SCTP? I think Ned Freed has talked about why IMAP over SCTP would be=20 a good thing, we could probably get someone to get XMPP running over SCTP with little to no major effor ... etc. My feeling is that actually just getting things up and running over SCTP=20 rather than making TCP-MH would be easier, however deployment is always 'interesting' - my guess is that servers could easily support TCP & SCTP, but getting SCTP on popular=20 OS's can be more challenging. John _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 06 12:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWwV-00057D-CW; Thu, 06 Apr 2006 12:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWwT-000578-Qk for tcpm@ietf.org; Thu, 06 Apr 2006 12:02:41 -0400 Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWwT-0005u0-7U for tcpm@ietf.org; Thu, 06 Apr 2006 12:02:41 -0400 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 06 Apr 2006 09:02:29 -0700 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 501B62AE; Thu, 6 Apr 2006 09:02:29 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id C62142B2; Thu, 6 Apr 2006 09:02:28 -0700 (PDT) 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 DGA24393; Thu, 6 Apr 2006 09:02:27 -0700 (PDT) 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 C307020501; Thu, 6 Apr 2006 09:02:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Date: Thu, 6 Apr 2006 09:02:26 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13C9C34@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Thread-Index: AcZZGTBqsV7oLYQiTnCK1647PvT7zAAeYS4g From: "Caitlin Bestler" To: "Thomas Narten" , "Tim Shepard" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006040606; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230362E34343335334139312E303037392D412D; ENG=IBF; TS=20060406160232; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006040606_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682BE41F1743482442-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tcpm@ietf.org, mallman@icir.org, Joe Touch 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 Thomas Narten wrote: > Tim Shepard writes: >=20 >>>> 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?=20 >>>=20 >>> I guess I don't quite follow this. You make it sound as if there is >>> some grand plan or some great need to move all apps from TCP to >>> SCTP.=20 >=20 >> I don't mean to say that there is. I'm asking if there is. (AFAIK, >> there is not.) >=20 > IMO, there is no good reason to have such a transition. Let's > be honest here. SCTP has some interesting (and useful > features), but they are largely of interest only to > specialized applications (that is, they are irrelevant to 95% > of the applications that run on top of TCP today). Why on > earth would they want to run on top of SCTP, much less "migrate" to > SCTP?=20 >=20 > In the case of SCTP's "multihoming facilities", for example, > they are AFAIK, primitive, and we have little real experience > with them. Indeed, I viewed them (when I reviewed the > original specs) as largely hooks for potential future work, > but that the details needed to be sorted out. >=20 > I'll probably get flamed for saying that. So, let me ask > those that disagree to provide pointers to documents and > research showing experience with those multihoming > capabilities and what we have learned from them. >=20 SCTP provides multi-homing, multi-streaming and message boundaries. All of which are very relevant to many applications. RDMA and iSCSI are both applications that should have been developed over SCTP. It's defined for RDMA, but not deployed, and not defined for iSCSI. The reason is that customers are not confident that they can deploy SCTP at the endpoints and have proper support from all network elements, and network management. People promoting new technologies only want to sell one new concept at a time, therefore they stick to TCP. The point is that any new solution that doesn't address the problem of compatability with a network that doesn't instantly update itself to be RFC-compliant doesn't do any good. If all networks adapted themselves instantly to RFCs then we would already be using SCTP to solve these problems. So I don't see any point in considering TCP enhancements unless they pass the test of being transparent to existing network elements. If they aren't transparent they'll just add one more spec to the list of things networks don't do despite there being an RFC. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Mon Apr 10 22:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT93h-0004ji-GA; Mon, 10 Apr 2006 22:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT93g-0004ja-58 for tcpm@ietf.org; Mon, 10 Apr 2006 22:56:48 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT93e-0002vI-UM for tcpm@ietf.org; Mon, 10 Apr 2006 22:56:48 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id B5633119; Mon, 10 Apr 2006 22:56:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on louie.udel.edu X-Spam-Level: X-Spam-Status: No, score=-2.2 required=4.1 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 20ED724; Mon, 10 Apr 2006 22:56:46 -0400 (EDT) Date: Mon, 10 Apr 2006 22:56:45 -0400 (EDT) From: Janardhan Iyengar X-X-Sender: iyengar@stimpy.eecis.udel.edu To: Scott Leibrand Subject: RE: [tcpm] "TCP Multipath" with shim6 In-Reply-To: Message-ID: References: <54AD0F12E08D1541B826BE97C98F99F13C96B0@NT-SJCA-0751.brcm.ad.broadcom.com> X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm, v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Scott, Sorry about the delayed response. You are already aware of our work, so let me just point you to specific papers: http://www.cis.udel.edu/~iyengar/publications/iyengar.ToN.pdf http://www.cis.udel.edu/~iyengar/publications/rbufJournal.pdf For more info: http://www.cis.udel.edu/~iyengar/dissertation/ > 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 Absolutely yes. regards, - jana -------------------- Janardhan R. Iyengar http://www.cis.udel.edu/~iyengar Protocol Engineering Lab, University of Delaware _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 13 11:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3rQ-0002Gz-3R; Thu, 13 Apr 2006 11:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3rO-0002Gu-L7 for tcpm@ietf.org; Thu, 13 Apr 2006 11:35:54 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3rO-0000Xd-EH for tcpm@ietf.org; Thu, 13 Apr 2006 11:35:54 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Apr 2006 08:35:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,118,1144047600"; d="scan'208"; a="539693030:sNHT20599056" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 11:35:53 -0400 Message-ID: <443E6FD6.3020507@juniper.net> Date: Thu, 13 Apr 2006 11:35:50 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 15:35:53.0264 (UTC) FILETIME=[F2FFDB00:01C65F0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [tcpm] draft-ietf-tcpm-tcp-soft-errors 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 Folks, At IETF 65, I agreed to review draft-ietf-tcpm-tcp-soft-errors. Aside from a few editorial comments, which I have sent to the author and WG chairs, the draft appeared to be in publishable condition. -r _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 13 15:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7p5-0005yL-4N; Thu, 13 Apr 2006 15:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU7p3-0005vw-5z for tcpm@ietf.org; Thu, 13 Apr 2006 15:49:45 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU7p1-0000O8-RD for tcpm@ietf.org; Thu, 13 Apr 2006 15:49:45 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 59877C2BA for ; Thu, 13 Apr 2006 15:49:43 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id k3DJnhQ7012275 for ; Thu, 13 Apr 2006 15:49:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k3DJng3Y025501 for ; Thu, 13 Apr 2006 15:49:42 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1]) by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19804-28 for ; Thu, 13 Apr 2006 15:49:41 -0400 (EDT) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k3DJnem2025482 for ; Thu, 13 Apr 2006 15:49:40 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 8EB244FC21; Thu, 13 Apr 2006 15:48:11 -0400 (EDT) Date: Thu, 13 Apr 2006 15:48:11 -0400 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <20060413194810.GB2145@grc.nasa.gov> Mime-Version: 1.0 User-Agent: Mutt/1.5.5.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [tcpm] syn flooding draft 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="===============0548909260==" Errors-To: tcpm-bounces@ietf.org --===============0548909260== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FYI: An updated version of the draft on TCP SYN flooding and defenses (including SYN cookies) is available: http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt I am soliciting comments/questions/suggestions. --=20 Wesley M. Eddy Verizon Federal Network Systems --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFEPqr6zBuYqbnj3IwRAqc6AJoCpTyDwqByUF32UPsVDzQoINds5QCeMalH oI98Gv9jGz8UoOyW2SNwmWg= =QgKY -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- --===============0548909260== 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 --===============0548909260==-- From tcpm-bounces@ietf.org Thu Apr 13 16:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8g8-0002fD-Sb; Thu, 13 Apr 2006 16:44:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8g7-0002f3-0G for tcpm@ietf.org; Thu, 13 Apr 2006 16:44:35 -0400 Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8g5-0003BI-Is for tcpm@ietf.org; Thu, 13 Apr 2006 16:44:34 -0400 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 13 Apr 2006 13:44:26 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 382C82AF; Thu, 13 Apr 2006 13:44:26 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 13A922AE for ; Thu, 13 Apr 2006 13:44:26 -0700 (PDT) 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.5-GA) with ESMTP id DHM25449; Thu, 13 Apr 2006 13:44:19 -0700 (PDT) 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 86C8920501 for ; Thu, 13 Apr 2006 13:44:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] syn flooding draft Date: Thu, 13 Apr 2006 13:44:18 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13CA315@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: RE: [tcpm] syn flooding draft Thread-Index: AcZfOwk1U1PtrmOrTZWAl+362LELew== From: "Caitlin Bestler" To: tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041307; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343345423645462E303034412D452D5046786C33494E497A33445631553653544639524F673D3D; ENG=IBF; TS=20060413204426; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041307_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682067A03NG7531140-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Wesley Eddy wrote: > FYI: An updated version of the draft on TCP SYN flooding and defenses=20 > (including SYN cookies) is available: > http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt >=20 > I am soliciting comments/questions/suggestions. A well written summary. My only suggestion is that it might be worth adding language emphasizing that both Syn Caching and Syn Cookies *are* RFC compliant and merely represent host choices on how to select the ISN and/or encode the TCB (Syn Cookies essentially "storing" the TCB for the SYN- Received state through its choice of ISN). _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Thu Apr 13 19:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBeH-0006hm-Bu; Thu, 13 Apr 2006 19:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUBeF-0006hh-KD for tcpm@ietf.org; Thu, 13 Apr 2006 19:54:51 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUBeE-0001An-6N for tcpm@ietf.org; Thu, 13 Apr 2006 19:54:51 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 16:54:49 -0700 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 16:54:49 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 16:54:49 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Apr 2006 16:54:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] syn flooding draft Date: Thu, 13 Apr 2006 16:54:45 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06451E136@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F13CA315@NT-SJCA-0751.brcm.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] syn flooding draft Thread-Index: AcZfOwk1U1PtrmOrTZWAl+362LELewAGSPdg From: "Christian Huitema" To: "Caitlin Bestler" , X-OriginalArrivalTime: 13 Apr 2006 23:54:46.0900 (UTC) FILETIME=[A4D63B40:01C65F55] 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 > A well written summary. My only suggestion is that it might be worth > adding > language emphasizing that both Syn Caching and Syn Cookies *are* RFC > compliant > and merely represent host choices on how to select the ISN and/or encode > the > TCB (Syn Cookies essentially "storing" the TCB for the SYN- Received > state > through its choice of ISN). The SYN-Cookies approach actually modifies TCP in a significant way, by removing protection against the loss of the first ACK message. Consider the following: Initiator Responder SYN ----> <------ SYN+ACK ACK ---*(loss) At this point in the state machine, the initiator will not repeat the SYN, since it has already received the ACK. In standard TCP, this is taken care of by the responder, which is supposed to repeat the SYN+ACK until the SYN is acknowledged. This is not a problem for applications like HTTP in which the first message in the session is sent by the initiator. The HTTP sequence looks like: Initiator Responder SYN ----> <------ SYN+ACK ACK ---*(loss) DATA+ACK ---> Even if the DATA + ACK is lost, it would be repeated. However, consider a protocol like FTP, where the first DATA message is sent by the client. If you use SYN cookies, the stack is not repeating the SYN-ACK. The loss of the ACK results in the loss of the connection. Now, consider a SYN flooding scenario. The responder is under attack, the line is probably flooded, the packet loss rate is likely quite high. Many good connections are going to be lost! -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 12:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQtj-0002yY-Qt; Fri, 14 Apr 2006 12:11:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQtj-0002yT-2p for tcpm@ietf.org; Fri, 14 Apr 2006 12:11:51 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQti-0007Go-Ki for tcpm@ietf.org; Fri, 14 Apr 2006 12:11:50 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 14 Apr 2006 09:11:38 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 341042B0; Fri, 14 Apr 2006 09:11:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0F8EF2AE; Fri, 14 Apr 2006 09:11:38 -0700 (PDT) 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.5-GA) with ESMTP id DHP91411; Fri, 14 Apr 2006 09:11:36 -0700 (PDT) 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 4B44220501; Fri, 14 Apr 2006 09:11:36 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] syn flooding draft Date: Fri, 14 Apr 2006 09:11:35 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13CA3B3@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] syn flooding draft Thread-Index: AcZfOwk1U1PtrmOrTZWAl+362LELewAGSPdgACI8wqA= From: "Caitlin Bestler" To: "Christian Huitema" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041404; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34343346433837412E303030392D412D; ENG=IBF; TS=20060414161141; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041404_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 682116300HW7115931-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Christian Huitema wrote: >> A well written summary. My only suggestion is that it might be worth >> adding language emphasizing that both Syn Caching and Syn Cookies >> *are* RFC compliant and merely represent host choices on how to >> select the ISN and/or > encode >> the >> TCB (Syn Cookies essentially "storing" the TCB for the SYN- Received >> state through its choice of ISN). >=20 > The SYN-Cookies approach actually modifies TCP in a > significant way, by removing protection against the loss of > the first ACK message. Consider the following: >=20 >=20 > Initiator Responder > SYN ----> > <------ SYN+ACK > ACK ---*(loss) >=20 > At this point in the state machine, the initiator will not > repeat the SYN, since it has already received the ACK. In > standard TCP, this is taken care of by the responder, which > is supposed to repeat the SYN+ACK until the SYN is acknowledged. >=20 > This is not a problem for applications like HTTP in which the > first message in the session is sent by the initiator. The > HTTP sequence looks > like: >=20 >=20 > Initiator Responder > SYN ----> > <------ SYN+ACK > ACK ---*(loss) > DATA+ACK ---> >=20 > Even if the DATA + ACK is lost, it would be repeated. > However, consider a protocol like FTP, where the first DATA > message is sent by the client. > If you use SYN cookies, the stack is not repeating the > SYN-ACK. The loss of the ACK results in the loss of the connection. >=20 > Now, consider a SYN flooding scenario. The responder is under > attack, the line is probably flooded, the packet loss rate is likely > quite high. Many good connections are going to be lost! >=20 > -- Christian Huitema Only if you have a server that accepts a large number of connections where the initiator sends no data. I doubt there are many such servers. Syn Cookies are indeed designed for unbound listens that accept connections from virtually anybody. The core of their design is protection from forged source IP addresses. You do raise an excellent point, however, that this defense is not appropriate for specialized connections (such as secondary connections with FTP). One of the benefits of having an RFC, even an informational one, is encourage some standardization of the feature as well as its use. One such suggestion would be that syn cookies should be enabled on a per listen basis. In my opinion that enabling should be for any port that has a signifigant backlog. Can you cite an example where the passive side would send the first data and be accepting a large number of connections from unknown remote peers? _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 12:15:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQxa-0003Gp-GG; Fri, 14 Apr 2006 12:15:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQxZ-0003Gk-3N for tcpm@ietf.org; Fri, 14 Apr 2006 12:15:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQxX-0007Q7-Qs for tcpm@ietf.org; Fri, 14 Apr 2006 12:15:49 -0400 Received: from [12.208.106.139] (helo=elb.elitists.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUQxW-000OCj-Pb for tcpm@ietf.org; Fri, 14 Apr 2006 16:15:47 +0000 Received: from elitists.net (colt [192.168.33.1]) by elb.elitists.net (Postfix) with ESMTP id 8AA4C2BE1F for ; Fri, 14 Apr 2006 11:15:45 -0500 (EST) Received: by elitists.net (Postfix, from userid 3000) id BBBC2F452; Fri, 14 Apr 2006 11:15:44 -0500 (EST) Date: Fri, 14 Apr 2006 12:15:44 -0400 From: Ethan Blanton To: tcpm@ietf.org Subject: Re: [tcpm] syn flooding draft Message-ID: <20060414161544.GA5323@localhost.localdomain> Mail-Followup-To: tcpm@ietf.org References: <54AD0F12E08D1541B826BE97C98F99F13CA3B3@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F13CA3B3@NT-SJCA-0751.brcm.ad.broadcom.com> X-GnuPG-Fingerprint: A290 14A8 C682 5C88 AE51 4787 AFD9 00F4 883C 1C14 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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="===============1820706707==" Errors-To: tcpm-bounces@ietf.org --===============1820706707== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Caitlin Bestler spake unto us the following wisdom: > Can you cite an example where the passive side would send > the first data and be accepting a large number of connections > from unknown remote peers? ssh Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEP8qwr9kA9Ig8HBQRAlNJAKCvqKFlxBD/0GKEBuvwEa2pFX6+lQCdFX6t VbD4uJKPTtlCAsI5MfmkIH8= =ozTh -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- --===============1820706707== 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 --===============1820706707==-- From tcpm-bounces@ietf.org Fri Apr 14 13:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTJ-0001TR-Fp; Fri, 14 Apr 2006 13:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSTI-0001Q6-Nd for tcpm@ietf.org; Fri, 14 Apr 2006 13:52:40 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSTH-0001X7-Cg for tcpm@ietf.org; Fri, 14 Apr 2006 13:52:40 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:52:38 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:51:37 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:51:37 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 10:51:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [tcpm] syn flooding draft Date: Fri, 14 Apr 2006 10:51:35 -0700 Message-ID: <70C6EFCDFC8AAD418EF7063CD132D06451E35B@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <20060414161544.GA5323@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] syn flooding draft Thread-Index: AcZf3tBbpaJy5u8NTTSN5XkvltEMBwADHwvQ From: "Christian Huitema" To: "Ethan Blanton" , X-OriginalArrivalTime: 14 Apr 2006 17:51:37.0099 (UTC) FILETIME=[138435B0:01C65FEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > > Can you cite an example where the passive side would send > > the first data and be accepting a large number of connections > > from unknown remote peers? >=20 > ssh SMTP, if implemented according to RFC2821, which states (section 4.3.1 Sequencing Overview, page 47): One important reply is the connection greeting. Normally, a receiver will send a 220 "Service ready" reply when the connection is completed. The sender SHOULD wait for this greeting message before sending any commands. Obviously, implementations of SMTP could decide to override the SHOULD and send a HELO/EHLO message anyhow, but that is a change in spec... -- Christian Huitema _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 14:03:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSdN-00035s-Vk; Fri, 14 Apr 2006 14:03:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSdM-00035n-Mn for tcpm@ietf.org; Fri, 14 Apr 2006 14:03:04 -0400 Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSdL-00020m-AU for tcpm@ietf.org; Fri, 14 Apr 2006 14:03:04 -0400 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 14 Apr 2006 11:02:54 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 4B94D2AF; Fri, 14 Apr 2006 11:02:54 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 271202AE; Fri, 14 Apr 2006 11:02:54 -0700 (PDT) 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.5-GA) with ESMTP id DHQ29395; Fri, 14 Apr 2006 11:02:53 -0700 (PDT) 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 5F08C20501; Fri, 14 Apr 2006 11:02:53 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [tcpm] syn flooding draft Date: Fri, 14 Apr 2006 11:02:52 -0700 Message-ID: <54AD0F12E08D1541B826BE97C98F99F13CA3D5@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [tcpm] syn flooding draft Thread-Index: AcZf3tBbpaJy5u8NTTSN5XkvltEMBwADHwvQAACN/EA= From: "Caitlin Bestler" To: "Christian Huitema" , "Ethan Blanton" , tcpm@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041406; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230352E34343346453239302E303030362D412D; ENG=IBF; TS=20060414180258; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006041406_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68213C440HW7135636-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Christian Huitema wrote: >>> Can you cite an example where the passive side would send the first >>> data and be accepting a large number of connections from unknown >>> remote peers? >>=20 >> ssh >=20 > SMTP, if implemented according to RFC2821, which states > (section 4.3.1 Sequencing Overview, page 47): >=20 > One important reply is the connection greeting. Normally, > a receiver > will send a 220 "Service ready" reply when the connection is > completed. The sender SHOULD wait for this greeting message > before sending any commands.=20 >=20 > Obviously, implementations of SMTP could decide to override > the SHOULD and send a HELO/EHLO message anyhow, but that is a > change in spec... >=20 Good points. The draft should probably recommend use of Syn Caching over Syn cookies for this type of daemon. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 18:49:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUX6F-0006k4-89; Fri, 14 Apr 2006 18:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUX6D-0006jz-6h for tcpm@ietf.org; Fri, 14 Apr 2006 18:49:09 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUX6A-0003WS-R8 for tcpm@ietf.org; Fri, 14 Apr 2006 18:49:09 -0400 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 k3EMm1M07471; Fri, 14 Apr 2006 15:48:01 -0700 (PDT) Message-ID: <44402640.7030705@isi.edu> Date: Fri, 14 Apr 2006 15:46:24 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tcpm 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: c1c65599517f9ac32519d043c37c5336 Subject: [tcpm] TCP port names option ID 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, In response to some discussion on the IETF mailing list, the following ID has been submitted. It's intended to become a TCPM work item (thus the header) if there's sufficient interest. For the original discussion, see the ietf@ietf.org archives, and look for "Guidance needed on well known ports". The draft available at the following URL until it's in the ID repositories: http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt Joe - ---- TCPM WG J. Touch Internet Draft USC/ISI Expires: October 2006 April 14, 2006 A TCP Option for Port Names draft-touch-tcp-portnames-00.txt ... Abstract This document specifies a new TCP option that specifies services by a string name. This option separates the use of port numbers for connection demultiplexing from their use as a service identifier. The option allows a larger number of concurrent connections for a particular service, as well as potentially enabling more explicitly coordination of services behind NATs and firewalls. This option should be supported in new TCP implementations. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQCZAE5f5cImnZrsRAnNFAJ4lf3v4kmbGBrwvX5Zz6rnn02fI4ACfXo8b fBiAwJRKmvhEJvXLDE/X3Ow= =aUmR -----END PGP SIGNATURE----- _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 21:13:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUZLk-00067q-1T; Fri, 14 Apr 2006 21:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUZLi-00067g-HF for tcpm@ietf.org; Fri, 14 Apr 2006 21:13:18 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUZLi-0000C5-8o for tcpm@ietf.org; Fri, 14 Apr 2006 21:13:18 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FUZLj-0001N6-Ix; Fri, 14 Apr 2006 19:12:57 -0600 Message-ID: <444048B7.5060306@middle.net> Date: Fri, 14 Apr 2006 19:13:27 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tcpm@ietf.org Subject: [tcpm] TCP port / service names 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 After a quick review of the TCP portnames draft, I have a couple of comments / questions: 1. I think the idea of accepting requests for a service on an arbitrary port number is an outstanding idea. 2. The nomenclature could use some clarification. In particular the term "port name" in this context is confusing, when a port name can be distributed across an arbitrary number of numbered ports. Is there any particular reason why "service name" shouldn't be used instead? 2. Is the intent that a port name be a service instance specifier in addition to a service type specifier? If just a service type specifier, why not just adopt the 32-bit service codes being standardized for DCCP? If both, why not use a DCCP style service type code, plus an additional service instance code? 3. Using a name string instead of binary numeric identifiers seems unnecessarily expensive. I would like to see a scheme exactly the same, except have the SYN option carry a DCCP compatible service type identifier, plus an additional 32 bit service instance identifier, where instance N means the Nth instance of the specified service type. - Mark B. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Fri Apr 14 22:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUaHu-0008Cy-TL; Fri, 14 Apr 2006 22:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUaHu-0008Bd-Fy for tcpm@ietf.org; Fri, 14 Apr 2006 22:13:26 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUaHs-0002hM-34 for tcpm@ietf.org; Fri, 14 Apr 2006 22:13:26 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FUaHk-0001WZ-P6 for tcpm@ietf.org; Fri, 14 Apr 2006 20:12:54 -0600 Message-ID: <444056C5.4020005@middle.net> Date: Fri, 14 Apr 2006 20:13:25 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: RE: [tcpm] is SCTP the answer? (was Re: [tcpm] "TCP Multipath" with shim6 ) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 don't think there should be a wholesale TCP->SCTP migration effort, but there isn't any reason why SCTP can't provide TCP style byte stream delivery service with additional benefits. (Or DCCP style connection oriented unreliable message delivery service for that matter). The primary obstacle to doing this is that socket APIs are being defined on a transport protocol specific basis. That is an unusually counterproductive practice. Wouldn't it be much better to define a single socket API with proper service types that can be used on any supporting transport protocol? That was the original intent was it not? For example POSIX defines SOCK_STREAM as a byte oriented delivery service, but for various reasons SCTP adopted SOCK_STREAM to request a one-to-one message oriented delivery service, instead of something like SOCK_RDM. And then we have SOCK_DCCP, a definition that pretty much disregards the whole idea of distinguishing the socket service type from the underlying transport protocol. Historical issues aside, SCTP is easily tweakable to support all the common socket service types, including: connection oriented byte stream, connection oriented reliable/partially reliable/unreliable message delivery, connectionless reliable/partially reliable/unreliable message delivery, with two subvariants for each of the message oriented service types - atomic (SOCK_DGRAM style) read/write semantics, and partial message (SOCK_SEQPACKET style) read/write semantics. The problem is that standardization in this area is non-existent, which means if you want to port a program from one transport protocol to another, much more care must be taken than simply changing IPPROTO_x to IPPROTO_y. Besides the base socket service type issues, there are several socket options that should be shared between transport protocols that are not. SCTP_NODELAY and TCP_NODELAY have essentially identical semantics for example. DCCP has a new option for service code that might be useful for future extensions to TCP and SCTP, but it is defined as a DCCP specific socket option. SCTP has a pretty generic multihoming interface, but it is defined as a set of sctp_xxx library calls. It there were a transport protocol independent socket API standard, the uptake and testing of new transport protocols would be much improved. Instead of adding an unmaintainable flurry of #ifdefs, common applications could switch transport protocols as easily as they now switch port numbers. Any comments on this idea? - Mark B. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 15 01:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUcv3-00009G-7v; Sat, 15 Apr 2006 01:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUcv1-00009B-RH for tcpm@ietf.org; Sat, 15 Apr 2006 01:01:59 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUcv1-0007cM-FS for tcpm@ietf.org; Sat, 15 Apr 2006 01:01:59 -0400 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 k3F51BR17380; Fri, 14 Apr 2006 22:01:11 -0700 (PDT) Message-ID: <44407E0F.404@isi.edu> Date: Fri, 14 Apr 2006 22:01:03 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mark Butler References: <444048B7.5060306@middle.net> In-Reply-To: <444048B7.5060306@middle.net> 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: d0bdc596f8dd1c226c458f0b4df27a88 Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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, Mark, Mark Butler wrote: > > After a quick review of the TCP portnames draft, I have a couple of > comments / questions: > > 1. I think the idea of accepting requests for a service on an arbitrary > port number is an outstanding idea. > > 2. The nomenclature could use some clarification. In particular the > term "port name" in this context is confusing, when a port name can be > distributed across an arbitrary number of numbered ports. Is there any > particular reason why "service name" shouldn't be used instead? The difference is that service names appear in many contexts - DNS SRV records, IANA's keywords, etc. I.e., it's already backwards (service names already mean port numbers). That said, if there's a groundswell, we could rename this a "service option" etc... throughout. > 2. Is the intent that a port name be a service instance specifier in > addition to a service type specifier? The instance is completely specified by the connection, i.e., by the socket pair already; having a further specifier would require the option in subsequent segments and would unnecessarily complicate all segment processing, rather than just SYNs and SYN-ACKs. (at least if I understand what you're suggesting) > If just a service type specifier, > why not just adopt the 32-bit service codes being standardized for > DCCP? It's redundant to reserve a service name and a service code; we already do that for port numbers in IANA, and avoiding that sort of thing is part of what this option was motivated by (see the discussion in the IETF mailing archives). The strings are sufficient, and not necessarily less efficient. > If both, why not use a DCCP style service type code, plus an > additional service instance code? I don't see the reason for an instance code here. The goal is to separate the existing socket pair instance specifier from the service specifier only. > 3. Using a name string instead of binary numeric identifiers seems > unnecessarily expensive. Considering that more than a few common services are a three characters long, there's no difference. They're easier to debug. And again then we have to reserve two things when one will do. And if we have a set of numbers, we're back to probably deploying a lookup function again. Part of this was motivated by decoupling the service name from a set of numbers. > I would like to see a scheme exactly the same, except have the SYN > option carry a DCCP compatible service type identifier, plus an > additional 32 bit service instance identifier, where instance N means > the Nth instance of the specified service type. > > - Mark B. We don't necessarily want to propagate DCCP's notion of service code groups or instances. Joe _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 15 04:02:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUfjQ-0004WX-Ft; Sat, 15 Apr 2006 04:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUfjO-0004WS-ER for tcpm@ietf.org; Sat, 15 Apr 2006 04:02:10 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUfjK-0004kc-Cz for tcpm@ietf.org; Sat, 15 Apr 2006 04:02:08 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FUfjM-0002AI-4C; Sat, 15 Apr 2006 02:01:46 -0600 Message-ID: <4440A889.60307@middle.net> Date: Sat, 15 Apr 2006 02:02:17 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu> In-Reply-To: <44407E0F.404@isi.edu> X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.8 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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="===============0287006310==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0287006310== Content-Type: multipart/alternative; boundary="------------050306070007070908020909" This is a multi-part message in MIME format. --------------050306070007070908020909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Joe, Joe Touch wrote: >Mark Butler wrote: > > >>After a quick review of the TCP portnames draft, I have a couple of >>comments / questions: >> >>1. I think the idea of accepting requests for a service on an arbitrary >>port number is an outstanding idea. >> >>2. The nomenclature could use some clarification. In particular the >>term "port name" in this context is confusing, when a port name can be >>distributed across an arbitrary number of numbered ports. Is there any >>particular reason why "service name" shouldn't be used instead? >> >> > >The difference is that service names appear in many contexts - DNS SRV >records, IANA's keywords, etc. I.e., it's already backwards (service >names already mean port numbers). > > Service names currently _translate_ to port numbers. That is a big difference to being equivalent to port numbers. If the latter were the case we would call them "port names", a term which furthers precisely the association we should be trying to avoid. >>2. Is the intent that a port name be a service instance specifier in >>addition to a service type specifier? >> >> > >The instance is completely specified by the connection, i.e., by the >socket pair already; having a further specifier would require the option > in subsequent segments and would unnecessarily complicate all segment >processing, rather than just SYNs and SYN-ACKs. (at least if I >understand what you're suggesting) > > Say you have multiple web servers on the same machine. Currently one specifies which one to connect to by changing the port number. Now with an extension like this a web server can listen on all ports simultaneously and the TCP stack will associate incoming connections with a web server process by matching on the "port name". So if you want to run two different web servers on the same IP address, each one will have to use a different port name, i.e. the port name will have to carry both service type and instance information. >>If both, why not use a DCCP style service type code, plus an >>additional service instance code? >> >> > >I don't see the reason for an instance code here. The goal is to >separate the existing socket pair instance specifier from the service >specifier only. > > There is some confusion about the sense of service instance here. I mean a logically independent provider of network services, and you appear to mean a connection over which services are provided. >>3. Using a name string instead of binary numeric identifiers seems >>unnecessarily expensive. >> >> > >Considering that more than a few common services are a three characters >long, there's no difference. > If you want to store them in structures, there is a considerable difference, because arbitrary length strings generally have to be dynamically allocated. If in a hashed lookup process, every entry in the same hash chain has to be strcmp()'d to check for a match, when a simple integer comparison or two would otherwise do nicely >They're easier to debug. And again then we >have to reserve two things when one will do. > >And if we have a set of numbers, we're back to probably deploying a >lookup function again. Part of this was motivated by decoupling the >service name from a set of numbers. > > The service instance number is logically equivalent to the use of the port number in a URI like: http://plasma.example.com:8000/ except they would be much smaller, similar to the digit in "www1", "www2", "www3" and so on. Databases like Oracle and DB2 support multiple server instances on the same machine and use instance identifiers as selectors, both over the network and with environment variables like ORACLE_SID and DB2_SID. Service instance identifiers would not need to be looked up. Non-default values would be rare, and used only in cases where more than one service process of the same type run on the same IP address. They could be used more pervasively, e.g. to do NAT dispatching, or to reduce the number of IP addresses required in virtually hosted environments, but that would require something comparable to SRV records. That is not such a bad option - a DNS lookup generally occurs already, and one can get the extra information in the same request/response turnaround, right? All that can be done with ports now, but would not be able to be done with the proposed extension unless "port names" can include both service type and service (logical provider) instance information. So if the option is a string the question is what standard format should it have, or should it be anything goes with a few well known defaults? >>I would like to see a scheme exactly the same, except have the SYN >>option carry a DCCP compatible service type identifier, plus an >>additional 32 bit service instance identifier, where instance N means >>the Nth instance of the specified service type. >> >> >> > >We don't necessarily want to propagate DCCP's notion of service code >groups or instances. > > I think with service [type] codes the DCCP folks had firewalls more in mind, e.g. to support policies where a party is trying to keep a particular protocol from being run on any port. I am told that PPIDs were added to SCTP in an attempt to achieve a similar objective. Any standard service naming scheme is likely to contain similar information. DCCP service instances are an artifact of the way DCCP uses ports, not anything designed in, as far as I can tell. I am just saying that a widely used capability should not be thrown away. IP addresses are hard to come by, and a more extensive use of instance identifiers is one way to conserve the IPv4 address space. i.e. a company could adopt a scheme where interior nodes are assigned instance identifiers. Then the proper instance identifiers for something to establish a connection to something like an SIP telephone number could be listed in an externally visible DNS zone, and a remote caller could look up the public IP address of the NAT box, and the instance number associated with the interior node, and establish an inbound connection throught the NAT without ridiculous workarounds. No media gateways required either - the instance identifier could identify a specific phone, just like a telephone extension number, except transparent to the caller. - Mark B. --------------050306070007070908020909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Joe,

Joe Touch wrote:
Mark Butler wrote:
  
After a quick review of the TCP portnames draft, I have a couple of
comments / questions:

1. I think the idea of accepting requests for a service on an arbitrary
port number is an outstanding idea.

2. The nomenclature could use some clarification.  In particular the
term "port name" in this context is confusing, when a port name can be
distributed across an arbitrary number of numbered ports. Is there any
particular reason why "service name" shouldn't be used instead?
    

The difference is that service names appear in many contexts - DNS SRV
records, IANA's keywords, etc. I.e., it's already backwards (service
names already mean port numbers).
Service names currently _translate_ to port numbers.  That is a big difference to being equivalent to port numbers. If the latter were the case we would call them "port names", a term which furthers precisely the association we should be trying to avoid.

2. Is the intent that a port name be a service instance specifier in
addition to a service type specifier?
    

The instance is completely specified by the connection, i.e., by the
socket pair already; having a further specifier would require the option
 in subsequent segments and would unnecessarily complicate all segment
processing, rather than just SYNs and SYN-ACKs. (at least if I
understand what you're suggesting)
Say you have multiple web servers on the same machine.  Currently one specifies which one to connect to by changing the port number.  Now with an extension like this a web server can listen on all ports simultaneously and the TCP stack will associate incoming connections with a web server process by matching on the "port name". So if you want to run two different web servers on the same IP address, each one will have to use a different port name, i.e. the port name will have to carry both service type and instance information.


If both, why not use a DCCP style service type code, plus an
additional service instance code?
    

I don't see the reason for an instance code here. The goal is to
separate the existing socket pair instance specifier from the service
specifier only.
There is some confusion about the sense of service instance here.  I mean a logically independent provider of network services, and you appear to mean a connection over which services are provided.


3. Using a name string instead of binary numeric identifiers seems
unnecessarily expensive.
    

Considering that more than a few common services are a three characters
long, there's no difference.
If you want to store them in structures, there is a considerable difference, because arbitrary length strings generally have to be dynamically allocated.  If in a hashed lookup process, every entry in the same hash chain has to be strcmp()'d to check for a match, when a simple integer comparison or two would otherwise do nicely

They're easier to debug. And again then we
have to reserve two things when one will do.

And if we have a set of numbers, we're back to probably deploying a
lookup function again. Part of this was motivated by decoupling the
service name from a set of numbers.
The service instance number is logically equivalent to the use of the port number in a URI like:

http://plasma.example.com:8000/

except they would be much smaller, similar to the digit in "www1", "www2", "www3" and so on. Databases like Oracle and DB2 support multiple server instances on the same machine and use instance identifiers as selectors, both over the network and with environment variables like ORACLE_SID and DB2_SID.

Service instance identifiers would not need to be looked up.  Non-default values would be rare, and used only in cases where more than one service process of the same type run on the same IP address.

They could be used more pervasively, e.g. to do NAT dispatching, or to reduce the number of IP addresses required in virtually hosted environments, but that would require something comparable to SRV records.  That is not such a bad option - a DNS lookup generally occurs already, and one can get the extra information in the same request/response turnaround, right?  All that can be done with ports now, but would not be able to be done with the proposed extension unless "port names" can include both service type and service (logical provider) instance information.

So if the option is a string the question is what standard format should it have, or should it be anything goes with a few well known defaults?

I would like to see a scheme exactly the same, except have the SYN
option carry a DCCP compatible service type identifier, plus an
additional 32 bit service instance identifier, where instance N means
the Nth instance of the specified service type.

    

We don't necessarily want to propagate DCCP's notion of service code
groups or instances.
I think with service [type] codes the DCCP folks had firewalls more in mind, e.g. to support policies where a party is trying to keep a particular protocol from being run on any port.  I am told that PPIDs were added to SCTP in an attempt to achieve a similar objective.  Any standard service naming scheme is likely to contain similar information.

DCCP service instances are an artifact of the way DCCP uses ports, not anything designed in, as far as I can tell.  I am just saying that a widely used capability should not be thrown away.  IP addresses are hard to come by, and a  more extensive use of instance identifiers is one way to conserve the IPv4 address space. i.e. a company could adopt a scheme where interior nodes are assigned instance identifiers. 

Then the proper instance identifiers for something to establish a connection to something like an SIP telephone number could be listed in an externally visible DNS zone, and a remote caller could look up the public IP address of the NAT box, and the instance number associated with the interior node, and establish an inbound connection throught the NAT without ridiculous workarounds. No media gateways required either - the instance identifier could identify a specific phone, just like a telephone extension number, except transparent to the caller.

 - Mark B.


--------------050306070007070908020909-- --===============0287006310== 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 --===============0287006310==-- From tcpm-bounces@ietf.org Sat Apr 15 11:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUmkY-0000Bo-0F; Sat, 15 Apr 2006 11:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUmkX-0000Bj-CE for tcpm@ietf.org; Sat, 15 Apr 2006 11:31:49 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUmkV-0003IP-Rb for tcpm@ietf.org; Sat, 15 Apr 2006 11:31:49 -0400 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 k3FFVCR17467; Sat, 15 Apr 2006 08:31:12 -0700 (PDT) Message-ID: <444111B7.7050001@isi.edu> Date: Sat, 15 Apr 2006 08:31:03 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mark Butler References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu> <4440A889.60307@middle.net> In-Reply-To: <4440A889.60307@middle.net> 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.5 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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, Mark, Mark Butler wrote: > Hello Joe, ... >>> 2. Is the intent that a port name be a service instance specifier in >>> addition to a service type specifier? >> >> The instance is completely specified by the connection, i.e., by the >> socket pair already; having a further specifier would require the option >> in subsequent segments and would unnecessarily complicate all segment >> processing, rather than just SYNs and SYN-ACKs. (at least if I >> understand what you're suggesting) >> > Say you have multiple web servers on the same machine. Ah - sorry; now I get the issue: Then: a) run a single web server and demux in the service protocol. Originally web servers couldn't do this because the GET target had the host ID stripped off; the protocol was changed to include the host ID to support this. b) get another IP address; what you're doing by running them on different ports is overloading the Internet concept of a 'service' and a 'host', IMO. The issue is one of info and how it is known/shared. See the end for why (b) is probably what you want for a transport protocol, IMO. A host on the Internet already needs to know the name and service of the other host it is contacting, i.e., out of band, in order to establish a connection. The current method of "run multiple servers on different port numbers" is basically equivalent to "run HTTP on what everyone else thinks is a DNS port". I.e., the strings are meaningful as service IDs - they've never been semantic anyway. There's no reason that a web server MUST bind to a port that says "HTTP.80", or even "HTTP.53". If you extend the string to include a service instance, it _must_ be known by the other end a-priori. There's no difference between: "HTTP.3.80" and "HTTP.4.80" (explicit instance IDs) and "HTTP-3.80" and "HTTP-4.80" or even "HTTP.80" and "HTTQ.80" In all three cases, the service is to the left of the ".80". What it means is up to the two parties at the ends. > Currently one > specifies which one to connect to by changing the port number. Now with > an extension like this a web server can listen on all ports > simultaneously and the TCP stack will associate incoming connections > with a web server process by matching on the "port name". So if you want > to run two different web servers on the same IP address, each one will > have to use a different port name, i.e. the port name will have to carry > both service type and instance information. That's one way, as per above. Another is to push the info to the port number side, i.e., not to listen on all ports, just as we do today: HTTP.80 and HTTP.81 could be two different instances This lets you run 65,536 web servers using today's technique, but allows you to still run other services on all those ports. Again, since the origin needs to know - either the service name has changed on a per instance basis or the port number is specific - why bother with putting the instance number anywhere that misleads the designer into thinking otherwise? >>> If both, why not use a DCCP style service type code, plus an >>> additional service instance code? >> >> I don't see the reason for an instance code here. The goal is to >> separate the existing socket pair instance specifier from the service >> specifier only. >> > There is some confusion about the sense of service instance here. I > mean a logically independent provider of network services, and you > appear to mean a connection over which services are provided. Agreed; I think I answered your original question above now. >>> 3. Using a name string instead of binary numeric identifiers seems >>> unnecessarily expensive. >>> >> >> Considering that more than a few common services are a three characters >> long, there's no difference. > > If you want to store them in structures, there is a considerable > difference, because arbitrary length strings generally have to be > dynamically allocated. If in a hashed lookup process, every entry in > the same hash chain has to be strcmp()'d to check for a match, when a > simple integer comparison or two would otherwise do nicely Looking 16-bit numbers up in a table is fast and comparatively compact. Looking 32-bit numbers up in a table is insane - it's far too sparse to be efficient; you're back to hashing. Looking up strings can be done quickly and compactly - use a dictionary tree. >> They're easier to debug. And again then we >> have to reserve two things when one will do. >> >> And if we have a set of numbers, we're back to probably deploying a >> lookup function again. Part of this was motivated by decoupling the >> service name from a set of numbers. >> > The service instance number is logically equivalent to the use of the > port number in a URI like: > > http://plasma.example.com:8000/ > > except they would be much smaller, similar to the digit in "www1", > "www2", "www3" and so on. OK - and that works fine as a portname. > Databases like Oracle and DB2 support multiple > server instances on the same machine and use instance identifiers as > selectors, both over the network and with environment variables like > ORACLE_SID and DB2_SID. > > Service instance identifiers would not need to be looked up. > Non-default values would be rare, and used only in cases where more than > one service process of the same type run on the same IP address. > > They could be used more pervasively, e.g. to do NAT dispatching, or to > reduce the number of IP addresses required in virtually hosted > environments, but that would require something comparable to SRV > records. That is not such a bad option - a DNS lookup generally occurs > already, and one can get the extra information in the same > request/response turnaround, right? All that can be done with ports > now, but would not be able to be done with the proposed extension unless > "port names" can include both service type and service (logical > provider) instance information. Why is that a problem? > So if the option is a string the question is what standard format should > it have, or should it be anything goes with a few well known defaults? It's meaningful only between consenting endpoints; the latter seems fine. >>> I would like to see a scheme exactly the same, except have the SYN >>> option carry a DCCP compatible service type identifier, plus an >>> additional 32 bit service instance identifier, where instance N means >>> the Nth instance of the specified service type. >>> >>> >> >> We don't necessarily want to propagate DCCP's notion of service code >> groups or instances. >> > I think with service [type] codes the DCCP folks had firewalls more in > mind, e.g. to support policies where a party is trying to keep a > particular protocol from being run on any port. I am told that PPIDs > were added to SCTP in an attempt to achieve a similar objective. Any > standard service naming scheme is likely to contain similar information. > > DCCP service instances are an artifact of the way DCCP uses ports, not > anything designed in, as far as I can tell. I am just saying that a > widely used capability should not be thrown away. It's hard to argue that a technique designed for a fairly recent protocol is 'widely used'. > IP addresses are hard > to come by, and a more extensive use of instance identifiers is one way > to conserve the IPv4 address space. I *REALLY* don't think this is a valid argument in favor of instances. Instances basically mimic the notion of a host ID; instance IDs are hidden IP addresses. If that's what you want, then open a connection with a tunneled IP packet and let the inner tunnel address be your 'instance' demultiplexer'. I.e., this is solving a problem that is NOT TCP's, which is why I don't think it belongs at the transport layer. > i.e. a company could adopt a scheme > where interior nodes are assigned instance identifiers. > > Then the proper instance identifiers for something to establish a > connection to something like an SIP telephone number could be listed in > an externally visible DNS zone, and a remote caller could look up the > public IP address of the NAT box, and the instance number associated > with the interior node, and establish an inbound connection throught the > NAT without ridiculous workarounds. No media gateways required either - > the instance identifier could identify a specific phone, just like a > telephone extension number, except transparent to the caller. > > - Mark B. > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 15 11:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUmvc-0002oG-BY; Sat, 15 Apr 2006 11:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUmvb-0002oB-1X for tcpm@ietf.org; Sat, 15 Apr 2006 11:43:15 -0400 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 1FUmvZ-0003Tz-MG for tcpm@ietf.org; Sat, 15 Apr 2006 11:43:14 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FUmvK-0003nH-00; Sat, 15 Apr 2006 11:42:58 -0400 From: Tim Shepard To: "Caitlin Bestler" Subject: Re: [tcpm] syn flooding draft In-reply-to: Your message of Fri, 14 Apr 2006 11:02:52 -0700. <54AD0F12E08D1541B826BE97C98F99F13CA3D5@NT-SJCA-0751.brcm.ad.broadcom.com> Date: Sat, 15 Apr 2006 11:42:58 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Christian Huitema , Ethan Blanton , 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 > >>> Can you cite an example where the passive side would send the first > >>> data and be accepting a large number of connections from unknown > >>> remote peers? > >> > >> ssh > > > > SMTP, if implemented according to RFC2821, which states > > (section 4.3.1 Sequencing Overview, page 47): > > Good points. The draft should probably recommend use of Syn Caching > over Syn cookies for this type of daemon. How's a TCP implementation supposed to know what type of daemon is using it? -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sat Apr 15 23:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUxpk-0004Eq-UV; Sat, 15 Apr 2006 23:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUxph-0004BM-NE for tcpm@ietf.org; Sat, 15 Apr 2006 23:21:54 -0400 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 1FUxph-0000xl-AC for tcpm@ietf.org; Sat, 15 Apr 2006 23:21:53 -0400 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FUxpf-00042o-00; Sat, 15 Apr 2006 23:21:51 -0400 From: Tim Shepard To: Joe Touch Subject: Re: [tcpm] TCP port names option ID In-reply-to: Your message of Fri, 14 Apr 2006 15:46:24 -0700. <44402640.7030705@isi.edu> Date: Sat, 15 Apr 2006 23:21:51 -0400 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: tcpm 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 >From Joe's draft: > Portnames need to fit inside the available TCP option space, which > provides 40 bytes for options. It is useful to consider that TCP SYN > packets may include other options consuming up to 33 bytes, notably: > > o 16 bytes of authentication [Bo05] [We06] [To06] > > o 4 bytes of MSS > > o 10 bytes of timestamp > > o 3 bytes of windowscale > > This leaves only 7 bytes for the portname option, or 5 bytes for the > NAMESTRING. I had not thought of the 16 bytes of authentication until I saw it on the list in the draft. Ouch. Can we hope that will be deprecated by the time something like a service name option gets deployed? What about the TCP Sack-Permitted Option which is 2 bytes long? (And is very common on TCP SYN packets these days.) If you add that to the list, we're down to 3 bytes for the NAMESTRING, which is only one byte more than the 16-bit port number that we started with. In any case, it seems if we go forward with this, it will be the last option we can add to the TCP SYN packet without breaking something, as we will have (in some cases) completely used up all space for a TCP option. So before we go forward with this, we should make sure we really want to do that. \begin{thinking-out-loud} Do we need a new "extended TCP options" option? I cannot think of how to do that in a backwards compatible way. When I've thought about how to bring CHAOSNET-style service name capabilities to TCP, I figured that you'd send the SYN to port zero with the service name and argv style arguments to the service in the data portion of the SYN segment (where we would not have this space crunch), and have the reply come back with the port number filled in. If the packet comes back with the correct pair of IP addresses and the right destination port number, but a source port number we've never heard of, then before dropping the packet, we'd see if any connection block was in the SYN_SENT state wants it. If the ACK is acceptable, it fills in the foreign port number in connection block. Use of the timestamp option could also help make sure that there was no ambiguity in matching up the SYN-ACK with the SYN (though I expect the ACK value would be good enough if the ISN was well chosen as per RFC1498.) This is perhaps less backwards compatable (if not implemented on the other end, you get a RST), but more likely to last through the centuries without running out of room for something. And then, what about SCTP? If TCP needs needs, doesn't SCTP need this too? (Or does it already have it?) \end{thinking-out-loud} -Tim Shepard shep@alum.mit.edu _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 16 00:44:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUz6u-0003HC-9h; Sun, 16 Apr 2006 00:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUz6s-0003H7-P2 for tcpm@ietf.org; Sun, 16 Apr 2006 00:43:42 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUz6p-0003yT-My for tcpm@ietf.org; Sun, 16 Apr 2006 00:43:40 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FUz6q-00089t-KT; Sat, 15 Apr 2006 22:43:18 -0600 Message-ID: <4441CB88.1080803@middle.net> Date: Sat, 15 Apr 2006 22:43:52 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu> <4440A889.60307@middle.net> <444111B7.7050001@isi.edu> In-Reply-To: <444111B7.7050001@isi.edu> X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.3 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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="===============0531504635==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0531504635== Content-Type: multipart/alternative; boundary="------------040107030301010005040508" This is a multi-part message in MIME format. --------------040107030301010005040508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Joe, Joe Touch wrote: >Then: >a) run a single web server and demux in the service protocol. Originally >web servers couldn't do this because the GET target had the host ID >stripped off; the protocol was changed to include the host ID to support >this. > > This is fine as long as the ULP supports this, and you have no need to run different versions or configurations of the same server software for testing purposes or to work around various limitations. To always run a web service using the same service identifier would require a higher level demultiplexer akin to a reverse proxy, and there is certainly no ULP independent means of doing that. >b) get another IP address; what you're doing by running them on >different ports is overloading the Internet concept of a 'service' and a >'host', IMO. > > Admittedly, if everyone was running IPv6 this wouldn't be needed very much, except to say that process required to safely and effectively assign a new service instance id is much simpler than doing the same with a separate IP address, and has less internal overhead (ARP, send address ambiguity, etc.). It is also simpler, more reliable, and more "portable" than the current process of assigning a non-standard port. That is just incidental use where IP addresses of the necessary scope are actually available. Where they are not easily available, overloading on port reaches its logical extreme with NAT - which in practice is nothing other than a stand-alone _transport_ layer de-multiplexer. Dispatch based only on service type would not allow for the equivalent of port forwarding, i.e. a NAT device that implemented solely that method would be even less capable of handling inbound connections than existing implementations. On the other hand, a standard service type / service instance split would allow a NAT device to de-multiplex inbound connections very cleanly. >The issue is one of info and how it is known/shared. See the end for why >(b) is probably what you want for a transport protocol, IMO. > >A host on the Internet already needs to know the name and service of the >other host it is contacting, i.e., out of band, in order to establish a >connection. > >The current method of "run multiple servers on different port numbers" >is basically equivalent to "run HTTP on what everyone else thinks is a >DNS port". > > That is a bit of an overstatement - there are plenty of port numbers that have no standard association. >I.e., the strings are meaningful as service IDs - they've never been >semantic anyway. > >There's no reason that a web server MUST bind to a port that says >"HTTP.80", or even "HTTP.53". > >If you extend the string to include a service instance, it _must_ be >known by the other end a-priori. There's no difference between: > > For non-incidental use, yes. For pervasive use the service instance would have to be looked up using a directory service, just like a phone number extension. There is no hard and fast reason why a service endpoint has to be identified by (network address, service type). (network address, service type, service instance) is much more flexible. > "HTTP.3.80" and "HTTP.4.80" (explicit instance IDs) >and > "HTTP-3.80" and "HTTP-4.80" >or even > "HTTP.80" and "HTTQ.80" > >In all three cases, the service is to the left of the ".80". What it >means is up to the two parties at the ends. > > It is helpful of course to be able to do that at all, but ignoring the issue is likely to lead to incompatible adhoc formats. Say the HTTP people wanted to preserve the equivalent of the port selector in the current standard URI format, they would necessary have to prescribe the way that is formatted in the port name string. HTTP is particularly relevant case because it is extremely common to run multiple HTTP speaking "web server" processes on the same host. Everyone and their dog has their own web based configuration interface and there is no standard way to get them to share the same port on the same host. A typical server might have half a dozen... With proper DNS support (a la SRV) the URI issue would go away, but the service instance selection issue would remain and would require standardization on at least on a ULP by ULP basis. > > >>Currently one >>specifies which one to connect to by changing the port number. Now with >>an extension like this a web server can listen on all ports >>simultaneously and the TCP stack will associate incoming connections >>with a web server process by matching on the "port name". So if you want >>to run two different web servers on the same IP address, each one will >>have to use a different port name, i.e. the port name will have to carry >>both service type and instance information. >> >> > >That's one way, as per above. Another is to push the info to the port >number side, i.e., not to listen on all ports, just as we do today: > > HTTP.80 and HTTP.81 could be two different instances > >This lets you run 65,536 web servers using today's technique, but allows >you to still run other services on all those ports. > >Again, since the origin needs to know - either the service name has >changed on a per instance basis or the port number is specific - why >bother with putting the instance number anywhere that misleads the >designer into thinking otherwise? > > Requiring port numbers to be used to be able to do service instance selection preserves everything that is wrong about the status quo. The objective here is to use port numbers solely for connection disambiguation, right? >>>>3. Using a name string instead of binary numeric identifiers seems >>>>unnecessarily expensive. >>>> >>>> >>>> >>>Considering that more than a few common services are a three characters >>>long, there's no difference. >>> >>> >>If you want to store them in structures, there is a considerable >>difference, because arbitrary length strings generally have to be >>dynamically allocated. If in a hashed lookup process, every entry in >>the same hash chain has to be strcmp()'d to check for a match, when a >>simple integer comparison or two would otherwise do nicely >> >> > >Looking 16-bit numbers up in a table is fast and comparatively compact. >Looking 32-bit numbers up in a table is insane - it's far too sparse to >be efficient; you're back to hashing. > > I am not talking about linear lookup tables, but rather the cost of hash key comparisons on the collision chain, as well as the cost of dynamically allocating variable length identifiers. >Looking up strings can be done quickly and compactly - use a dictionary >tree. > > Implementing a relatively exotic kernel data structure in an efficient, SMP safe manner is not something to be taken lightly. No one does filesystem lookup or caching that way, for example. > > > >> >>They could be used more pervasively, e.g. to do NAT dispatching, or to >>reduce the number of IP addresses required in virtually hosted >>environments, but that would require something comparable to SRV >>records. That is not such a bad option - a DNS lookup generally occurs >>already, and one can get the extra information in the same >>request/response turnaround, right? All that can be done with ports >>now, but would not be able to be done with the proposed extension unless >>"port names" can include both service type and service (logical >>provider) instance information. >> >> > >Why is that a problem? > > Standardization and efficiency (or rather the lack thereof). >>DCCP service instances are an artifact of the way DCCP uses ports, not >>anything designed in, as far as I can tell. I am just saying that a >>widely used capability should not be thrown away. >> >> > >It's hard to argue that a technique designed for a fairly recent >protocol is 'widely used'. > > Instance selection at the transport layer is not something that was designed into DCCP. It is a universal practice with TCP and UDP that is an artifact of the way ports are used. That is the widely used capability I am speaking of. >>IP addresses are hard >>to come by, and a more extensive use of instance identifiers is one way >>to conserve the IPv4 address space. >> >> > >I *REALLY* don't think this is a valid argument in favor of instances. >Instances basically mimic the notion of a host ID; instance IDs are >hidden IP addresses. If that's what you want, then open a connection >with a tunneled IP packet and let the inner tunnel address be your >'instance' demultiplexer'. > > Network layer tunneling is an enormously complex solution for such a simple problem, and would be borderline impossible to implement for publically available services in the contemporary environment. >I.e., this is solving a problem that is NOT TCP's, which is why I don't >think it belongs at the transport layer > > The popularity of NAT devices indicates that something that needs to be done at the transport layer. Failure to anticipate this real world requirement is *precisely* why NAT is such a ridiculous mess today. I agree in a perfect world this could all be done at a lower or higher layer. In the world as it exists today, however, the problem is most easily solved at the transport layer. That is why everyone uses NAT boxes instead of either (1) paying to have their ISP configure and route a larger IP address block or (2) running application layer proxies exclusively. - Mark B. --------------040107030301010005040508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Joe,

Joe Touch wrote: 
Then:
a) run a single web server and demux in the service protocol. Originally
web servers couldn't do this because the GET target had the host ID
stripped off; the protocol was changed to include the host ID to support
this.
This is fine as long as the ULP supports this, and you have no need to run different versions or configurations of the same server software for testing purposes or to work around various limitations.  To always run a web service using the same service identifier would require a higher level demultiplexer akin to a reverse proxy, and there is certainly no ULP independent means of doing that. 
b) get another IP address; what you're doing by running them on
different ports is overloading the Internet concept of a 'service' and a
'host', IMO.
Admittedly, if everyone was running IPv6 this wouldn't be needed very much, except to say that process required to safely and effectively assign a new service instance id is much simpler than doing the same with a separate IP address, and has less internal overhead (ARP, send address ambiguity, etc.).   It is also simpler, more reliable, and more "portable" than the current process of assigning a non-standard port.

That is just incidental use where IP addresses of the necessary scope are actually available. Where they are not easily available, overloading on port reaches its logical extreme with NAT - which in practice is nothing other than a stand-alone _transport_ layer de-multiplexer.  Dispatch based only on service type would not allow for the equivalent of port forwarding, i.e. a NAT device that implemented solely that method would be even less capable of handling inbound connections than existing implementations.   On the other hand, a standard service type / service instance split would allow a NAT device to de-multiplex inbound connections very cleanly.

The issue is one of info and how it is known/shared. See the end for why
(b) is probably what you want for a transport protocol, IMO.

A host on the Internet already needs to know the name and service of the
other host it is contacting, i.e., out of band, in order to establish a
connection.

The current method of "run multiple servers on different port numbers"
is basically equivalent to "run HTTP on what everyone else thinks is a
DNS port".
That is a bit of an overstatement - there are plenty of port numbers that have no standard association.
I.e., the strings are meaningful as service IDs - they've never been
semantic anyway.

There's no reason that a web server MUST bind to a port that says
"HTTP.80", or even "HTTP.53".

If you extend the string to include a service instance, it _must_ be
known by the other end a-priori. There's no difference between:
For non-incidental use, yes.  For pervasive use the service instance would have to be looked up using a directory service, just like a phone number extension.  There is no hard and fast reason why a service endpoint has to be identified by (network address, service type).  (network address, service type, service instance) is much more flexible.
	"HTTP.3.80" and "HTTP.4.80" (explicit instance IDs)
and
	"HTTP-3.80" and "HTTP-4.80"
or even
	"HTTP.80" and "HTTQ.80"

In all three cases, the service is to the left of the ".80". What it
means is up to the two parties at the ends.
It is helpful of course to be able to do that at all, but ignoring the issue is likely to lead to incompatible adhoc formats.  Say the HTTP people wanted to preserve the equivalent of the port selector in the current standard URI format, they would necessary have to prescribe the way that is formatted in the port name string.  HTTP is particularly relevant case because it is extremely common to run multiple HTTP speaking "web server" processes on the same host.  Everyone and their dog has their own web based configuration interface and there is no standard way to get them to share the same port on the same host.  A typical server might have half a dozen...

With proper DNS support (a la SRV) the URI issue would go away, but the service instance selection issue would remain and would require standardization on at least on a ULP by ULP basis.

  
Currently one
specifies which one to connect to by changing the port number.  Now with
an extension like this a web server can listen on all ports
simultaneously and the TCP stack will associate incoming connections
with a web server process by matching on the "port name". So if you want
to run two different web servers on the same IP address, each one will
have to use a different port name, i.e. the port name will have to carry
both service type and instance information.
    

That's one way, as per above. Another is to push the info to the port
number side, i.e., not to listen on all ports, just as we do today:

	HTTP.80 and HTTP.81 could be two different instances

This lets you run 65,536 web servers using today's technique, but allows
you to still run other services on all those ports.

Again, since the origin needs to know - either the service name has
changed on a per instance basis or the port number is specific - why
bother with putting the instance number anywhere that misleads the
designer into thinking otherwise?
Requiring port numbers to be used to be able to do service instance selection preserves everything that is wrong about the status quo.  The objective here is to use port numbers solely for connection disambiguation, right?

3. Using a name string instead of binary numeric identifiers seems
unnecessarily expensive.
    
        
Considering that more than a few common services are a three characters
long, there's no difference. 
      
If you want to store them in structures, there is a considerable
difference, because arbitrary length strings generally have to be
dynamically allocated.  If in a hashed lookup process, every entry in
the same hash chain has to be strcmp()'d to check for a match, when a
simple integer comparison or two would otherwise do nicely
    

Looking 16-bit numbers up in a table is fast and comparatively compact.
Looking 32-bit numbers up in a table is insane - it's far too sparse to
be efficient; you're back to hashing.
I am not talking about linear lookup tables, but rather the cost of hash key comparisons on the collision chain, as well as the cost of dynamically allocating variable length identifiers.
Looking up strings can be done quickly and compactly - use a dictionary
tree.
Implementing a relatively exotic kernel data structure in an efficient, SMP safe manner is not something to be taken lightly.  No one does filesystem lookup or caching that way, for example.


  

They could be used more pervasively, e.g. to do NAT dispatching, or to
reduce the number of IP addresses required in virtually hosted
environments, but that would require something comparable to SRV
records.  That is not such a bad option - a DNS lookup generally occurs
already, and one can get the extra information in the same
request/response turnaround, right?  All that can be done with ports
now, but would not be able to be done with the proposed extension unless
"port names" can include both service type and service (logical
provider) instance information.
    

Why is that a problem?
Standardization and efficiency (or rather the lack thereof).

DCCP service instances are an artifact of the way DCCP uses ports, not
anything designed in, as far as I can tell.  I am just saying that a
widely used capability should not be thrown away.
    

It's hard to argue that a technique designed for a fairly recent
protocol is 'widely used'.
Instance selection at the transport layer is not something that was designed into DCCP.  It is a universal practice with TCP and UDP that is an artifact of the way ports are used. That is the widely used capability I am speaking of.
IP addresses are hard
to come by, and a  more extensive use of instance identifiers is one way
to conserve the IPv4 address space.
    

I *REALLY* don't think this is a valid argument in favor of instances.
Instances basically mimic the notion of a host ID; instance IDs are
hidden IP addresses. If that's what you want, then open a connection
with a tunneled IP packet and let the inner tunnel address be your
'instance' demultiplexer'.
Network layer tunneling is an enormously complex solution for such a simple problem, and would be borderline impossible to implement for publically available services in the contemporary environment. 

I.e., this is solving a problem that is NOT TCP's, which is why I don't
think it belongs at the transport layer
The popularity of NAT devices indicates that something that needs to be done at the transport layer. Failure to anticipate this real world requirement is *precisely* why NAT is such a ridiculous mess today.   I agree in a perfect world this could all be done at a lower or higher layer.  In the world as it exists today, however, the problem is most easily solved at the transport layer.   That is why everyone uses NAT boxes instead of either (1) paying to have their ISP configure and route a larger IP address block or (2) running application layer proxies exclusively.

 - Mark B.

--------------040107030301010005040508-- --===============0531504635== 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 --===============0531504635==-- From tcpm-bounces@ietf.org Sun Apr 16 01:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUzrf-000055-9z; Sun, 16 Apr 2006 01:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUzrd-000050-LD for tcpm@ietf.org; Sun, 16 Apr 2006 01:32:01 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUzrd-0005Le-1T for tcpm@ietf.org; Sun, 16 Apr 2006 01:32:01 -0400 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 k3G5UsR18495; Sat, 15 Apr 2006 22:30:54 -0700 (PDT) Message-ID: <4441D686.7090802@isi.edu> Date: Sat, 15 Apr 2006 22:30:46 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mark Butler References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu> <4440A889.60307@middle.net> <444111B7.7050001@isi.edu> <4441CB88.1080803@middle.net> In-Reply-To: <4441CB88.1080803@middle.net> 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: 10d2fdecab7a7fa796e06e001d026c91 Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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 Mark Butler wrote: > Hello Joe, > > Joe Touch wrote: >> Then: >> a) run a single web server and demux in the service protocol. Originally >> web servers couldn't do this because the GET target had the host ID >> stripped off; the protocol was changed to include the host ID to support >> this. >> > This is fine as long as the ULP supports this, and you have no need to > run different versions or configurations of the same server software for > testing purposes or to work around various limitations. To always run a > web service using the same service identifier would require a higher > level demultiplexer akin to a reverse proxy, and there is certainly no > ULP independent means of doing that. The question is whether that is sensible. If you want to run a web service on all incoming ports AND all incoming addresses, then that's what you get, and perhaps that what you should get. >> b) get another IP address; what you're doing by running them on >> different ports is overloading the Internet concept of a 'service' and a >> 'host', IMO. >> > Admittedly, if everyone was running IPv6 this wouldn't be needed very > much, except to say that process required to safely and effectively > assign a new service instance id is much simpler than doing the same > with a separate IP address, and has less internal overhead (ARP, send > address ambiguity, etc.). It is also simpler, more reliable, and more > "portable" than the current process of assigning a non-standard port. > > That is just incidental use where IP addresses of the necessary scope > are actually available. Where they are not easily available, overloading > on port reaches its logical extreme with NAT - which in practice is > nothing other than a stand-alone _transport_ layer de-multiplexer. > Dispatch based only on service type would not allow for the equivalent > of port forwarding, i.e. a NAT device that implemented solely that > method would be even less capable of handling inbound connections than > existing implementations. On the other hand, a standard service type / > service instance split would allow a NAT device to de-multiplex inbound > connections very cleanly. This is a mechanism to forward on services rather than just ports, which can help some NAT-created problems. It is NOT a mechanism to reimplement numbering at the transport layer so that multiple hosts behind a NAT can now become visible. NATs create that latter problem, and will ALWAYS end up with it, because once service names exist they will start remapping those as well. >> The issue is one of info and how it is known/shared. See the end for why >> (b) is probably what you want for a transport protocol, IMO. >> >> A host on the Internet already needs to know the name and service of the >> other host it is contacting, i.e., out of band, in order to establish a >> connection. >> >> The current method of "run multiple servers on different port numbers" >> is basically equivalent to "run HTTP on what everyone else thinks is a >> DNS port". >> > That is a bit of an overstatement - there are plenty of port numbers > that have no standard association. >> I.e., the strings are meaningful as service IDs - they've never been >> semantic anyway. >> >> There's no reason that a web server MUST bind to a port that says >> "HTTP.80", or even "HTTP.53". >> >> If you extend the string to include a service instance, it _must_ be >> known by the other end a-priori. There's no difference between: >> > For non-incidental use, yes. For pervasive use the service instance > would have to be looked up using a directory service, just like a phone > number extension. There is no hard and fast reason why a service > endpoint has to be identified by (network address, service type). > (network address, service type, service instance) is much more flexible. >> "HTTP.3.80" and "HTTP.4.80" (explicit instance IDs) >> and >> "HTTP-3.80" and "HTTP-4.80" >> or even >> "HTTP.80" and "HTTQ.80" >> >> In all three cases, the service is to the left of the ".80". What it >> means is up to the two parties at the ends. >> > It is helpful of course to be able to do that at all, but ignoring the > issue is likely to lead to incompatible adhoc formats. Say the HTTP > people wanted to preserve the equivalent of the port selector in the > current standard URI format, they would necessary have to prescribe the > way that is formatted in the port name string. HTTP is particularly > relevant case because it is extremely common to run multiple HTTP > speaking "web server" processes on the same host. Everyone and their > dog has their own web based configuration interface and there is no > standard way to get them to share the same port on the same host. A > typical server might have half a dozen... A standard way is to run a single web server with multiple 'roots' and to overload the DNS in the forward direction, i.e., multiple DNS names that map to a single IP address. What you're trying to support is running multiple services with the same name on all incoming ports, where the name is the same and the 'all ports' is the same and the IP address is the same, but somehow something is different. That's not something TCP is designed to address. It's been hacked by moving services from well-known ports to other ports; that's still supported here. It can also be supported by overloading the meaning of the service name. Since which of the two methods is used is a matter ONLY for the consenting parties (i.e., the site running the web server and the URLs it serves), why does it matter? There are multiple ways of skinning this cat today: - DNS overloading with multiple roots on a single server - multiple IP addresses - separate IP ports This solution isn't going to get rid of any of these necessarily, nor is it intended to. > With proper DNS support (a la SRV) the URI issue would go away, but the > service instance selection issue would remain and would require > standardization on at least on a ULP by ULP basis. The doc discusses why DNS support for SRV records is a non-starter. I may be given a DNS name by my ISP, but they don't give me permission to insert a SRV record, nor do I suspect that's in the future. >>> Currently one >>> specifies which one to connect to by changing the port number. Now with >>> an extension like this a web server can listen on all ports >>> simultaneously and the TCP stack will associate incoming connections >>> with a web server process by matching on the "port name". So if you want >>> to run two different web servers on the same IP address, each one will >>> have to use a different port name, i.e. the port name will have to carry >>> both service type and instance information. >>> >> >> That's one way, as per above. Another is to push the info to the port >> number side, i.e., not to listen on all ports, just as we do today: >> >> HTTP.80 and HTTP.81 could be two different instances >> >> This lets you run 65,536 web servers using today's technique, but allows >> you to still run other services on all those ports. >> >> Again, since the origin needs to know - either the service name has >> changed on a per instance basis or the port number is specific - why >> bother with putting the instance number anywhere that misleads the >> designer into thinking otherwise? >> > Requiring port numbers to be used to be able to do service instance > selection preserves everything that is wrong about the status quo. The > objective here is to use port numbers solely for connection > disambiguation, right? It's to separate service from port. It's not to separate instance from service or instance from port; separating service from port does NOT preserve the status quo, even without addressing instance, either. >>>>> 3. Using a name string instead of binary numeric identifiers seems >>>>> unnecessarily expensive. >>>>> >>>>> >>>> Considering that more than a few common services are a three characters >>>> long, there's no difference. >>>> >>> If you want to store them in structures, there is a considerable >>> difference, because arbitrary length strings generally have to be >>> dynamically allocated. If in a hashed lookup process, every entry in >>> the same hash chain has to be strcmp()'d to check for a match, when a >>> simple integer comparison or two would otherwise do nicely >>> >> >> Looking 16-bit numbers up in a table is fast and comparatively compact. >> Looking 32-bit numbers up in a table is insane - it's far too sparse to >> be efficient; you're back to hashing. >> > I am not talking about linear lookup tables, but rather the cost of hash > key comparisons on the collision chain, as well as the cost of > dynamically allocating variable length identifiers. > >> Looking up strings can be done quickly and compactly - use a dictionary >> tree. >> > Implementing a relatively exotic kernel data structure in an efficient, > SMP safe manner is not something to be taken lightly. No one does > filesystem lookup or caching that way, for example. Dictionary trees aren't exotic; more complex structures are used already for IP address lookups; SYN matching (and this is ONLY for SYN packets) doesn't need to happen on a very fast timescale, either. >>> They could be used more pervasively, e.g. to do NAT dispatching, or to >>> reduce the number of IP addresses required in virtually hosted >>> environments, but that would require something comparable to SRV >>> records. That is not such a bad option - a DNS lookup generally occurs >>> already, and one can get the extra information in the same >>> request/response turnaround, right? All that can be done with ports >>> now, but would not be able to be done with the proposed extension unless >>> "port names" can include both service type and service (logical >>> provider) instance information. >>> >> >> Why is that a problem? >> > Standardization and efficiency (or rather the lack thereof). > >>> DCCP service instances are an artifact of the way DCCP uses ports, not >>> anything designed in, as far as I can tell. I am just saying that a >>> widely used capability should not be thrown away. >>> >> >> It's hard to argue that a technique designed for a fairly recent >> protocol is 'widely used'. >> > Instance selection at the transport layer is not something that was > designed into DCCP. It is a universal practice with TCP and UDP that is > an artifact of the way ports are used. That is the widely used > capability I am speaking of. Instance selection can be done in various layers; this doesn't preclude any of them. It doesn't focus on that as a specific capability, either. >>> IP addresses are hard >>> to come by, and a more extensive use of instance identifiers is one way >>> to conserve the IPv4 address space. >>> >> >> I *REALLY* don't think this is a valid argument in favor of instances. >> Instances basically mimic the notion of a host ID; instance IDs are >> hidden IP addresses. If that's what you want, then open a connection >> with a tunneled IP packet and let the inner tunnel address be your >> 'instance' demultiplexer'. >> > Network layer tunneling is an enormously complex solution for such a > simple problem, and would be borderline impossible to implement for > publically available services in the contemporary environment. Similar assertions were once made about packet remapping (e.g., NAT), and about IP forwarding at line rate. >> I.e., this is solving a problem that is NOT TCP's, which is why I don't >> think it belongs at the transport layer >> > The popularity of NAT devices indicates that something that needs to be > done at the transport layer. Actually, it indicates that whatever we do someone will try to undo it, IMO. Even if we put instances in the service name, someone will decide that everything behind a NAT ought to look like the same instance. > Failure to anticipate this real world > requirement is *precisely* why NAT is such a ridiculous mess today. This mechanism can't fix what's broken with NATs, nor will instance numbers. > I > agree in a perfect world this could all be done at a lower or higher > layer. It can and should be done at a lower or higher layer, and still can be with this mechanism. There's nothing here that undoes existing methods to get around the problem NATs create. That's why there's no reason to address that issue specifically. Joe In the world as it exists today, however, the problem is most > easily solved at the transport layer. That is why everyone uses NAT > boxes instead of either (1) paying to have their ISP configure and route > a larger IP address block or (2) running application layer proxies > exclusively. > > - Mark B. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 16 01:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV06X-0002Lq-Pz; Sun, 16 Apr 2006 01:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV06W-0002Ll-3B for tcpm@ietf.org; Sun, 16 Apr 2006 01:47:24 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV06O-0005cV-K7 for tcpm@ietf.org; Sun, 16 Apr 2006 01:47:22 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FV06Q-0008B6-5m; Sat, 15 Apr 2006 23:46:56 -0600 Message-ID: <4441DA71.5070703@middle.net> Date: Sat, 15 Apr 2006 23:47:29 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tcpm@ietf.org Subject: Re: [tcpm] TCP port names option ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Tim Shepard 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 Tim Shepard wrote: >When I've thought about how to bring CHAOSNET-style service name >capabilities to TCP, I figured that you'd send the SYN to port zero >with the service name and argv style arguments to the service in the >data portion of the SYN segment (where we would not have this space >crunch), and have the reply come back with the port number filled in. >If the packet comes back with the correct pair of IP addresses and the >right destination port number, but a source port number we've never >heard of, then before dropping the packet, we'd see if any connection >block was in the SYN_SENT state wants it. If the ACK is acceptable, >it fills in the foreign port number in connection block. Use of the >timestamp option could also help make sure that there was no ambiguity >in matching up the SYN-ACK with the SYN (though I expect the ACK value >would be good enough if the ISN was well chosen as per RFC1498.) > >This is perhaps less backwards compatable (if not implemented on the >other end, you get a RST), but more likely to last through the >centuries without running out of room for something. > > >And then, what about SCTP? If TCP needs needs, doesn't SCTP need >this too? (Or does it already have it?) > > SCTP uses parameterized INIT / INIT ACK chunks for association establishment. Each one can be nearly MTU sized before problems start to arise. SCTP already uses 32-bit verification tags to protect against the equivalent of SYN floods and other blind attacks, and there is a draft for adding encryption quality authentication to SCTP PDUs on a controlled basis. By 'controlled' I mean authentication (AUTH) chunks can be added just to packets that contain certain critical control information (notably addip). As to the issue of whether SCTP would benefit from something like service type / instance selection parameter, the answer is yes. SCTP currently uses ports just like TCP, except shared over multiple addresses. Typical implementations normally allocate ports at the host level, rather than IP address level. A typical outbound connection will reserve the selected local port number on all available addresses, and extend that reservation to new ones (otherwise ASCONF does not work properly). - Mark B. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 16 01:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV0Hi-0007mz-Nm; Sun, 16 Apr 2006 01:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV0Hh-0007bV-0Q for tcpm@ietf.org; Sun, 16 Apr 2006 01:58:57 -0400 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV0He-0005zu-Iy for tcpm@ietf.org; Sun, 16 Apr 2006 01:58:56 -0400 Received: from [128.9.176.213] (c2-vpn04.isi.edu [128.9.176.213]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3G5wYR23114; Sat, 15 Apr 2006 22:58:34 -0700 (PDT) Message-ID: <4441DD02.5030907@isi.edu> Date: Sat, 15 Apr 2006 22:58:26 -0700 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tim Shepard Subject: Re: [tcpm] TCP port names option ID 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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: tcpm 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 Tim Shepard wrote: >>From Joe's draft: > >> Portnames need to fit inside the available TCP option space, which >> provides 40 bytes for options. It is useful to consider that TCP SYN >> packets may include other options consuming up to 33 bytes, notably: >> >> o 16 bytes of authentication [Bo05] [We06] [To06] >> >> o 4 bytes of MSS >> >> o 10 bytes of timestamp >> >> o 3 bytes of windowscale >> >> This leaves only 7 bytes for the portname option, or 5 bytes for the >> NAMESTRING. > > > I had not thought of the 16 bytes of authentication until I saw it on > the list in the draft. Ouch. Can we hope that will be deprecated by > the time something like a service name option gets deployed? I would prefer that IPsec were used to TCP authentication. That said, I'd be glad to hear if any of the above can be left out of the SYN in favor of waiting for the data packet, i.e., other than authentication. As noted in the ID, though, this is an issue only for a small set of protocols for which TCP-level auth is currently either deployed or intended (routing protocols). > What about the TCP Sack-Permitted Option which is 2 bytes long? (And > is very common on TCP SYN packets these days.) If you add that to the > list, we're down to 3 bytes for the NAMESTRING, which is only one byte > more than the 16-bit port number that we started with. > > > In any case, it seems if we go forward with this, it will be the last > option we can add to the TCP SYN packet without breaking something, as > we will have (in some cases) completely used up all space for a TCP > option. So before we go forward with this, we should make sure we > really want to do that. That argues for rethinking the TCP auth option except for routing protocols, which is basically where I thought things were anyway. > \begin{thinking-out-loud} > > Do we need a new "extended TCP options" option? I cannot think of how > to do that in a backwards compatible way. Why would it need to be backwards compatible? It needs to fail in a non-silent way - just as this option does, but if space is limited the initiator might retry with fewer options. > When I've thought about how to bring CHAOSNET-style service name > capabilities to TCP, I figured that you'd send the SYN to port zero > with the service name and argv style arguments to the service in the > data portion of the SYN segment (where we would not have this space > crunch), and have the reply come back with the port number filled in. Putting data in the SYN can cause problems - in particular, if the implementation wants to send an MSS, you need to hold off on some to create space for the option; the data could be overwritten by subsequent packets, since it cannot be ACKd' until the connection is open (which data do you believe?), etc. > If the packet comes back with the correct pair of IP addresses and the > right destination port number, but a source port number we've never > heard of, then before dropping the packet, we'd see if any connection > block was in the SYN_SENT state wants it. If the ACK is acceptable, > it fills in the foreign port number in connection block. Use of the > timestamp option could also help make sure that there was no ambiguity > in matching up the SYN-ACK with the SYN (though I expect the ACK value > would be good enough if the ISN was well chosen as per RFC1498.) > > This is perhaps less backwards compatable (if not implemented on the > other end, you get a RST), but more likely to last through the > centuries without running out of room for something. I'm more wary about playing with data space than playing with the option space; we can always extend the option space in equally non-compatible ways for the centuries ;-) > And then, what about SCTP? If TCP needs needs, doesn't SCTP need > this too? (Or does it already have it?) > > \end{thinking-out-loud} > > -Tim Shepard > shep@alum.mit.edu > > > > > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm From tcpm-bounces@ietf.org Sun Apr 16 03:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV1ex-0000XT-0b; Sun, 16 Apr 2006 03:27:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV1eu-0000XF-K3 for tcpm@ietf.org; Sun, 16 Apr 2006 03:27:00 -0400 Received: from [166.70.100.114] (helo=mail.middle.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV1en-0000Y0-Ls for tcpm@ietf.org; Sun, 16 Apr 2006 03:26:58 -0400 Received: from citius ([67.137.150.193] helo=[192.168.0.61]) by mail.middle.net with esmtp (Exim 4.24) id 1FV1ep-0008PM-56; Sun, 16 Apr 2006 01:26:33 -0600 Message-ID: <4441F1CB.1080001@middle.net> Date: Sun, 16 Apr 2006 01:27:07 -0600 From: Mark Butler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu> <4440A889.60307@middle.net> <444111B7.7050001@isi.edu> <4441CB88.1080803@middle.net> <4441D686.7090802@isi.edu> In-Reply-To: <4441D686.7090802@isi.edu> X-SA-Exim-Connect-IP: 67.137.150.193 X-SA-Exim-Mail-From: butlerm@middle.net X-Spam-Score: 0.6 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: tcpm@ietf.org Subject: [tcpm] Re: TCP port / service names 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="===============0893399981==" Errors-To: tcpm-bounces@ietf.org This is a multi-part message in MIME format. --===============0893399981== Content-Type: multipart/alternative; boundary="------------010602000503020601050006" This is a multi-part message in MIME format. --------------010602000503020601050006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joe Touch wrote: >A standard way is to run a single web server with multiple 'roots' and >to overload the DNS in the forward direction, i.e., multiple DNS names >that map to a single IP address. > > Running multiple web sites on the same web server is not equivalent to running multiple web server instances, as far as the host operating system is concerned. DNS based solutions do not solve the problem - there is a very long list of practical reasons why multiple independent web servers get installed on the same machine - often with completely independent code bases and supporting infrastructure. Suppose I install Samba or CUPS - each has its own administrative web service that is independent of the main web server installation. Should I have to get new IP addresses just for that? Or should HTTP be moved down into the kernel and a new kernel interface created just so that independent web services can share the same transport layer port or service id? >What you're trying to support is running multiple services with the same >name on all incoming ports, where the name is the same and the 'all >ports' is the same and the IP address is the same, but somehow something >is different. > > That is rather misleading. There is no mystery here - the only difference is that a name would be replaced by a (service type, service instance) pair. >That's not something TCP is designed to address. It's been hacked by >moving services from well-known ports to other ports; that's still >supported here. It can also be supported by overloading the meaning of >the service name. > > So what? The question ought to be: "what should it be designed to address?" >Since which of the two methods is used is a matter ONLY for the >consenting parties (i.e., the site running the web server and the URLs >it serves), why does it matter? > > All network protocols are practically speaking simple a matter of agreement between consenting parties. Why standardize anything, especially to fine levels of detail? The more particular answer here is a transport layer dispatch is simple and ULP independent. The fact that a solution works with HTTP under appropriate conditions does not conclude the general argument. >There are multiple ways of skinning this cat today: > - DNS overloading with multiple roots on a single server > - multiple IP addresses > - separate IP ports > >This solution isn't going to get rid of any of these necessarily, nor is >it intended to. > > - DNS overloading only works with HTTP with a shared instance - i.e. it doesn't address the instance selection problem at all. - multiple IP addresses are either impossible or expensive to come by in many cases, and surely assigning multiple addresses from the same subnet to the same host is at least as decidedly unnatural as using service instance identifiers as the transport level. - Requiring separate port numbers defeats the purpose of making an extension like this at all. You end up with a bizarre architectural mess actually worse than what we have now, because the old practices can never be deprecated. > > >>With proper DNS support (a la SRV) the URI issue would go away, but the >>service instance selection issue would remain and would require >>standardization on at least on a ULP by ULP basis. >> >> > >The doc discusses why DNS support for SRV records is a non-starter. I >may be given a DNS name by my ISP, but they don't give me permission to >insert a SRV record, nor do I suspect that's in the future. > > Changing a DNS server entry is much simpler than getting, configuring, and likely renumbering additional IP addresses. Most people do not use their ISP to host their DNS services anyway - they either use their registrar or run their own DNS server - something they can do with a single address. If I were an ISP providing DNS services however, I would much rather upgrade my DNS software to allow common web based DNS configuration than assign and configure new customer IP address blocks. The latter is a royal pain in the neck (speaking from experience here). > >It's to separate service from port. It's not to separate instance from >service or instance from port; separating service from port does NOT >preserve the status quo, even without addressing instance, either. > > Agreed. But that begs the question of what should an option like this _should_ do. Has the working group previously agreed to solve just that problem and disregard related ones?. >>Network layer tunneling is an enormously complex solution for such a >>simple problem, and would be borderline impossible to implement for >>publically available services in the contemporary environment. >> >> > >Similar assertions were once made about packet remapping (e.g., NAT), >and about IP forwarding at line rate. > > I am not talking about efficiency per se. Sure it can be done a good clip. However, if tunnelling were a simple solution to say the inbound NAT connection problem for publically available services (i.e. not VPNs) it would very likely have been done by now. One has to define and advertise a new embedded IP address space to the rest of the world. Proper support for that would require an extensive list of infrastructure changes that would be hard to implement and deploy. If would be much cleaner to go all the way and extend socket interfaces, name service protocols, and ULPs for variable length network addressing, say by constructing an extended network address in the form of a stack of IPv4 addresses, adding a new IP subheader to hold the full VLA, and substituting the "next hop" IPv4 address in the main header whenever switching from one IPv4 domain to another. NATs do the same thing already, just in a completely opaque and transport protocol / ULP hostile manner. >>>I.e., this is solving a problem that is NOT TCP's, which is why I don't >>>think it belongs at the transport layer >>> >>> >>> >>The popularity of NAT devices indicates that something that needs to be >>done at the transport layer. >> >> > >Actually, it indicates that whatever we do someone will try to undo it, >IMO. Even if we put instances in the service name, someone will decide >that everything behind a NAT ought to look like the same instance. > > I think that is unnecessarily cynical. The impetus to NAT for example, is as much an artifact of the fact that network addresses have to be administered across organizational boundaries with considerable transaction costs, as it is a consequence of the pending IPv4 address shortage. ISPs do not generally run NAT, their customers do to work around the ISPs. Unless one wants to run more than ~4 billion services of the same type behind the same address, I can't see the motivation. >>Failure to anticipate this real world >>requirement is *precisely* why NAT is such a ridiculous mess today. >> >> > >This mechanism can't fix what's broken with NATs, nor will instance numbers. > > I think I have given several good example of how instance numbers could be used to mitigate the most common problem with NATs - at least for connection oriented protocols. - Mark B. --------------010602000503020601050006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Joe Touch wrote:
A standard way is to run a single web server with multiple 'roots' and
to overload the DNS in the forward direction, i.e., multiple DNS names
that map to a single IP address.
Running multiple web sites on the same web server is not equivalent to running multiple web server instances, as far as the host operating system is concerned.  DNS based solutions do not solve the problem - there is a very long list of practical reasons why multiple independent web servers get installed on the same machine - often with completely independent code bases and supporting infrastructure.  Suppose I install Samba or CUPS - each has its own administrative web service that is independent of the main web server installation.  Should I have to get new IP addresses just for that?  Or should HTTP be moved down into the kernel and a new kernel interface created just so that independent web services can share the same transport layer port or service id?

What you're trying to support is running multiple services with the same
name on all incoming ports, where the name is the same and the 'all
ports' is the same and the IP address is the same, but somehow something
is different.
That is rather misleading.  There is no mystery here - the only difference is that a name would be replaced by a (service type, service instance) pair.  

That's not something TCP is designed to address. It's been hacked by
moving services from well-known ports to other ports; that's still
supported here. It can also be supported by overloading the meaning of
the service name.
So what?  The question ought to be: "what should it be designed to address?"
Since which of the two methods is used is a matter ONLY for the
consenting parties (i.e., the site running the web server and the URLs
it serves), why does it matter?
All network protocols are practically speaking simple a matter of agreement between consenting parties. Why standardize anything, especially to fine levels of detail?  The more particular answer here is a transport layer dispatch is simple and ULP independent.  The fact that a solution works with HTTP under appropriate conditions does not conclude the general argument.

There are multiple ways of skinning this cat today:
	- DNS overloading with multiple roots on a single server
	- multiple IP addresses
	- separate IP ports

This solution isn't going to get rid of any of these necessarily, nor is
it intended to.
- DNS overloading only works with HTTP with a shared instance - i.e. it doesn't address the instance selection problem at all.
- multiple IP addresses are either impossible or expensive to come by in many cases, and surely assigning multiple addresses from the same subnet to the same host is at least as decidedly unnatural as using service instance identifiers as the transport level.
- Requiring separate port numbers defeats the purpose of making an extension like this at all. You end up with a bizarre architectural mess actually worse than what we have now, because the old practices can never be deprecated.

  
With proper DNS support (a la SRV) the URI issue would go away, but the
service instance selection issue would remain and would require
standardization on at least on a ULP by ULP basis.
    

The doc discusses why DNS support for SRV records is a non-starter. I
may be given a DNS name by my ISP, but they don't give me permission to
insert a SRV record, nor do I suspect that's in the future.
Changing a DNS server entry is much simpler than getting, configuring, and likely renumbering additional IP addresses.  Most people do not use their ISP to host their DNS services anyway - they either use their registrar or run their own DNS server - something they can do with a single address.  If I were an ISP providing DNS services however, I would much rather upgrade my DNS software to allow common web based DNS configuration than assign and configure new customer IP address blocks.  The latter is a royal pain in the neck (speaking from experience here).


It's to separate service from port. It's not to separate instance from
service or instance from port; separating service from port does NOT
preserve the status quo, even without addressing instance, either.
Agreed.  But that begs the question of what should an option like this _should_ do.  Has the working group previously agreed to solve just that problem and disregard related ones?.  

Network layer tunneling is an enormously complex solution for such a
simple problem, and would be borderline impossible to implement for
publically available services in the contemporary environment.
    

Similar assertions were once made about packet remapping (e.g., NAT),
and about IP forwarding at line rate.
I am not talking about efficiency per se. Sure it can be done a good clip.  However, if tunnelling were a simple solution to say the inbound NAT connection problem for publically available services (i.e. not VPNs) it would very likely have been done by now.  One has to define and advertise a new embedded IP address space to the rest of the world. Proper support for that would require an extensive list of infrastructure changes that would be hard to implement and deploy.

If would be much cleaner to go all the way and extend socket interfaces, name service protocols, and ULPs for variable length network addressing, say by constructing an extended network address in the form of a stack of IPv4 addresses, adding a new IP subheader to hold the full VLA, and substituting the "next hop" IPv4 address in the main header whenever switching from one IPv4 domain to another.  NATs do the same thing already, just in a completely opaque and transport protocol / ULP hostile manner.



  

    

      
I.e., this is solving a problem that is NOT TCP's, which is why I don't
think it belongs at the transport layer
  
      

    

    
The popularity of NAT devices indicates that something that needs to be
done at the transport layer.
    

  

  

Actually, it indicates that whatever we do someone will try to undo it,
IMO. Even if we put instances in the service name, someone will decide
that everything behind a NAT ought to look like the same instance.
  



I think that is unnecessarily cynical.  The impetus to NAT for
example,  is as much an artifact of the fact that network addresses
have to be administered across organizational boundaries with
considerable transaction costs, as it is a consequence of the pending
IPv4 address shortage.  ISPs do not generally run NAT, their customers
do to work around the ISPs.  Unless one wants to run more than ~4
billion services of the same type behind the same address, I can't see
the motivation.





  

    
Failure to anticipate this real world
requirement is *precisely* why NAT is such a ridiculous mess today.  
    

  

  

This mechanism can't fix what's broken with NATs, nor will instance numbers.
  



I think I have given several good example of how instance numbers could
be used to mitigate the most common problem with NATs - at least for
connection oriented protocols.



 - Mark B.




--------------010602000503020601050006--


--===============0893399981==
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

--===============0893399981==--




From tcpm-bounces@ietf.org Sun Apr 16 19:29:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVGgB-0003c0-FZ; Sun, 16 Apr 2006 19:29:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVGgA-0003bv-DS
	for tcpm@ietf.org; Sun, 16 Apr 2006 19:29:18 -0400
Received: from mms2.broadcom.com ([216.31.210.18])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVGg7-0004rA-0X
	for tcpm@ietf.org; Sun, 16 Apr 2006 19:29:16 -0400
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom
	SMTP Relay (Email Firewall v6.2.0)); Sun, 16 Apr 2006 16:29:06 -0700
X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id
	C232F2AF; Sun, 16 Apr 2006 16:29:05 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by
	mail-irva-10.broadcom.com (Postfix) with ESMTP id 9F25D2AE; Sun, 16 Apr
	2006 16:29:05 -0700 (PDT)
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.5-GA) with ESMTP
	id DIA15407; Sun, 16 Apr 2006 16:29:04 -0700 (PDT)
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
	D223A20501; Sun, 16 Apr 2006 16:29:04 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] Re: TCP port / service names
Date: Sun, 16 Apr 2006 16:29:04 -0700
Message-ID: <54AD0F12E08D1541B826BE97C98F99F1025E47@NT-SJCA-0751.brcm.ad.broadcom.com>
Thread-Topic: [tcpm] Re: TCP port / service names
Thread-Index: AcZgSc6we5EBr80tSC2gXWwahJ0n3QBYkDvn
References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu>
From: "Caitlin Bestler" 
To: "Joe Touch" ,
	"Mark Butler" 
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041608; IFV=2.0.6,4.0-7; RPD=4.00.0004;
	RPDID=303030312E30413039303230312E34343432443146332E303030382D412D;
	ENG=IBF; TS=20060416232908; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006041608_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 685C0CC84I8787372-01-01
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
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]
Sent: Fri 4/14/2006 10:01 PM
To: Mark Butler
Cc: tcpm@ietf.org
Subject: [tcpm] Re: TCP port / service names
=20
Hi, Mark,

Mark Butler wrote:
>=20
> After a quick review of the TCP portnames draft, I have a couple of
> comments / questions:
>=20
> 1. I think the idea of accepting requests for a service on an =
arbitrary
> port number is an outstanding idea.
>=20
> 2. The nomenclature could use some clarification.  In particular the
> term "port name" in this context is confusing, when a port name can be
> distributed across an arbitrary number of numbered ports. Is there any
> particular reason why "service name" shouldn't be used instead?

The difference is that service names appear in many contexts - DNS SRV
records, IANA's keywords, etc. I.e., it's already backwards (service
names already mean port numbers).

That said, if there's a groundswell, we could rename this a "service
option" etc... throughout.

> 2. Is the intent that a port name be a service instance specifier in
> addition to a service type specifier?

The instance is completely specified by the connection, i.e., by the
socket pair already; having a further specifier would require the option
 in subsequent segments and would unnecessarily complicate all segment
processing, rather than just SYNs and SYN-ACKs. (at least if I
understand what you're suggesting)

----------

There are actually three layers of identification relevant here:
the class of the service ("http"), the instance of the server
("http://mydomainname.com/") and the instance of the
connection.

The last is clearly identified by the existing tuple. Distinguishing
between the first two is an interesting question. Certainly the
IP address of the destination is the preferred method, but there
are already complex schemes used by load-balancers to identify
a specific instance of a server based on information that is not=20
present in the SYN packet.

That is actually a very key point. The advantage of this proposal
over solutions like TCPMUX or the SDP portmapper is that it allows
more precise control over connection establishment without being
forced to parse payload. After all, a portmapper alone is sufficient
to allow any one IP address to offer 48K distinct services from a
potentially limitless set of possibilities, but that sort of mapping
would be hidden from gatekeepers, or at least hard to access.

The utility of having this information in the SYN packet is exactly
there is need for caution, however. There are only so many option
bytes available. It may be worthwhile to compare and contrast
versus other options that would be desirable to enhance connection
setup to see if they can blend with this or if they are in competion
for the last bytes available that won't interfere with existing =
equipment.

The most obvious one to me is that if you are going to define new
TCP options to enhance connection setup you should start with
a full Conneciton Cookie scheme, along the line of SCTP, rather
than having to make do with abusing the Initial Sequence Number.
Definitively knowing when a packet was a third handshake would
also be a major benefit for routing traffic when an IP address
has multiple processing elements implementing it.

Should the work group take this on by expanding the charter to
deal with "enhanced connection establishment" in general?


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



From tcpm-bounces@ietf.org Mon Apr 17 09:36:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVTth-0005cW-KK; Mon, 17 Apr 2006 09:36:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVTtg-0005cR-0Z
	for tcpm@ietf.org; Mon, 17 Apr 2006 09:36:08 -0400
Received: from mx2.grc.nasa.gov ([128.156.11.69])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVTtb-00061r-OD
	for tcpm@ietf.org; Mon, 17 Apr 2006 09:36:07 -0400
Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13])
	by mx2.grc.nasa.gov (Postfix) with ESMTP id 1A879C234
	for ; Mon, 17 Apr 2006 09:36:01 -0400 (EDT)
Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35])
	by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id
	k3HDa0tV020322; Mon, 17 Apr 2006 09:36:00 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id
	k3HDZx97007361; Mon, 17 Apr 2006 09:35:59 -0400 (EDT)
Received: from apataki.grc.nasa.gov ([127.0.0.1])
	by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 24480-12; Mon, 17 Apr 2006 09:35:53 -0400 (EDT)
Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])
	by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id
	k3HDZne2007229; Mon, 17 Apr 2006 09:35:49 -0400 (EDT)
Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)
	id 5D2384FC97; Mon, 17 Apr 2006 09:34:16 -0400 (EDT)
Date: Mon, 17 Apr 2006 09:34:16 -0400
From: Wesley Eddy 
To: Tim Shepard 
Subject: Re: [tcpm] TCP port names option ID
Message-ID: <20060417133416.GA13465@grc.nasa.gov>
References: 
Mime-Version: 1.0
In-Reply-To: 
User-Agent: Mutt/1.5.5.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: tcpm , Joe Touch 
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="===============1576942370=="
Errors-To: tcpm-bounces@ietf.org


--===============1576942370==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 15, 2006 at 11:21:51PM -0400, Tim Shepard wrote:
>=20
> What about the TCP Sack-Permitted Option which is 2 bytes long?  (And
> is very common on TCP SYN packets these days.)  If you add that to the
> list, we're down to 3 bytes for the NAMESTRING, which is only one byte
> more than the 16-bit port number that we started with.
>=20
> In any case, it seems if we go forward with this, it will be the last
> option we can add to the TCP SYN packet without breaking something, as
> we will have (in some cases) completely used up all space for a TCP
> option.  So before we go forward with this, we should make sure we
> really want to do that.
>=20

Or reconsider things like:
http://www.potaroo.net/ietf/all-ids/draft-kohler-tcpm-extopt-00.txt
or
http://www.potaroo.net/ietf/all-ids/draft-eddy-tcp-loo-03.txt

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFEQ5lXzBuYqbnj3IwRAoPXAKCKIz2e2ZYwNJ/9I3l5oeXEYk6XYgCdGlB3
M3GVYLfyXpDxy3MR0lCbEkA=
=BiOQ
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--


--===============1576942370==
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

--===============1576942370==--




From tcpm-bounces@ietf.org Mon Apr 17 11:16:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVVSn-0007CR-Gm; Mon, 17 Apr 2006 11:16:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVSm-0007CM-Hr
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:16:28 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVSj-0003Eb-UT
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:16:28 -0400
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 k3HFF5R15232;
	Mon, 17 Apr 2006 08:15:05 -0700 (PDT)
Message-ID: <4443B0F1.4000702@isi.edu>
Date: Mon, 17 Apr 2006 08:14:57 -0700
From: Joe Touch 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Mark Butler 
References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu>
	<4440A889.60307@middle.net> <444111B7.7050001@isi.edu>
	<4441CB88.1080803@middle.net> <4441D686.7090802@isi.edu>
	<4441F1CB.1080001@middle.net>
In-Reply-To: <4441F1CB.1080001@middle.net>
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: 5fb88b8381f3896aeacc5a021513237b
Cc: tcpm@ietf.org
Subject: [tcpm] Re: TCP port / service names
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



Mark Butler wrote:
> Joe Touch wrote:
>> A standard way is to run a single web server with multiple 'roots' and
>> to overload the DNS in the forward direction, i.e., multiple DNS names
>> that map to a single IP address.
>>   
> Running multiple web sites on the same web server is not equivalent to
> running multiple web server instances, as far as the host operating
> system is concerned.  DNS based solutions do not solve the problem -
> there is a very long list of practical reasons why multiple independent
> web servers get installed on the same machine - often with completely
> independent code bases and supporting infrastructure.  Suppose I install
> Samba or CUPS - each has its own administrative web service that is
> independent of the main web server installation.  Should I have to get
> new IP addresses just for that?  Or should HTTP be moved down into the
> kernel and a new kernel interface created just so that independent web
> services can share the same transport layer port or service id?

Regardless of how it's supported, the app/user needs to know something
in advance to reach those. I.e., by adding multiple instances on the
same machine you're creating a multiple-virtual host issue.

Using multiple IP addresses is one way to solve this; so is using
specific ports. However, the last solution you suggest is probably the
best - each server should register with the primary server software on
the system; this doesn't require a new kernel interface so much as a new
application interface where virtual servers can register on-the-fly.
Let's call this "dynamic sub-server registration" (DSSR), so I can refer
to it later in this post...

The most important observation, however, is that this is NOT a transport
layer problem.

>> What you're trying to support is running multiple services with the same
>> name on all incoming ports, where the name is the same and the 'all
>> ports' is the same and the IP address is the same, but somehow something
>> is different.
>>   
> That is rather misleading.  There is no mystery here - the only
> difference is that a name would be replaced by a (service type, service
> instance) pair. 

The mystery is why a transport protocol should need to know what an
'instance' is as different from either the service type or host address.

>> That's not something TCP is designed to address. It's been hacked by
>> moving services from well-known ports to other ports; that's still
>> supported here. It can also be supported by overloading the meaning of
>> the service name.
>>   
> So what?  The question ought to be: "what should it be designed to address?"

Perhaps the question ought to be "why can't you get another address?" or
"why aren't these all running off of one service and demuxing there?"
There are many good questions, the key is which one to address. ;-)

>> Since which of the two methods is used is a matter ONLY for the
>> consenting parties (i.e., the site running the web server and the URLs
>> it serves), why does it matter?
>>   
> All network protocols are practically speaking simple a matter of
> agreement between consenting parties. Why standardize anything,
> especially to fine levels of detail?  The more particular answer here is
> a transport layer dispatch is simple and ULP independent.  The fact that
> a solution works with HTTP under appropriate conditions does not
> conclude the general argument.

It does beg the question: what is the goal of multiple instances?

There are two reasons:
	- coordinate apps that should be coordinating at the app
	layer but currently do not (e.g., HTTP with DSSR)

	- emulate virtual hosts without additional IP addresses

Those are insufficient reasons, IMO. If there are others, they should be
considered, but so far the reasons to support multiple instances are
reminiscent of the reasons for NATs: because the current architecture
isn't convenient, even though the solution isn't part of the current
architecture.

This document is intended to be consistent with the current
architecture, not to solve these new problems. An 'instance option'
could do that in two bytes, which is roughly what it would take anyway.

>> There are multiple ways of skinning this cat today:
>> 	- DNS overloading with multiple roots on a single server
>> 	- multiple IP addresses
>> 	- separate IP ports
>>
>> This solution isn't going to get rid of any of these necessarily, nor is
>> it intended to.
>>   
> - DNS overloading only works with HTTP with a shared instance - i.e. it
> doesn't address the instance selection problem at all.

It lets the solution be solved at the app layer, albeit assuming DSSR as
noted above.

> - multiple IP addresses are either impossible or expensive to come by in
> many cases, and surely assigning multiple addresses from the same subnet
> to the same host is at least as decidedly unnatural as using service
> instance identifiers as the transport level.

It depends on what you're doing. If these are all web control interfaces
for different services on the same host, then they ought to sit on the
same IP address. But then you're *really* arguing that portname "DNS"
ought to take both protocol=DNS and protocol=HTTP to allow (e.g.) HTTP
configuration of the DNS server.

That really begs the issue of DSSR; one example might be:
	http://yourhost:portname1/portname2

Where portname1 is the NAMESTRING of the portname option, and portname2
is just the front of the URL and used by DSSR to demux the request to
the right sub-server.

---

Side-note: the use of multiple web servers to control services on a
machine is like running multiple SNMP servers, one for each host
interface. There's no real reason to do this.

> - Requiring separate port numbers defeats the purpose of making an
> extension like this at all. You end up with a bizarre architectural mess
> actually worse than what we have now, because the old practices can
> never be deprecated.

The 'old practice' is to using port numbers to indicate service
instances too. DSSR is a way to avoid that, and should be encouraged,
perhaps by NOT supporting this in a new option.

HOWEVER, as noted above, if you want an option for service instance,
propose that separately. It ought NOT be in this one, IMO.

>>> With proper DNS support (a la SRV) the URI issue would go away, but the
>>> service instance selection issue would remain and would require
>>> standardization on at least on a ULP by ULP basis.
>>>     
>>
>> The doc discusses why DNS support for SRV records is a non-starter. I
>> may be given a DNS name by my ISP, but they don't give me permission to
>> insert a SRV record, nor do I suspect that's in the future.
>>   
> Changing a DNS server entry is much simpler than getting, configuring,
> and likely renumbering additional IP addresses.  Most people do not use
> their ISP to host their DNS services anyway - they either use their
> registrar or run their own DNS server - something they can do with a
> single address.  

Most people don't manage their address in a DNS entry anywhere. They're
dependent on what their ISP already provides (or doesn't).

> If I were an ISP providing DNS services however, I
> would much rather upgrade my DNS software to allow common web based DNS
> configuration than assign and configure new customer IP address blocks. 
> The latter is a royal pain in the neck (speaking from experience here).

Most ISPs will decide that users CAN'T register certain services,
notably ones they think they can charge commercial rates for (e.g., web
servers, mail servers, etc.).

>> It's to separate service from port. It's not to separate instance from
>> service or instance from port; separating service from port does NOT
>> preserve the status quo, even without addressing instance, either.
>>   
> Agreed.  But that begs the question of what should an option like this
> _should_ do.  Has the working group previously agreed to solve just that
> problem and disregard related ones?. 

This isn't a WG item; it would be useful to review the discussion on the
IETF list to see where this came from and what problem it solves, if
that isn't already sufficiently explained in the document itself.

>>> Network layer tunneling is an enormously complex solution for such a
>>> simple problem, and would be borderline impossible to implement for
>>> publically available services in the contemporary environment.
>>
>> Similar assertions were once made about packet remapping (e.g., NAT),
>> and about IP forwarding at line rate.
>>   
> I am not talking about efficiency per se. Sure it can be done a good
> clip.  However, if tunnelling were a simple solution to say the inbound
> NAT connection problem for publically available services (i.e. not VPNs)
> it would very likely have been done by now. 

That's basically where HIP and SHIM6 are heading; they just don't 'call'
what they do tunneling.

> One has to define and
> advertise a new embedded IP address space to the rest of the world.

Just as one would have to advertise the service instance numbers.

> Proper support for that would require an extensive list of
> infrastructure changes that would be hard to implement and deploy.

Again, why isn't this the case for service instance numbers? How do you
know the service instance for your DNS configuration server, vs. the one
that monitors your printers software, vs. the one used to configure your
mail server?

> If would be much cleaner to go all the way and extend socket interfaces,
> name service protocols, and ULPs for variable length network addressing,
> say by constructing an extended network address in the form of a stack
> of IPv4 addresses, adding a new IP subheader to hold the full VLA, and
> substituting the "next hop" IPv4 address in the main header whenever
> switching from one IPv4 domain to another.  NATs do the same thing
> already, just in a completely opaque and transport protocol / ULP
> hostile manner.

Perhaps, but service instance IDs are equally opaque.

>>>> I.e., this is solving a problem that is NOT TCP's, which is why I don't
>>>> think it belongs at the transport layer
>>>>   
>>>>       
>>> The popularity of NAT devices indicates that something that needs to be
>>> done at the transport layer.
>>>     
>>
>> Actually, it indicates that whatever we do someone will try to undo it,
>> IMO. Even if we put instances in the service name, someone will decide
>> that everything behind a NAT ought to look like the same instance.
>>   
> I think that is unnecessarily cynical.  The impetus to NAT for example, 
> is as much an artifact of the fact that network addresses have to be
> administered across organizational boundaries with considerable
> transaction costs, as it is a consequence of the pending IPv4 address
> shortage.  ISPs do not generally run NAT, their customers do to work
> around the ISPs.

ISPs include cable companies, telcos, etc. And many provide service only
behind NATs.

> Unless one wants to run more than ~4 billion services
> of the same type behind the same address, I can't see the motivation.

The motivation for ISPs to defeat this is their charging model - which
is one of the reasons they promoted NATs in the first place. It's easier
to serve addresses behind a device you CAN'T run a server on than to
monitor who runs a server so you can charge them more.

>>> Failure to anticipate this real world
>>> requirement is *precisely* why NAT is such a ridiculous mess today.  
>>>     
>> This mechanism can't fix what's broken with NATs, nor will instance numbers.
>>   
> I think I have given several good example of how instance numbers could
> be used to mitigate the most common problem with NATs - at least for
> connection oriented protocols.
> 
>  - Mark B.

They may mitigate some things, but they require coordination of the
service instance numbers, which puts us back at square one architecturally.

I think the way to proceed here is to have a separate option for service
instances; they have nothing to do with portnames (or service names) per se.

Joe

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



From tcpm-bounces@ietf.org Mon Apr 17 11:17:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVVTN-0007h8-Ty; Mon, 17 Apr 2006 11:17:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVTM-0007h3-Hn
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:17:04 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVTL-0003Jm-6W
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:17:04 -0400
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 k3HFGhR15906;
	Mon, 17 Apr 2006 08:16:43 -0700 (PDT)
Message-ID: <4443B153.8060400@isi.edu>
Date: Mon, 17 Apr 2006 08:16:35 -0700
From: Joe Touch 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Caitlin Bestler 
Subject: Re: [tcpm] Re: TCP port / service names
References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu>
	<54AD0F12E08D1541B826BE97C98F99F1025E47@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F1025E47@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: 7bac9cb154eb5790ae3b2913587a40de
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:
...
> Should the work group take this on by expanding the charter to
> deal with "enhanced connection establishment" in general?

IMO, that's probably a lot broader than 'minor maintenance'.

Joe

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



From tcpm-bounces@ietf.org Mon Apr 17 11:19:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVVVO-0000IB-DT; Mon, 17 Apr 2006 11:19:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVVN-0000I6-0V
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:19:09 -0400
Received: from vapor.isi.edu ([128.9.64.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVVL-0003UF-Lk
	for tcpm@ietf.org; Mon, 17 Apr 2006 11:19:08 -0400
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 k3HFIdR16234;
	Mon, 17 Apr 2006 08:18:39 -0700 (PDT)
Message-ID: <4443B1C6.6000400@isi.edu>
Date: Mon, 17 Apr 2006 08:18:30 -0700
From: Joe Touch 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: weddy@grc.nasa.gov
Subject: Re: [tcpm] TCP port names option ID
References:  <20060417133416.GA13465@grc.nasa.gov>
In-Reply-To: <20060417133416.GA13465@grc.nasa.gov>
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: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: tcpm , Tim Shepard 
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




Wesley Eddy wrote:
> On Sat, Apr 15, 2006 at 11:21:51PM -0400, Tim Shepard wrote:
>> What about the TCP Sack-Permitted Option which is 2 bytes long?  (And
>> is very common on TCP SYN packets these days.)  If you add that to the
>> list, we're down to 3 bytes for the NAMESTRING, which is only one byte
>> more than the 16-bit port number that we started with.
>>
>> In any case, it seems if we go forward with this, it will be the last
>> option we can add to the TCP SYN packet without breaking something, as
>> we will have (in some cases) completely used up all space for a TCP
>> option.  So before we go forward with this, we should make sure we
>> really want to do that.
>>
> 
> Or reconsider things like:
> http://www.potaroo.net/ietf/all-ids/draft-kohler-tcpm-extopt-00.txt
> or
> http://www.potaroo.net/ietf/all-ids/draft-eddy-tcp-loo-03.txt

Those might be useful, but as portnames notes, this is an issue ONLY for
SYNs containing the TCP/MD5 or other TCP-level authentication options.

IF we move forward with TCP-level security for anything other than
routing protocols as a stop-gap until IPsec is used, perhaps, but only
in that case, IMO.

Joe


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



From tcpm-bounces@ietf.org Mon Apr 17 14:57:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVYuy-0006Fj-Lc; Mon, 17 Apr 2006 14:57:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVYux-0006Fe-9c
	for tcpm@ietf.org; Mon, 17 Apr 2006 14:57:47 -0400
Received: from [166.70.100.114] (helo=mail.middle.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVYuw-0006qS-6W
	for tcpm@ietf.org; Mon, 17 Apr 2006 14:57:47 -0400
Received: from citius ([67.137.150.193] helo=[192.168.0.61])
	by mail.middle.net with esmtp (Exim 4.24)
	id 1FVYuv-0006I2-V3; Mon, 17 Apr 2006 12:57:24 -0600
Message-ID: <4443E531.6070401@middle.net>
Date: Mon, 17 Apr 2006 12:57:53 -0600
From: Mark Butler 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch 
References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu>
	<4440A889.60307@middle.net> <444111B7.7050001@isi.edu>
	<4441CB88.1080803@middle.net> <4441D686.7090802@isi.edu>
	<4441F1CB.1080001@middle.net> <4443B0F1.4000702@isi.edu>
In-Reply-To: <4443B0F1.4000702@isi.edu>
X-SA-Exim-Connect-IP: 67.137.150.193
X-SA-Exim-Mail-From: butlerm@middle.net
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 303e29529f30c23b95ea718537067fd5
Cc: tcpm@ietf.org
Subject: [tcpm] Re: TCP port / service names
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="===============1410211860=="
Errors-To: tcpm-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1410211860==
Content-Type: multipart/alternative;
	boundary="------------010203010006000903080801"

This is a multi-part message in MIME format.
--------------010203010006000903080801
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Joe Touch wrote:

>  
>
> <>Regardless of how it's supported, the app/user needs to know something 

> <>in advance to reach those. I.e., by adding multiple instances on the
> same machine you're creating a multiple-virtual host issue.
>
> Using multiple IP addresses is one way to solve this; so is using
> specific ports. However, the last solution you suggest is probably the
> best - each server should register with the primary server software on
> the system; this doesn't require a new kernel interface so much as a new
> application interface where virtual servers can register on-the-fly.
> Let's call this "dynamic sub-server registration" (DSSR), so I can refer
> to it later in this post...
>
> The most important observation, however, is that this is NOT a transport
> layer problem.
>
This is an important issue - see below.

>The mystery is why a transport protocol should need to know what an
>'instance' is as different from either the service type or host address.
>  
>
It is no more mysterious than a transport protocol needing to have the 
concept of service type at all.  TCP currently makes no such distinction 
- the concept of service instance simply flows from introducing service 
type semantics where previously there were none.  The only way to avoid 
the problem is to say that this name string is a dispatch specifier with 
arbitrary semantics. 

No matter what is done there has to be a quasi standard way of binding a 
higher level application to a transport protocol endpoint.  That is not 
strictly speaking a TCP or transport protocol function at all, it is 
just traditionally implemented in the transport layer. The problems are 
sufficiently independent that the semantics of name strings could be a 
completely independent specification, possibly even a layer unto itself, 
in the same sense that say ARP is an independent layer.

>
>It depends on what you're doing. If these are all web control interfaces
>for different services on the same host, then they ought to sit on the
>same IP address. But then you're *really* arguing that portname "DNS"
>ought to take both protocol=DNS and protocol=HTTP to allow (e.g.) HTTP
>configuration of the DNS server.
>  
>
Having two protocols like that is unnecessary, cumbersome, and 
confusing.  It doesn't matter what you are configuring (at least not to 
anything at the transport or HTTP layers).  "www1" or "www2" is a more 
accurate reflection of what is going on, except split into two numeric 
fields - e.g. service type=HTTP, server instance=2.

>---
>
>Side-note: the use of multiple web servers to control services on a
>machine is like running multiple SNMP servers, one for each host
>interface. There's no real reason to do this.
>  
>
Doing SNMP properly on a general purpose operating system requires 
something comparable to DSSR. As far as there are no established 
standards for doing that - i.e. distributing the SNMP "name" space 
across multiple server processes.


>
>The 'old practice' is to using port numbers to indicate service
>instances too. DSSR is a way to avoid that, and should be encouraged,
>perhaps by NOT supporting this in a new option.
>  
>
I like the idea of DSSR internal to a host, for ULPs that can support 
it.  However, DSSR on a NAT is the equivalent of running an application 
layer proxy for each ULP, generally on an underpowered external box that 
is difficult to upgrade.

>
>  
>
>Most people don't manage their address in a DNS entry anywhere. They're
>dependent on what their ISP already provides (or doesn't).
>  
>
Every IM or VoIP network has some sort of name service. The main 
practical difference is that most such systems use dynamic registration 
(especially of the current IP address or 'locator' to be used for a 
particular name), where public DNS generally has static entries.  
Neither the user nor the ISP needs to do anything.

> <>
> This isn't a WG item; it would be useful to review the discussion on the
> IETF list to see where this came from and what problem it solves, if
> that isn't already sufficiently explained in the document itself.

Fair enough.  My point is that the two problem are closely associated 
because of the way ports are currently used, and this is a particular 
point of concern if new APIs are going to be established.  Socket APIs 
should be transport protocol independent as much as possible.

> <>
>
>>I am not talking about efficiency per se. Sure it can be done a good
>>clip.  However, if tunnelling were a simple solution to say the inbound
>>NAT connection problem for publically available services (i.e. not VPNs)
>>it would very likely have been done by now. 
>>    
>>
>
>That's basically where HIP and SHIM6 are heading; they just don't 'call'
>what they do tunneling.
>  
>
The SHIM6 people are working on solving the NAT problem?  I thought they 
were working on solving the multihoming problem, in a manner similar to 
SCTP except implemented in layer 3.  I thought they concluded that a 
ULID was going to be one of the existing IP addresses of the system, 
i.e. neither to establish another global layer of address indirection, 
nor to extend the existing address space.

>  
>
>>One has to define and
>>advertise a new embedded IP address space to the rest of the world.
>>    
>>
>
>Just as one would have to advertise the service instance numbers.
>  
>
The real problem is not advertising -  it is the fact that a tunneled 
address space is fundamentally dissimilar to an extended address space.  
You cannot use tunnels to replace service instances  without dynamically 
numbering or renumbering everything on at least one end on a connection 
by connection basis.  That is what Network Address Translation attempts 
to do already - adding a tunnel is superfluous.

>  
>
>> <>Again, why isn't this the case for service instance numbers? How do you
>> know the service instance for your DNS configuration server, vs. the one
>> that monitors your printers software, vs. the one used to configure your
>> mail server?
>
Current software generally has some non-default port number that you 
must include in the URL. An instance number could be included the same 
way, although registering the instance number with a local name service 
would be the proper way to solve the problem.  The difference between 
that and "DSSR" is that DSSR requires ULP specific name and dispatch 
services, where instance number registration is ULP independent, just 
like SRV.

>  
>
>>If would be much cleaner to go all the way and extend socket interfaces,
>>name service protocols, and ULPs for variable length network addressing,
>>say by constructing an extended network address in the form of a stack
>>of IPv4 addresses, adding a new IP subheader to hold the full VLA, and
>>substituting the "next hop" IPv4 address in the main header whenever
>>switching from one IPv4 domain to another.  NATs do the same thing
>>already, just in a completely opaque and transport protocol / ULP
>>hostile manner.
>>    
>>
>
>Perhaps, but service instance IDs are equally opaque.
>  
>
No more opaque than telephone extension numbers.  Service instance IDs 
would be statically assigned.  The major problem with NAT is that 
externally visible port numbers are not only not statically assigned (in 
general), they are not readily available.

>  
>
>
>ISPs include cable companies, telcos, etc. And many provide service only
>behind NATs.
>  
>
They are certainly in a small minority.  .The main reason for an ISP to 
deal with the hassles of running a large customer base behind NAT would 
be a severe address shortage. I can see that condition prevailing for 
various practical reasons in parts of Asia, but in general I don't see 
ISPs having any problem getting at least one address per customer.  DHCP 
is one thing, but NAT creates more problems than it solves at the ISP 
level - especially in terms of customer traceability. 

>  
>
>>Unless one wants to run more than ~4 billion services
>>of the same type behind the same address, I can't see the motivation.
>>    
>>
>
>The motivation for ISPs to defeat this is their charging model - which
>is one of the reasons they promoted NATs in the first place. It's easier
>to serve addresses behind a device you CAN'T run a server on than to
>monitor who runs a server so you can charge them more.
>
>  
>
No amount of architecture can prevent ISPs from doing stupid things, 
unfortunately.  They are the literal "men in the middle" after all.  
Someday, unfortunately, goverment regulation will likely be required to 
set limits on what an ISP can and cannot do in terms of interfering with 
their customer's traffic.  Bills are already before Congress to give the 
FCC explicit authority to do this in the U.S..  So far just the ad hoc 
threat of more extensive regulation seems to be helping.

Promoting NAT is not an effective way to keep users from running 
"servers".  The common method is to block incoming SYN packets - a 
classic example of ISP interference of the type that should be outlawed, 
interference that doesn't stop much more resource intensive P2P use, NAT 
or no NAT,  at all.


>They may mitigate some things, but they require coordination of the
>service instance numbers, which puts us back at square one architecturally.
>  
>
I would say that it lays the foundation for incrementally deployable 
changes that have the potential to solve the major problems with NAT.

>I think the way to proceed here is to have a separate option for service
>instances; they have nothing to do with portnames (or service names) per se.
>  
>
That is certainly reasonable.

 - Mark B.


--------------010203010006000903080801
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Joe Touch wrote:


  
  

<>Regardless of how it's supported, the app/user needs to know
something 


<>in advance
to reach those. I.e., by adding multiple instances on the

same machine you're creating a multiple-virtual host issue.

  

Using multiple IP addresses is one way to solve this; so is using

specific ports. However, the last solution you suggest is probably the

best - each server should register with the primary server software on

the system; this doesn't require a new kernel interface so much as a new

application interface where virtual servers can register on-the-fly.

Let's call this "dynamic sub-server registration" (DSSR), so I can refer

to it later in this post...

  

The most important observation, however, is that this is NOT a transport

layer problem.

  

  

This is an important issue - see below.



  

  
The mystery is why a transport protocol should need to know what an
'instance' is as different from either the service type or host address.
  



It is no more mysterious than a transport protocol needing to have the
concept of service type at all.  TCP currently makes no such
distinction - the concept of service instance simply flows from
introducing service type semantics where previously there were none. 
The only way to avoid the problem is to say that this name string is a
dispatch specifier with arbitrary semantics.  



No matter what is done there has to be a quasi standard way of binding
a higher level application to a transport protocol endpoint.  That is
not strictly speaking a TCP or transport protocol function at all, it
is just traditionally implemented in the transport layer. The problems
are sufficiently independent that the semantics of name strings could
be a completely independent specification, possibly even a layer unto
itself, in the same sense that say ARP is an independent layer.



  

It depends on what you're doing. If these are all web control interfaces
for different services on the same host, then they ought to sit on the
same IP address. But then you're *really* arguing that portname "DNS"
ought to take both protocol=DNS and protocol=HTTP to allow (e.g.) HTTP
configuration of the DNS server.
  



Having two protocols like that is unnecessary, cumbersome, and
confusing.  It doesn't matter what you are configuring (at least not to
anything at the transport or HTTP layers).  "www1" or "www2" is a more
accurate reflection of what is going on, except split into two numeric
fields - e.g. service type=HTTP, server instance=2.





  
---

Side-note: the use of multiple web servers to control services on a
machine is like running multiple SNMP servers, one for each host
interface. There's no real reason to do this.
  



Doing SNMP properly on a general purpose operating system requires
something comparable to DSSR. As far as there are no established
standards for doing that - i.e. distributing the SNMP "name" space
across multiple server processes.







  

The 'old practice' is to using port numbers to indicate service
instances too. DSSR is a way to avoid that, and should be encouraged,
perhaps by NOT supporting this in a new option.
  



I like the idea of DSSR internal to a host, for ULPs that can support
it.  However, DSSR on a NAT is the equivalent of running an application
layer proxy for each ULP, generally on an underpowered external box
that is difficult to upgrade.





  

  

  
Most people don't manage their address in a DNS entry anywhere. They're
dependent on what their ISP already provides (or doesn't).
  



Every IM or VoIP network has some sort of name service. The main
practical difference is that most such systems use dynamic registration
(especially of the current IP address or 'locator' to be used for a
particular name), where public DNS generally has static entries. 
Neither the user nor the ISP needs to do anything. 




<>

This isn't a WG item; it would be useful to review the discussion on the

IETF list to see where this came from and what problem it solves, if

that isn't already sufficiently explained in the document itself.

  

Fair enough.  My point is that the two problem are closely associated
because of the way ports are currently used, and this is a particular
point of concern if new APIs are going to be established.  Socket APIs
should be transport protocol independent as much as possible.




<> 

  
  

    
I am not talking about efficiency per se. Sure it can be done a good
clip.  However, if tunnelling were a simple solution to say the inbound
NAT connection problem for publically available services (i.e. not VPNs)
it would very likely have been done by now. 
    

  

  

That's basically where HIP and SHIM6 are heading; they just don't 'call'
what they do tunneling.
  



The SHIM6 people are working on solving the NAT problem?  I thought
they were working on solving the multihoming problem, in a manner
similar to SCTP except implemented in layer 3.  I thought they
concluded that a ULID was going to be one of the existing IP addresses
of the system, i.e. neither to establish another global layer of
address indirection, nor to extend the existing address space.





  
  

  

    
One has to define and
advertise a new embedded IP address space to the rest of the world.
    

  

  

Just as one would have to advertise the service instance numbers.
  



The real problem is not advertising -  it is the fact that a tunneled
address space is fundamentally dissimilar to an extended address
space.  You cannot use tunnels to replace service instances  without
dynamically numbering or renumbering everything on at least one end on
a connection by connection basis.  That is what Network Address
Translation attempts to do already - adding a tunnel is superfluous.





  
  

  
<>Again, why isn't this the case for service
instance numbers? How do you

know the service instance for your DNS configuration server, vs. the one

that monitors your printers software, vs. the one used to configure your

mail server?

    



Current software generally has some non-default port number that you
must include in the URL. An instance number could be included the same
way, although registering the instance number with a local name service
would be the proper way to solve the problem.  The difference between
that and "DSSR" is that DSSR requires ULP specific name and dispatch
services, where instance number registration is ULP independent, just
like SRV.



  
  

  

    
If would be much cleaner to go all the way and extend socket interfaces,
name service protocols, and ULPs for variable length network addressing,
say by constructing an extended network address in the form of a stack
of IPv4 addresses, adding a new IP subheader to hold the full VLA, and
substituting the "next hop" IPv4 address in the main header whenever
switching from one IPv4 domain to another.  NATs do the same thing
already, just in a completely opaque and transport protocol / ULP
hostile manner.
    

  

  

Perhaps, but service instance IDs are equally opaque.
  



No more opaque than telephone extension numbers.  Service instance IDs
would be statically assigned.  The major problem with NAT is that
externally visible port numbers are not only not statically assigned
(in general), they are not readily available.





  
  

  

ISPs include cable companies, telcos, etc. And many provide service only
behind NATs.
  



They are certainly in a small minority.  .The main reason for an ISP to
deal with the hassles of running a large customer base behind NAT would
be a severe address shortage. I can see that condition prevailing for
various practical reasons in parts of Asia, but in general I don't see
ISPs having any problem getting at least one address per customer. 
DHCP is one thing, but NAT creates more problems than it solves at the
ISP level - especially in terms of customer traceability.  





  
  

  

    
Unless one wants to run more than ~4 billion services
of the same type behind the same address, I can't see the motivation.
    

  

  

The motivation for ISPs to defeat this is their charging model - which
is one of the reasons they promoted NATs in the first place. It's easier
to serve addresses behind a device you CAN'T run a server on than to
monitor who runs a server so you can charge them more.

  



No amount of architecture can prevent ISPs from doing stupid things,
unfortunately.  They are the literal "men in the middle" after all. 
Someday, unfortunately, goverment regulation will likely be required to
set limits on what an ISP can and cannot do in terms of interfering
with their customer's traffic.  Bills are already before Congress to
give the FCC explicit authority to do this in the U.S..  So far just
the ad hoc threat of more extensive regulation seems to be helping.



Promoting NAT is not an effective way to keep users from running
"servers".  The common method is to block incoming SYN packets - a
classic example of ISP interference of the type that should be
outlawed, interference that doesn't stop much more resource intensive
P2P use, NAT or no NAT,  at all.







  

  
They may mitigate some things, but they require coordination of the
service instance numbers, which puts us back at square one architecturally.
  



I would say that it lays the foundation for incrementally deployable
changes that have the potential to solve the major problems with NAT.



  
I think the way to proceed here is to have a separate option for service
instances; they have nothing to do with portnames (or service names) per se.
  



That is certainly reasonable.



 - Mark B.






--------------010203010006000903080801--


--===============1410211860==
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

--===============1410211860==--




From tcpm-bounces@ietf.org Mon Apr 17 16:18:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVaBB-0006hB-IB; Mon, 17 Apr 2006 16:18:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVaBA-0006h6-Ez
	for tcpm@ietf.org; Mon, 17 Apr 2006 16:18:36 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVaB8-00030x-Vh
	for tcpm@ietf.org; Mon, 17 Apr 2006 16:18:36 -0400
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 k3HKI3C17729;
	Mon, 17 Apr 2006 13:18:03 -0700 (PDT)
Message-ID: <4443F79D.3030105@isi.edu>
Date: Mon, 17 Apr 2006 13:16:29 -0700
From: Joe Touch 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Mark Butler 
References: <444048B7.5060306@middle.net> <44407E0F.404@isi.edu>
	<4440A889.60307@middle.net> <444111B7.7050001@isi.edu>
	<4441CB88.1080803@middle.net> <4441D686.7090802@isi.edu>
	<4441F1CB.1080001@middle.net> <4443B0F1.4000702@isi.edu>
	<4443E531.6070401@middle.net>
In-Reply-To: <4443E531.6070401@middle.net>
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: 6ba8aaf827dcb437101951262f69b3de
Cc: tcpm@ietf.org
Subject: [tcpm] Re: TCP port / service names
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

Mark Butler wrote:
z...
> I like the idea of DSSR internal to a host, for ULPs that can support
> it.  However, DSSR on a NAT is the equivalent of running an application
> layer proxy for each ULP, generally on an underpowered external box that
> is difficult to upgrade.

Isn't that basically where BEHAVE is going?

(or a WG precursor thereto?)

>> This isn't a WG item; it would be useful to review the discussion on the
>> IETF list to see where this came from and what problem it solves, if
>> that isn't already sufficiently explained in the document itself.
> Fair enough.  My point is that the two problem are closely associated
> because of the way ports are currently used, and this is a particular
> point of concern if new APIs are going to be established.  Socket APIs
> should be transport protocol independent as much as possible.
> 
>> <>
>>> I am not talking about efficiency per se. Sure it can be done a good
>>> clip.  However, if tunnelling were a simple solution to say the inbound
>>> NAT connection problem for publically available services (i.e. not VPNs)
>>> it would very likely have been done by now. 
>>>     
>>
>> That's basically where HIP and SHIM6 are heading; they just don't 'call'
>> what they do tunneling.
>
> The SHIM6 people are working on solving the NAT problem?  I thought they
> were working on solving the multihoming problem, in a manner similar to
> SCTP except implemented in layer 3.  I thought they concluded that a
> ULID was going to be one of the existing IP addresses of the system,
> i.e. neither to establish another global layer of address indirection,
> nor to extend the existing address space.

I'm thinking more of how their solutions include tunneling-like
services; having SHIM6 terminate at the NAT would support the
multihoming behind the NAT.

...
>>> <>Again, why isn't this the case for service instance numbers? How do you
>>> know the service instance for your DNS configuration server, vs. the one
>>> that monitors your printers software, vs. the one used to configure your
>>> mail server?
> Current software generally has some non-default port number that you
> must include in the URL. An instance number could be included the same
> way, although registering the instance number with a local name service
> would be the proper way to solve the problem.  The difference between
> that and "DSSR" is that DSSR requires ULP specific name and dispatch
> services, where instance number registration is ULP independent, just
> like SRV.

How does the source know it wants instance 2 vs. instance 3?

Right now, it knows because it uses a different port number. However,
the service number space needs to be fairly large to avoid collisions
(i.e., as is done in the port number space by picking from among 'large'
values).

>>> If would be much cleaner to go all the way and extend socket interfaces,
>>> name service protocols, and ULPs for variable length network addressing,
>>> say by constructing an extended network address in the form of a stack
>>> of IPv4 addresses, adding a new IP subheader to hold the full VLA, and
>>> substituting the "next hop" IPv4 address in the main header whenever
>>> switching from one IPv4 domain to another.  NATs do the same thing
>>> already, just in a completely opaque and transport protocol / ULP
>>> hostile manner.
>>
>> Perhaps, but service instance IDs are equally opaque.
>>   
> No more opaque than telephone extension numbers.

Those are a good example of extending the address space using in-band
data. As automated local exchanges have become more prevalent, the use
of extension numbers has decreased over the years.

I.e., the 'right' way to solve that problem was to use the phone number
space. While I agree that might not be a viable alternative for TCP,
that is only because we're in IPv4. Further support at the transport
layer for the lack of IP addresses is a bad idea.

> Service instance IDs
> would be statically assigned.  The major problem with NAT is that
> externally visible port numbers are not only not statically assigned (in
> general), they are not readily available.
> 
>> ISPs include cable companies, telcos, etc. And many provide service only
>> behind NATs.
>>   
> They are certainly in a small minority. 

I'm on Verizon DSL. My modem is a NAT - I didn't ask for it; that's what
I get.

Anybody else want to report on experience with their "minority" telco or
cable company?

> The main reason for an ISP to
> deal with the hassles of running a large customer base behind NAT would
> be a severe address shortage.

1. address shortage
2. limiting services users can run
3. using commodity boxes for multiple hosts, e.g., via wireless
	(even if they have multiple addresses, wireless boxes support
	NAT more than they support managing multiple real addresses)

Depending on who you ask, you'll get a different answer, of course. I
believe it has more to do with their business model, since even those
who assign real IP addresses spin them periodically and won't allow you
to control the reverse DNS name of them.

> I can see that condition prevailing for
> various practical reasons in parts of Asia, but in general I don't see
> ISPs having any problem getting at least one address per customer.  DHCP
> is one thing, but NAT creates more problems than it solves at the ISP
> level - especially in terms of customer traceability. 

Some NATs are at the head-end, some are in registered boxes at the customer.

>>> Unless one wants to run more than ~4 billion services
>>> of the same type behind the same address, I can't see the motivation.
>>>     
>>
>> The motivation for ISPs to defeat this is their charging model - which
>> is one of the reasons they promoted NATs in the first place. It's easier
>> to serve addresses behind a device you CAN'T run a server on than to
>> monitor who runs a server so you can charge them more.
>>   
> No amount of architecture can prevent ISPs from doing stupid things,
> unfortunately.  They are the literal "men in the middle" after all. 
> Someday, unfortunately, goverment regulation will likely be required to
> set limits on what an ISP can and cannot do in terms of interfering with
> their customer's traffic.  Bills are already before Congress to give the
> FCC explicit authority to do this in the U.S..  So far just the ad hoc
> threat of more extensive regulation seems to be helping.
> 
> Promoting NAT is not an effective way to keep users from running
> "servers".  The common method is to block incoming SYN packets - a
> classic example of ISP interference of the type that should be outlawed,
> interference that doesn't stop much more resource intensive P2P use, NAT
> or no NAT,  at all.

Incoming SYNs block only TCP traffic.

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

iD8DBQFEQ/ecE5f5cImnZrsRAk64AJ45/0rVPSpuyMooMHIFikGsR+UivACfbJWf
uETxBhZHqwPuX48I0xxZ+lM=
=YcCt
-----END PGP SIGNATURE-----

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



From tcpm-bounces@ietf.org Mon Apr 17 19:25:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVd5v-0007Jg-Rq; Mon, 17 Apr 2006 19:25:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVd5u-0007Ht-J2
	for tcpm@ietf.org; Mon, 17 Apr 2006 19:25:22 -0400
Received: from mms1.broadcom.com ([216.31.210.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVd5t-0004nw-8V
	for tcpm@ietf.org; Mon, 17 Apr 2006 19:25:22 -0400
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom
	SMTP Relay (Email Firewall v6.2.0)); Mon, 17 Apr 2006 16:25:10 -0700
X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id
	8B5D32B0; Mon, 17 Apr 2006 16:25:10 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by
	mail-irva-10.broadcom.com (Postfix) with ESMTP id 6850D2AE; Mon, 17 Apr
	2006 16:25:10 -0700 (PDT)
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.5-GA) with ESMTP
	id DIF40667; Mon, 17 Apr 2006 16:25:06 -0700 (PDT)
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
	42C2520501; Mon, 17 Apr 2006 16:25:06 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] Re: TCP port / service names
Date: Mon, 17 Apr 2006 16:25:05 -0700
Message-ID: <54AD0F12E08D1541B826BE97C98F99F143A444@NT-SJCA-0751.brcm.ad.broadcom.com>
Thread-Topic: [tcpm] Re: TCP port / service names
Thread-Index: AcZiUOAeHbMPRr1uQq2OuFF/lw0YywAJDRLg
From: "Caitlin Bestler" 
To: "Mark Butler" ,
	"Joe Touch" 
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006041708; IFV=2.0.6,4.0-7; RPD=4.00.0004;
	RPDID=303030312E30413039303230382E34343434323237452E303033352D412D;
	ENG=IBF; TS=20060417232512; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006041708_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 685AFC5C0HW7938166-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
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

Mark Butler wrote:
> Joe Touch wrote:
>=20

>=20
>=20
> 	The 'old practice' is to using port numbers to indicate service
> 	instances too. DSSR is a way to avoid that, and should
>     be encouraged,
> 	perhaps by NOT supporting this in a new option.
>=20
>=20
> I like the idea of DSSR internal to a host, for ULPs that can
> support it.  However, DSSR on a NAT is the equivalent of
> running an application layer proxy for each ULP, generally on
> an underpowered external box that is difficult to upgrade.
>=20

Actually a major benefit of of enhancing connection setup
options would be to enable a middlebox to act as a traffic
cop *wihthout* acting as an application layer proxy. As you
point out, it is not well designed for that purpose, and
middleboxes looking at TCP payload is inherently unclean
and risky.

I would agree that there is not much of a benefit of
a middlebox doing multiplexing of logical websites
when all of them are delivered to the same daemon
on the same processor anyway. But allowing a virtual
host that is implemented by a cluster of devices
to do its first step filtering of connection setup
*without* having to look at TCP payload would be
a major benefit both for performance and architectural
integrity.
 =20


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



From tcpm-bounces@ietf.org Mon Apr 17 21:24:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVewt-0001Yr-2g; Mon, 17 Apr 2006 21:24:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVews-0001Ym-6u
	for tcpm@ietf.org; Mon, 17 Apr 2006 21:24:10 -0400
Received: from [166.70.100.114] (helo=mail.middle.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVewq-0002Fc-PK
	for tcpm@ietf.org; Mon, 17 Apr 2006 21:24:10 -0400
Received: from citius ([67.137.150.193] helo=[192.168.0.61])
	by mail.middle.net with esmtp (Exim 4.24)
	id 1FVewq-0007MM-Th; Mon, 17 Apr 2006 19:23:47 -0600
Message-ID: <44443FC2.8030702@middle.net>
Date: Mon, 17 Apr 2006 19:24:18 -0600
From: Mark Butler 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Caitlin Bestler 
Subject: Re: [tcpm] Re: TCP port / service names
References: <54AD0F12E08D1541B826BE97C98F99F143A444@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F143A444@NT-SJCA-0751.brcm.ad.broadcom.com>
X-SA-Exim-Connect-IP: 67.137.150.193
X-SA-Exim-Mail-From: butlerm@middle.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87
Cc: tcpm@ietf.org, Joe Touch 
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="===============0616298517=="
Errors-To: tcpm-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0616298517==
Content-Type: multipart/alternative;
	boundary="------------020207040701090503040202"

This is a multi-part message in MIME format.
--------------020207040701090503040202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Caitlin Bestler wrote:

> <>
>
>Actually a major benefit of of enhancing connection setup
>options would be to enable a middlebox to act as a traffic
>cop *wihthout* acting as an application layer proxy. As you
>point out, it is not well designed for that purpose, and
>middleboxes looking at TCP payload is inherently unclean
>and risky.
>  
>
>
Compared to payload inspection techniques, absolutely.  Enhanced 
connection options of the sort we are talking about will require per 
flow state to do protocol level traffic shaping though, because each 
packet will no longer carry even weakly ULP identifying information.

>I would agree that there is not much of a benefit of
>a middlebox doing multiplexing of logical websites
>when all of them are delivered to the same daemon
>on the same processor anyway. But allowing a virtual
>host that is implemented by a cluster of devices
>to do its first step filtering of connection setup
>*without* having to look at TCP payload would be
>a major benefit both for performance and architectural
>integrity.
>  
>
I can see how enhanced connection options this might be used internal to 
a cluster, but not how it would help on the client facing side.  A 
virtual host is completely accessible through a single HTTP/1.1 
connection right?

 - Mark



--------------020207040701090503040202
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Caitlin Bestler wrote:


<>
  
Actually a major benefit of of enhancing connection setup
options would be to enable a middlebox to act as a traffic
cop *wihthout* acting as an application layer proxy. As you
point out, it is not well designed for that purpose, and
middleboxes looking at TCP payload is inherently unclean
and risky.
  





Compared to payload inspection techniques, absolutely.  Enhanced
connection options of the sort we are talking about will require per
flow state to do protocol level traffic shaping though, because each
packet will no longer carry even weakly ULP identifying information.





  
I would agree that there is not much of a benefit of
a middlebox doing multiplexing of logical websites
when all of them are delivered to the same daemon
on the same processor anyway. But allowing a virtual
host that is implemented by a cluster of devices
to do its first step filtering of connection setup
*without* having to look at TCP payload would be
a major benefit both for performance and architectural
integrity.
  



I can see how enhanced connection options this might be used internal
to a cluster, but not how it would help on the client facing side.  A
virtual host is completely accessible through a single HTTP/1.1
connection right?



 - Mark








--------------020207040701090503040202--


--===============0616298517==
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

--===============0616298517==--




From tcpm-bounces@ietf.org Tue Apr 18 09:55:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVqfT-0007W1-6C; Tue, 18 Apr 2006 09:54:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVqfR-0007Vw-S5
	for tcpm@ietf.org; Tue, 18 Apr 2006 09:54:57 -0400
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVqfQ-00005n-AX
	for tcpm@ietf.org; Tue, 18 Apr 2006 09:54:57 -0400
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 k3IDsstA027523
	for ; Tue, 18 Apr 2006 06:54:55 -0700 (PDT)
	(envelope-from mallman@guns.icir.org)
Received: from guns.icir.org (localhost [127.0.0.1])
	by guns.icir.org (Postfix) with ESMTP id DAC3C77AF38
	for ; Tue, 18 Apr 2006 09:54:53 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman 
Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Jailhouse Rock
MIME-Version: 1.0
Date: Tue, 18 Apr 2006 09:54:53 -0400
Message-Id: <20060418135453.DAC3C77AF38@guns.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
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="===============1028961988=="
Errors-To: tcpm-bounces@ietf.org

--===============1028961988==
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


Folks-

Lars sent the attached request a few weeks back and we haven't heard
anything.  Could a couple of folks volunteer to take a look at this
document in the next week or two (it's pretty short)?  

(And, send along a note to me indicating that you intend to do so, else
I'll have to try to poll people specifically.)

Thanks!

allman


 

--=_bOundary
Content-Type: message/rfc822
Content-Disposition: attachment; filename=397
Content-Description: forwarded message

Return-Path: lars.eggert@netlab.nec.de
Delivery-Date: Thu Mar 23 14:45:15 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 5BBBE77AB77
	for ; Thu, 23 Mar 2006 14:45:15 -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);
	Thu, 23 Mar 2006 14:45:15 -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
	k2NJio2d006035
	for ; Thu, 23 Mar 2006 11:44:50 -0800 (PST)
Received: from megatron.ietf.org (stiedprmman1.ietf.org [156.154.16.145])
	by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k2NJigeK093830;
	Thu, 23 Mar 2006 11:44:42 -0800 (PST)
	(envelope-from tcpm-bounces@ietf.org)
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
X-ClamAV: OK
X-SpamProbe: GOOD 0.0000444 bb9c294796c405b755a96091f6251d99
X-mallman-sequence: tcpm


--===============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==--

--=_bOundary--

--==_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQFERO+tWyrrWs4yIs4RAqv5AJsE0NwFvMDpR/5ajLIYST+d9KpEegCeJ4P2
IT76SBELyxWm/T1X4Ct1uYw=
=FiAV
-----END PGP SIGNATURE-----
--==_bOundary--


--===============1028961988==
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

--===============1028961988==--




From tcpm-bounces@ietf.org Tue Apr 18 10:36:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVrJS-0001uh-Ad; Tue, 18 Apr 2006 10:36:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrJR-0001uc-37
	for tcpm@ietf.org; Tue, 18 Apr 2006 10:36:17 -0400
Received: from kremlin.juniper.net ([207.17.137.120])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVrJP-0002e7-Q1
	for tcpm@ietf.org; Tue, 18 Apr 2006 10:36:17 -0400
Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37])
	by kremlin.juniper.net with ESMTP; 18 Apr 2006 07:36:15 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,131,1144047600"; 
	d="scan'208"; a="540718919:sNHT23065908"
Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by
	proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 18 Apr 2006 10:36:14 -0400
Message-ID: <4444F95B.3060801@juniper.net>
Date: Tue, 18 Apr 2006 10:36:11 -0400
From: Ron Bonica 
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Joe Touch 
Subject: Re: [tcpm] TCP port names option ID
References: <44402640.7030705@isi.edu>
In-Reply-To: <44402640.7030705@isi.edu>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Apr 2006 14:36:14.0322 (UTC)
	FILETIME=[71D96520:01C662F5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: tcpm 
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 Joe,

If you want devices to filter packets based on the TCP Port Name Option,
 you might consider placing that option first in the list TCP options.
That would make it easier to filter in hardware.

                                -r


Joe Touch wrote:
> Hi, all,
> 
> In response to some discussion on the IETF mailing list, the following
> ID has been submitted. It's intended to become a TCPM work item (thus
> the header) if there's sufficient interest.
> 
> For the original discussion, see the ietf@ietf.org archives, and look
> for "Guidance needed on well known ports".
> 
> The draft available at the following URL until it's in the ID repositories:
> http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt
> 
> Joe
> 
> ----
> 
> TCPM WG                                                        J. Touch
> Internet Draft                                                  USC/ISI
> Expires: October 2006                                    April 14, 2006
> 
>                         A TCP Option for Port Names
>                      draft-touch-tcp-portnames-00.txt
> ...
> Abstract
> 
>    This document specifies a new TCP option that specifies services by a
>    string name. This option separates the use of port numbers for
>    connection demultiplexing from their use as a service identifier. The
>    option allows a larger number of concurrent connections for a
>    particular service, as well as potentially enabling more explicitly
>    coordination of services behind NATs and firewalls. This option
>    should be supported in new TCP implementations.
> 
> 
> 
> 

_______________________________________________
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 Wed Apr 19 08:58:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWCFn-0006tF-2R; Wed, 19 Apr 2006 08:57:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWCFm-0006t8-6L
	for tcpm@ietf.org; Wed, 19 Apr 2006 08:57:54 -0400
Received: from mail.clavister.com ([85.11.194.12])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWCFk-0001R1-Oj
	for tcpm@ietf.org; Wed, 19 Apr 2006 08:57:54 -0400
Received: by mail.clavister.com (Postfix, from userid 1000)
	id 5BF07BE81C; Wed, 19 Apr 2006 14:57:28 +0200 (CEST)
Received: from smtp-gw.clavister.com (gw-clavister.clavister.com [85.11.194.1])
	by mail.clavister.com (Postfix) with SMTP id 3D546BE894
	for ; Wed, 19 Apr 2006 14:57:24 +0200 (CEST)
Received: FROM hermes-II.clavister.com BY smtp-gw.clavister.com ;
	Wed Apr 19 14:57:43 2006 +0200
Received: from [127.0.0.1] ([10.4.0.16]) by hermes-II.clavister.com with
	Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 14:57:44 +0200
Message-ID: <44463405.6020007@clavister.com>
Date: Wed, 19 Apr 2006 14:58:45 +0200
From: Mikael Olsson 
Organization: Clavister AB
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: weddy@grc.nasa.gov
Subject: Re: [tcpm] syn flooding draft
References: <20060413194810.GB2145@grc.nasa.gov>
In-Reply-To: <20060413194810.GB2145@grc.nasa.gov>
X-Enigmail-Version: 0.90.1.1
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1
X-OriginalArrivalTime: 19 Apr 2006 12:57:44.0385 (UTC)
	FILETIME=[D9AA5310:01C663B0]
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mail.clavister.com
X-Spam-Level: 
X-Spam-Status: No, score=-7.3 required=5.0 tests=LOCAL_CLAVISTER, LOCAL_PROTOS,
	LOCAL_ROUTING,MY_DASH_DASH_SPACE,MY_RECVD_SMTP autolearn=failed 
	version=3.0.3
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
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


Couple of things off the top of my head:

1. On the problem with SYN Cookies and daemons sending the first
  data packet: Yes, packet loss will cause problems here, but remember
  that TCP implementations should only rely on SYN Cookies when their
  half-open queue is full anyway.

2. Attacks on the SYN Cookie scheme itself:
- 7 bits of authentication means an attacker that knows the
  authentication algorithm of the responder "only" needs to
  send 128 times as many packets to establish a fully spoofed
  complete connection that now uses a full TCB as well as
  application resources.
- 40 bytes per SYN * 128 =3D 5120 bytes.
  5120 bytes * 8 bits * 100 connections =3D 4Mbit to create 100 connectio=
ns,
  which is likely to hurt most servers to some extent.
- Connection speeds are always on the rise. A 10mbit upstream pipe is
  far from uncommon today. An attacker on even such a "modest" connection
  is capable of bringing most any server to its knees in as little as
  one second.
- Determining where in the ISN the authentication bits are stored can
  easily be automated by sending as few as maybe a dozen packets and
  detecting which bits are ALWAYS affected as a result of changing
  a single field. This probe could obviously not be spoofed though.

3. On SYN Cache replacement schemes:
   This is implementation rather than spec, but then again so is
   "SYN Cache" to begin with so I figure it's fair game:
   Rather than replacing the oldest entry (common practice), while under
   attack, it makes more sense to replace a random entry. The more slots
   an attacker manages to fill, the higher the chance that the next
   spoofed packet will replace one of the attacker's own slots.

/Mikael

--=20
Mikael Olsson, Clavister AB
Torggatan 10, Box 393, SE-891 28 =D6RNSK=D6LDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com


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



From tcpm-bounces@ietf.org Fri Apr 21 16:23:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FX29y-0000Am-3A; Fri, 21 Apr 2006 16:23:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FX29w-0000AD-VI
	for tcpm@ietf.org; Fri, 21 Apr 2006 16:23:20 -0400
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX29v-0004RM-K3
	for tcpm@ietf.org; Fri, 21 Apr 2006 16:23:20 -0400
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 k3LKNI5b004006
	for ; Fri, 21 Apr 2006 13:23:19 -0700 (PDT)
	(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 38DF277AB77
	for ; Fri, 21 Apr 2006 16:23:17 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP id 799143F92BA
	for ; Fri, 21 Apr 2006 16:22:25 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: The Rising
MIME-Version: 1.0
Date: Fri, 21 Apr 2006 16:22:25 -0400
Message-Id: <20060421202225.799143F92BA@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [tcpm] meeting materials all online
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="===============1391398855=="
Errors-To: tcpm-bounces@ietf.org

--===============1391398855==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain
Content-Disposition: inline

 
All meeting materials from IETF65 are now posted at:

  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65

allman




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFEST8BWyrrWs4yIs4RAmmMAJ9ElCoRzQnGQrRYcBEGy/F0WBJAlACeKJMY
r+8UEKRzD5bQUTcq53lQcB8=
=ayl4
-----END PGP SIGNATURE-----
--=_bOundary--


--===============1391398855==
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

--===============1391398855==--




From tcpm-bounces@ietf.org Wed Apr 26 16:02:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYqDF-0002rC-Jz; Wed, 26 Apr 2006 16:02:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq64-0006os-IN
	for tcpm@ietf.org; Wed, 26 Apr 2006 15:54:49 -0400
Received: from wyvern.icir.org ([192.150.187.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq62-0000aW-3a
	for tcpm@ietf.org; Wed, 26 Apr 2006 15:54:47 -0400
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 k3QJsgjB013061;
	Wed, 26 Apr 2006 12:54:43 -0700 (PDT)
	(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 4C8CD77AB77; Wed, 26 Apr 2006 15:54:41 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1])
	by lawyers.icir.org (Postfix) with ESMTP id 154653FBF1A;
	Wed, 26 Apr 2006 15:53:49 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman 
Subject: Re: [tcpm] syn flooding draft 
In-Reply-To: <20060413194810.GB2145@grc.nasa.gov> 
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Ramble On
MIME-Version: 1.0
Date: Wed, 26 Apr 2006 15:53:48 -0400
Message-Id: <20060426195349.154653FBF1A@lawyers.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: weddy@grc.nasa.gov, Ted Faber 
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="===============0982793518=="
Errors-To: tcpm-bounces@ietf.org

--===============0982793518==
Content-Type: multipart/signed; boundary="=_bOundary";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--=_bOundary
Content-Type: text/plain
Content-Disposition: inline


Folks- 

This draft:

> FYI: An updated version of the draft on TCP SYN flooding and defenses
> (including SYN cookies) is available:
> http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt

has been discussed a bit on the list.  The vibe Ted and I have picked up
is that folks think its a good document to have around (even though
several folks have identified possible areas for improvement).  So,
we're asking if folks think that TCPM should take on this document as a
WG item.  As the document states, it's targeted as informational and a
guess at a timeframe (a WAG between Wes, Ted and I) is 6 months.

If you think this ought to be on our plate (or not), please say so.
(Lack of positive response will meet with the same decision as an
overwhelmingly negative response.)

Thanks!

allman



-- 
Mark Allman -- ICIR/ICSI -- http://www.icir.org/mallman/




--=_bOundary
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFET8/MWyrrWs4yIs4RAnFJAKCXVUBYba6alZbM59wrxxwxA2XB7wCeNoTT
ceu6n/5eBeJAkSHJJDpuWG8=
=goyC
-----END PGP SIGNATURE-----
--=_bOundary--


--===============0982793518==
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

--===============0982793518==--




From tcpm-bounces@ietf.org Wed Apr 26 16:30:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYqer-0000Dc-Cf; Wed, 26 Apr 2006 16:30:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FYqeq-00009L-HM
	for tcpm@ietf.org; Wed, 26 Apr 2006 16:30:44 -0400
Received: from mms1.broadcom.com ([216.31.210.17])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYqeo-0003XN-5s
	for tcpm@ietf.org; Wed, 26 Apr 2006 16:30:44 -0400
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom
	SMTP Relay (Email Firewall v6.2.0)); Wed, 26 Apr 2006 13:30:31 -0700
X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id
	B8E0A2B0; Wed, 26 Apr 2006 13:30:31 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by
	mail-irva-10.broadcom.com (Postfix) with ESMTP id 85C182AE for
	; Wed, 26 Apr 2006 13:30:31 -0700 (PDT)
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.5-GA) with ESMTP
	id DJU00732; Wed, 26 Apr 2006 13:30:20 -0700 (PDT)
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
	6FF0920501 for ; Wed, 26 Apr 2006 13:30:20 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] syn flooding draft
Date: Wed, 26 Apr 2006 13:30:19 -0700
Message-ID: <54AD0F12E08D1541B826BE97C98F99F143AE87@NT-SJCA-0751.brcm.ad.broadcom.com>
Thread-Topic: [tcpm] syn flooding draft
Thread-Index: AcZpbHE4iR5Pu03BTv6q06Wuhz9TLgAA6aow
From: "Caitlin Bestler" 
To: tcpm@ietf.org
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006042607; IFV=2.0.6,4.0-7; RPD=4.00.0004;
	RPDID=303030312E30413039303230312E34343446443643412E303035422D452D5046786C33494E497A33445631553653544639524F673D3D;
	ENG=IBF; TS=20060426203032; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006042607_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 685107ED0HW10406795-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
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

Mark Allman wrote:
> Folks-
>=20
> This draft:
>=20
>> FYI: An updated version of the draft on TCP SYN flooding and defenses
>> (including SYN cookies) is available:
>> http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt
>=20
> has been discussed a bit on the list.  The vibe Ted and I
> have picked up is that folks think its a good document to
> have around (even though several folks have identified
> possible areas for improvement).  So, we're asking if folks
> think that TCPM should take on this document as a WG item.
> As the document states, it's targeted as informational and a
> guess at a timeframe (a WAG between Wes, Ted and I) is 6 months.
>=20
> If you think this ought to be on our plate (or not), please say so.
> (Lack of positive response will meet with the same decision
> as an overwhelmingly negative response.)
>=20
> Thanks!
>=20
> allman

As indicated in my earlier comment, I think this is a valuable
document, which can be made more valuable via WG input.


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