From owner-wrec@cs.utk.edu Thu Sep 7 16:35:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26601 for ; Thu, 7 Sep 2000 16:35:46 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA25253; Thu, 7 Sep 2000 15:27:14 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 7 Sep 2000 15:25:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA25137; Thu, 7 Sep 2000 15:25:29 -0400 (EDT) Received: from mailman.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA25124; Thu, 7 Sep 2000 15:25:28 -0400 (EDT) Received: from mailman.cisco.com (171.68.225.9 -> mailman.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 7 Sep 2000 15:25:28 -0400 Received: from [192.168.1.11] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id MAA05098 for ; Thu, 7 Sep 2000 12:25:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 7 Sep 2000 21:19:56 +0200 To: wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Middlebox Features Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: The IESG is worried about "middlebox features" which comes up all over the place. Just all over. The way people think about early TCP termination, "front-ending SSL connections so the SSL is not all the way to the server", ...etc might not all the time work well in todays design of the Internet. Is this trend driven by customers to companies asking for features without knowing what they are asking for? Because, companies only make products which customers buy, right? ;-) We ask if not the WREC wg is the closest group we have on looking into these issues, and hope that the WREC wg will try to design functionality which is needed without jumping through too many loops and bending themselves backwards, violating the ground principles of end-to-end-communication which the IESG and IAB belive is needed for fundamental architectual things to work (like IPSEC etc). One document we have found is draft-tomlinson-epsfw-00.txt, which we think is interesting because it is discussing some of these issues (yes, I know it was on the agenda at the last IETF... :-) Can you please in the work you do on rechartering think about these "middleware feature" thing, and whether you should not include some wording about that in your charter? We also would like you to have a look at draft-tomlinson-epsfw-00.txt and deside if you should have that document as part of what you work items (so it gets proper review at least)? Regards, Patrik Area Director, Applications Area From owner-wrec@cs.utk.edu Fri Sep 8 15:03:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28236 for ; Fri, 8 Sep 2000 15:03:11 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA00916; Fri, 8 Sep 2000 14:59:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 14:57:48 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA00696; Fri, 8 Sep 2000 14:57:47 -0400 (EDT) Received: from mail.gmx.net (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA00671; Fri, 8 Sep 2000 14:57:43 -0400 (EDT) Received: from mail.gmx.net (194.221.183.20 -> pop.gmx.net) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 14:57:44 -0400 Received: (qmail 20712 invoked by uid 0); 8 Sep 2000 18:57:29 -0000 Received: from unknown (HELO nassau) (149.81.0.5) by mail.gmx.net with SMTP; 8 Sep 2000 18:57:29 -0000 To: "'wrec@cs.utk.edu'" From: "NorthStar.com" Subject: Your current resume Date: Fri, 08 Sep 2000 15:14:58 -0500 Message-Id: <36777.635401747684200.628878@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit List-Unsubscribe: Content-Transfer-Encoding: 8bit Greetings, I found your contact information on the web while conducting a search for IT professionals to fill a few select positions available with my clients. These are all highly visible full-time, permanent positions with e-commerce and financial firms in the New York City Metro area offering great growth opportunities and excellent compensation and benefits packages. If you are still on the market, or considering it, please email your current resume to careers@northstar.com; also, please specify your current and desired compensation package. Some background information: NorthStar Technologies, Inc. is a technical consulting and recruiting firm in the Wall Street area with clients in the e-commerce, financial and computer services industries throughout the Northeast. By all means, visit our website - http://www.northstar.com - and review our job bank periodically. I look forward to hearing from you soon. Regards, Imran Anwar anwar@northstar.com From owner-wrec@cs.utk.edu Fri Sep 8 17:32:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01021 for ; Fri, 8 Sep 2000 17:32:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA20805; Fri, 8 Sep 2000 17:28:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 17:26:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA20630; Fri, 8 Sep 2000 17:26:46 -0400 (EDT) Received: from fep03-svc.swip.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA20598; Fri, 8 Sep 2000 17:26:42 -0400 (EDT) Received: from fep03-svc.swip.net (130.244.199.131 -> fep03.swip.net) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 17:26:42 -0400 Received: from henrik.localdomain ([212.151.183.160]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20000908212639.FSCQ15523.fep03-svc.swip.net@henrik.localdomain>; Fri, 8 Sep 2000 23:26:39 +0200 Received: from henrik.localdomain (localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id XAA24914; Fri, 8 Sep 2000 23:27:09 +0200 Sender: hno@hem.passagen.se Message-ID: <39B959AD.40C477AB@hem.passagen.se> Date: Fri, 08 Sep 2000 23:27:09 +0200 From: Henrik Nordstrom X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.16-3 i586) MIME-Version: 1.0 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= CC: wrec@cs.utk.edu Subject: Re: Middlebox Features References: Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01021 Patrik Fältström wrote: > The IESG is worried about "middlebox features" which comes up all > over the place. Just all over. The way people think about early TCP > termination, "front-ending SSL connections so the SSL is not all the > way to the server", ...etc might not all the time work well in todays > design of the Internet. I think most IP people dislike the TCP hacks quite often done today in load balancers and "transparent" proxies & accelerators. This is bound to give problems sooner or later (quite often sooner in my experience). Regarding the SSL connection termination outside the "web server" I don't view it as a problem if done properly (i.e. no TCP hacking). Technically what is done is to introduce a HTTPS->HTTP application gateway in the request flow. The end point the user client connects to is the gateway application. -- Henrik Nordström From owner-wrec@cs.utk.edu Fri Sep 8 17:39:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01115 for ; Fri, 8 Sep 2000 17:39:23 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA21962; Fri, 8 Sep 2000 17:35:24 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 17:34:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA21731; Fri, 8 Sep 2000 17:33:59 -0400 (EDT) Received: from mail.iscaletech.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA21691; Fri, 8 Sep 2000 17:33:54 -0400 (EDT) Received: from mail.iscaletech.com (206.14.135.3 -> 206-14-135-3.ncal.verio.com) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 17:33:55 -0400 Received: from case (case.iscaletech.com [206.14.135.142]) by mail.iscaletech.com (8.11.0/8.11.0) with SMTP id e88Le3N28203 for ; Fri, 8 Sep 2000 14:40:03 -0700 From: "Jeremy Abramson" To: Subject: Is this me? Date: Fri, 8 Sep 2000 14:30:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: Content-Transfer-Encoding: 7bit And if this isn't me, why do I keep getting e-mail to this non-me person? J. From owner-wrec@cs.utk.edu Fri Sep 8 17:39:33 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01126 for ; Fri, 8 Sep 2000 17:39:32 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA22154; Fri, 8 Sep 2000 17:35:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 17:34:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA21775; Fri, 8 Sep 2000 17:34:20 -0400 (EDT) Received: from diablo.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA21762; Fri, 8 Sep 2000 17:34:19 -0400 (EDT) Received: from diablo.cisco.com (171.68.224.210 -> diablo.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 17:34:19 -0400 Received: from dgourlaypc100 (dhcp-10-34-17-145.cisco.com [10.34.17.145]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA01823; Fri, 8 Sep 2000 14:33:43 -0700 (PDT) From: "Douglas Gourlay" To: , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Subject: RE: Middlebox Features Date: Fri, 8 Sep 2000 14:37:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <39B959AD.40C477AB@hem.passagen.se> List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by cs.utk.edu id RAA22154 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01126 I have to agree with this logic. SSL termination devices placed in front of web servers for the purpose of offloading the computationally expensive key generation/exchange and/or the encryption/decryption processing are not much more than hardware optimized web proxy servers. The key design considerations this generates are more in the security space. I say this because how we choose to deal with this "used to be encrypted" data after termination is a concern that will plague the end-user of a commerce site. dg ------------------------------------------ Douglas Gourlay W- 415.371.2345 C- 415.269.3684 -----Original Message----- From: hno@hem.passagen.se [mailto:hno@hem.passagen.se] Sent: Friday, September 08, 2000 2:27 PM To: Patrik Fältström Cc: wrec@cs.utk.edu Subject: Re: Middlebox Features Patrik Fältström wrote: > The IESG is worried about "middlebox features" which comes up all > over the place. Just all over. The way people think about early TCP > termination, "front-ending SSL connections so the SSL is not all the > way to the server", ...etc might not all the time work well in todays > design of the Internet. I think most IP people dislike the TCP hacks quite often done today in load balancers and "transparent" proxies & accelerators. This is bound to give problems sooner or later (quite often sooner in my experience). Regarding the SSL connection termination outside the "web server" I don't view it as a problem if done properly (i.e. no TCP hacking). Technically what is done is to introduce a HTTPS->HTTP application gateway in the request flow. The end point the user client connects to is the gateway application. -- Henrik Nordström From owner-wrec@cs.utk.edu Fri Sep 8 17:48:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01285 for ; Fri, 8 Sep 2000 17:48:04 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA23852; Fri, 8 Sep 2000 17:44:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 17:42:46 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA23647; Fri, 8 Sep 2000 17:42:46 -0400 (EDT) Received: from localhost.localdomain (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA23633; Fri, 8 Sep 2000 17:42:44 -0400 (EDT) Received: from localhost.localdomain (207.8.144.3 -> thibault.org) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 17:42:44 -0400 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id RAA01539 for ; Fri, 8 Sep 2000 17:45:00 -0400 Sender: francis@localhost.localdomain Message-ID: <39B95DDB.C9E85246@ecal.com> Date: Fri, 08 Sep 2000 17:44:59 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: wrec@cs.utk.edu Subject: Re: Middlebox Features References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Douglas Gourlay wrote: > The key design > considerations this generates are more in the security space. I say this > because how we choose to deal with this "used to be encrypted" data after > termination is a concern that will plague the end-user of a commerce site. Yes, but we have similar concerns today, because the transaction records are normally stored in plaintext. For most commerce sites, it's probably easier to break into the database than to intercept network traffic (more lucrative, too, since you can get more data in a short time). -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"What we have here is a failure to assimilate."| |francis@ecal.com|--Cool Hand Locutius | \================================================================/ From owner-wrec@cs.utk.edu Fri Sep 8 18:04:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01514 for ; Fri, 8 Sep 2000 18:04:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA27080; Fri, 8 Sep 2000 18:00:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 17:59:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA26859; Fri, 8 Sep 2000 17:59:08 -0400 (EDT) Received: from diablo.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA26844; Fri, 8 Sep 2000 17:59:06 -0400 (EDT) Received: from diablo.cisco.com (171.68.224.210 -> diablo.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 17:59:06 -0400 Received: from dgourlaypc100 (dhcp-10-34-17-145.cisco.com [10.34.17.145]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA24776; Fri, 8 Sep 2000 14:59:03 -0700 (PDT) From: "Douglas Gourlay" To: "John Stracke" , Subject: RE: Middlebox Features Date: Fri, 8 Sep 2000 15:02:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <39B95DDB.C9E85246@ecal.com> List-Unsubscribe: Content-Transfer-Encoding: 7bit I absolutely agree. A database hack can be MUCH more valuable than just traffic interception. Some large financial institutions I have worked with on this have been more concerned about the "ease" of the hack for an insider though. For instance, it takes some degree of skill to hack the DB and pull down all the CC numbers. On the other hand, the skill level required to put a sniffer between two nodes and capture packets is far less. Although it does imply a trust issue (employee-employer) is gone and physical security at the site has been violated. So fundamentally I think we are in agreement that SSL termination is not a "bad" thing provided the designs they are deployed within conform to a reasonable level of security. dg ------------------------------------------ Douglas Gourlay W- 415.371.2345 C- 415.269.3684 -----Original Message----- From: francis@localhost.localdomain [mailto:francis@localhost.localdomain]On Behalf Of John Stracke Sent: Friday, September 08, 2000 2:45 PM To: wrec@cs.utk.edu Subject: Re: Middlebox Features Douglas Gourlay wrote: > The key design > considerations this generates are more in the security space. I say this > because how we choose to deal with this "used to be encrypted" data after > termination is a concern that will plague the end-user of a commerce site. Yes, but we have similar concerns today, because the transaction records are normally stored in plaintext. For most commerce sites, it's probably easier to break into the database than to intercept network traffic (more lucrative, too, since you can get more data in a short time). -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"What we have here is a failure to assimilate."| |francis@ecal.com|--Cool Hand Locutius | \================================================================/ From owner-wrec@cs.utk.edu Fri Sep 8 18:15:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01615 for ; Fri, 8 Sep 2000 18:15:59 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA28767; Fri, 8 Sep 2000 18:12:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 18:10:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA28671; Fri, 8 Sep 2000 18:10:47 -0400 (EDT) Received: from localhost.localdomain (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA28658; Fri, 8 Sep 2000 18:10:45 -0400 (EDT) Received: from localhost.localdomain (207.8.144.3 -> thibault.org) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 18:10:45 -0400 Received: from ecal.com (localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id SAA01629 for ; Fri, 8 Sep 2000 18:13:02 -0400 Sender: francis@localhost.localdomain Message-ID: <39B9646C.68775550@ecal.com> Date: Fri, 08 Sep 2000 18:13:00 -0400 From: John Stracke X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-3 i586) X-Accept-Language: en MIME-Version: 1.0 To: wrec@cs.utk.edu Subject: Re: Middlebox Features References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Douglas Gourlay wrote: > On the other hand, the skill level required > to put a sniffer between two nodes and capture packets is far less. True, but how many sites encrypt the link between the Web server and the DB? It might take a bit more skill than sniffing the HTTP, because the database protocol is probably harder to read than HTTP, but probably not a lot more. Really, an SSL connection only assures the user that nobody can intercept their traffic out on the public Internet. Once that's understood, the SSL-terminating boxen sound more reasonable. Um...however, there is one way they could make matters much worse. I can imagine a shady (or really ignorant) company offering SSL termination services, where the unencrypted hop runs over the public Internet. It'd be even more vulnerable than a completely unencrypted setup, because all the unencrypted data would be running over more or less the same path, so it'd be easier to intercept. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"If there's anything The Flintstones have taught| |francis@ecal.com|us, it's that pelicans can be used to mix | | |cement." -- Homer Simpson | \=================================================================/ From owner-wrec@cs.utk.edu Fri Sep 8 18:28:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01785 for ; Fri, 8 Sep 2000 18:28:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA00350; Fri, 8 Sep 2000 18:24:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 8 Sep 2000 18:23:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA00080; Fri, 8 Sep 2000 18:23:36 -0400 (EDT) Received: from fep03-svc.swip.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA00059; Fri, 8 Sep 2000 18:23:34 -0400 (EDT) Received: from fep03-svc.swip.net (130.244.199.131 -> fep03.swip.net) by cs.utk.edu (smtpshim v1.0); Fri, 8 Sep 2000 18:23:34 -0400 Received: from henrik.localdomain ([212.151.242.48]) by fep03-svc.swip.net (InterMail vM.5.01.01.01 201-252-104) with ESMTP id <20000908222331.GDCG15523.fep03-svc.swip.net@henrik.localdomain>; Sat, 9 Sep 2000 00:23:31 +0200 Received: from henrik.localdomain (localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id AAA26450; Sat, 9 Sep 2000 00:20:45 +0200 Sender: hno@hem.passagen.se Message-ID: <39B9663C.70D7440F@hem.passagen.se> Date: Sat, 09 Sep 2000 00:20:44 +0200 From: Henrik Nordstrom X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.16-3 i586) MIME-Version: 1.0 To: Douglas Gourlay CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , wrec@cs.utk.edu Subject: Re: Middlebox Features References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Douglas Gourlay wrote: > The key design considerations this generates are more in the > security space. I say this because how we choose to deal with > this "used to be encrypted" data after termination is a concern > that will plague the end-user of a commerce site. Sure, and this does not have that much with SSL to do. More of a general concern how sensitive data is processed at the site. The reasoning must be applied to the whole chain where the data is processed, not only the web server. SSL acceleration gateways are part of the service setup, just as HTTP servers, server-side applications, SQL servers and even humans processing the entered data. Where you draw the line on how far data must be encryped depends on the requirements of setup as a whole, not a single component like SSL. -- Henrik Nordstrom From owner-wrec@cs.utk.edu Sun Sep 10 07:44:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07841 for ; Sun, 10 Sep 2000 07:44:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA21837; Sun, 10 Sep 2000 07:39:40 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 10 Sep 2000 07:38:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA21805; Sun, 10 Sep 2000 07:38:07 -0400 (EDT) Received: from anchor-post-32.mail.demon.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA21792; Sun, 10 Sep 2000 07:38:04 -0400 (EDT) Received: from anchor-post-32.mail.demon.net (194.217.242.90 -> anchor-post-32.mail.demon.net) by cs.utk.edu (smtpshim v1.0); Sun, 10 Sep 2000 07:38:05 -0400 Received: from alethea.demon.co.uk ([194.222.10.198] helo=ian-nt.equinix.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 13Y5Qw-0007P6-0W for wrec@cs.utk.edu; Sun, 10 Sep 2000 12:38:03 +0100 Message-Id: <4.3.2.7.2.20000910122104.00b6bdf0@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Sep 2000 12:21:52 +0100 To: wrec@cs.utk.edu From: Ian Cooper Subject: Draft WREC minutes (IETF48) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: [Draft] minutes for the WREC meeting, IETF48 (Pittsburgh) Apologies for absence: John Martin In addition to a discussion of the WREC Known Problems document (draft-ietf-wrec-known-prob-02.txt) there were two presentations. There was no discussion on the WREC Taxonomy document at this meeting. Surrogates presentation ----------------------- Ted Hardie & Mark Nottingham (draft-nottingham-surrogates-00.txt) Mailing list: surrogates@equinix.com (subscribe at surrogates-request@equinix.com) Open source surrogate: bellwether Definition of the term "surrogate" exists in the WREC taxonomy but this needs to be extended. Need to document the differences from other devices (e.g. proxies); caching surrogates vs. caching proxies. Must examine HTTP headers related to cache-control to distinguish between caching proxies and caching surrogates; determine the applicability of existing headers; get rid of proxy-specific directives. There are currently no interoperable standards for a content provider to interact with multiple CDNs (how to choose between multiple CDNs, where URL re-writing is performed?). There are a minimal set of interactions: expire, refresh, extend TTL, pre-load. Surrogate specific enhancements: authoritative surrogates, content negotiation, authentication issues, redirect resolution. Define semantics of how surrogates behave within the network. Fixing bugs in cache-control headers vs. defining new directives; cache-control headers do not necessarily apply to surrogates (but do apply to other clients). Other groups (e.g. Extensible Proxies & Content Control HTTP headers) are investigating HTTP header issues; there should be cooperation between the groups. HTTP specification prohibits (new?) end-to-end headers. However, the surrogate acts as a gateway. The authorization issues surrounding surrogates are presently not clear. Work needed: * Definition of the term * Document differences from other devices * Examine HTTP headers for applicability Volunteer Authors: Mark Day, Fred Douglis, Jon Stracke Extensible Proxies presentation ------------------------------- Gary Tomlinson (draft-tomlinson-epsfw-00.txt) Mailing list: ietf-opencache@imc.org (subscribe ietf-opencache-request@imc.org) Workshop on 13 September 2000 Intent is to provide content driver services within proxies: * there are currently no standards in place * orthogonal to caching proxy infrastructure * provides an opportunity for a (caching) proxy to exploit content-driven services * Need to develop the framework, requirements, and standards * Examine security issues * Modifying bits on the fly * Value add to content services (e.g. Ad. injection) * Operate on behalf of users or content providers Within the extensible proxies framework an interception proxy should never change content without a content provider relationship. Goals: * Establish standard architecture requirements, protocols, APIs * Consistent with end-to-end principle * Encompass IETF frameworks including AAA and policy * Programming language independence First goal is to develop the framework. Next steps: * suitable for IETF? (consensus suggests *not* suitable for WREC) * spans sufficient space for own WG * need input from content providers - their perspective is currently missing * consider the issue of APIs in IETF * request for a bof in San Diego? WREC Known Problems draft ------------------------- Ian Cooper (draft-ietf-wrec-known-prob-02.txt) 19 submissions covered in the current draft, plus 1 submission since - Architecture: 9 (+1) - Implementation: 6 - Administration: 4 Architecture: "Interception proxies break client cache directives" (Clients do not send cache-control headers as they believe they are communicating with a server, not a proxy) Fix RFC2616 - cache control headers should always be sent Very high priority (10/10) Work on proxy discovery to remove need for interception proxies "Interception proxies prevent introduction of new HTTP methods" Already "fixed" within RFC2616 RFC2616 states that a proxy must operate as a tunnel if it does not understand a request "Interception proxies break IP address-based authentication" (Content providers mistakenly using IP based authentication) Recommend creation of an Informational RFC for advise on dos and don'ts for content providers Medium priority (6/10) "Cannot specify multiple URIs for replicated resources" (Servers/proxies cannot redirect requests to alternate locations where the resource is known to reside) Priority -1/10 - take to mailing list "Replica distance is unknown" Priority of -10/10 - "impossible" to calculate, should not be an area of interest for the group, let CDNs use their own secret sauce "Proxy resource location" (and surrogates) Medium priority (4/10) "Caching proxy peer selection in heterogeneous networks" Of interest to the group, come back to this at a later date Low priority (2/10) "ICP performance" (should be moving away from ICP) "Caching proxy meshes can break HTTP serialization of content" Move away from use of heuristics Low priority (1/10) "The Vary header is underspecified and/or misleading" Work with other groups (e.g. cnhhttp) to improve Medium priority (5/10) Implementation: "Use of Cache-Control headers" (Content providers not using Cache-Control headers) Dos and don'ts document Medium priority (6/10) "Lack of HTTP/1.1 compliance for caching proxies" Little that the group can do directly Push the community to provide better support Low priority (for WREC) (1/10) "ETag support" Little that the group can do directly Push the community to provide better support Low priority (for WREC) (1/10) "User agent/proxy failover" Related to discovery of proxies Medium to high priority (7/10) "Servers and content should be optimized for caching" Dos and don'ts document Medium priority (6/10) "Some servers send bad Content-Length header for files that contain CR" Not something the group can address, programming bugs (0/10) Administration: The group identified that WREC is not in a position to do any work in this area. Next steps: * Re-work KP document to better describe those problems the group plans to address; move other problems to appendix so that they are at least captured in a single location * Identify those areas future work for the group and get started - "fix" RFC2616 cache-control issues - proxy/surrogate discovery - document on dos and don'ts for content providers - better specification of Vary header (with cnhhttp) From owner-wrec@cs.utk.edu Tue Sep 12 12:34:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08568 for ; Tue, 12 Sep 2000 12:34:13 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA17365; Tue, 12 Sep 2000 12:29:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 12 Sep 2000 12:27:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA17104; Tue, 12 Sep 2000 12:27:42 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA17090; Tue, 12 Sep 2000 12:27:40 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Tue, 12 Sep 2000 12:27:40 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA07647; Tue, 12 Sep 2000 09:27:34 -0700 (PDT) Message-ID: <39BE5965.3B046252@isi.edu> Date: Tue, 12 Sep 2000 09:27:17 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henrik Nordstrom CC: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , wrec@cs.utk.edu Subject: Re: Middlebox Features References: <39B959AD.40C477AB@hem.passagen.se> Content-Type: text/plain; charset=iso-8859-1 List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by cs.utk.edu id MAA17365 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08568 Henrik Nordstrom wrote: > > Patrik Fältström wrote: > > > The IESG is worried about "middlebox features" which comes up all > > over the place. Just all over. The way people think about early TCP > > termination, "front-ending SSL connections so the SSL is not all the > > way to the server", ...etc might not all the time work well in todays > > design of the Internet. > > I think most IP people dislike the TCP hacks quite often done today in > load balancers and "transparent" proxies & accelerators. This is bound > to give problems sooner or later (quite often sooner in my experience). To be more specific, IP people avoid violating existing standards (TCP, IP), both because of potential side effects, as well as it 'robs Peter to pay Paul'. Either standards matter (in which case don't violate the old one), or they don't (in which case why bother creating the new one). It is the hack which is liable to give problems sooner or later; not the IP people's dislike of them. :-) Joe From owner-wrec@cs.utk.edu Mon Sep 18 23:20:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25513 for ; Mon, 18 Sep 2000 23:20:52 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA22902; Mon, 18 Sep 2000 23:16:32 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 18 Sep 2000 23:14:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA22651; Mon, 18 Sep 2000 23:14:25 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA22608; Mon, 18 Sep 2000 23:14:13 -0400 (EDT) Received: from 1-132.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Mon, 18 Sep 2000 23:14:17 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id A58256601; Mon, 18 Sep 2000 20:14:08 -0700 (PDT) Date: Mon, 18 Sep 2000 20:14:08 -0700 From: Mark Nottingham To: WREC Working Group Cc: ietf-openproxy@imc.org Subject: End to End thoughts [long] Message-ID: <20000918201408.D2609@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i List-Unsubscribe: There's been a lot of talk in various places about end-to-end problems, and their relation to intermediates (e.g., HTTP caching proxies, surrogates, etc.). Things have gotten somewhat religious. Rather than go down that road, I'd like to examine the issues and separate them into distinct problems. * Network Layer The end-to-end principle applies to *network* layer functions; it is not meant to preclude an application-level gateway. I _think_ that most everyone will agree that functions that break end-to-end transparency at the network layer cause problems. In other words, Interception Proxies are Evil. While it's nice to think that we can convince the world of this, it's more realistic to find out why people use them, and give them a better alternative. To my knowledge, most people use them because they need an easy way to assure that Web traffic (or at least port 80) goes through a proxy. While browser have proxy auto-configuration, it hasn't changed in quite a few years, there's no standard to implement, and it relies on JavaScript. WPAD was a good start; unfortunately, it never really went to far beyond Microsoft. Additionally, a more sensible, standard format for the configuration file would help. Over all of this, we need participation from the browser vendors, or we won't get anywhere. * Application Layer All of this being said, HTTP intermediates *do* raise issues at the application layer, which aren't end-to-end problems, but do get confused with them, as the causes are similar. Proxies and surrogates can do a number of things to requests and responses as they flow through. I've been roughly classifying them as; - access control (e.g., blocking, filtering) - request modification (URI rewriting) - response modification (transcoding) These operations are often performed in the interest of one of different parties: - content provider - access provider - user There have been numerous papers and discussions about the interesting things that can be done by intermediates. However, I don't think there's enough attention being paid to the problems that enabling these functions on intermediates can cause. * HTTP The HTTP makes a primary assumption of semantic transparency - that an entity body will not be changed 'in flight' - that, discounting transfer-encodings and so forth, what the server sends in the response is what the client gets. Jeff Mogul brought up issues with entity identity, as expressed in the ETag, in Lisbon. There was also general concern (it may have been Jeff in particular, my memory isn't that good) that an operation performed in one portion of the network may not be performed in another, causing unpredicatable behaviours. There are lots of other little examples here that should be covered, but I'll leave it for now. * URI One of the premises of URIs is that they refer to a specific, identifyable resource, and that the authority for that resource has control over it. Many applications have dependencies on this. PICS, Robots Exclusion, P3P, and other kinds of metadata systems break, sometimes disasterously, when intermediates change the semantics and/or payload of a message. The privacy implications are especially of concern. Overall, content providers have a reasonable expectation that the object which they deliver will be the one that the user gets, unless the user doesn't want it. These effects are largely social and legal; however, they're enabled by the technology that's being pushed out there. We need to reconcile the capabilities of the products and frameworks that we're building with the expectations that have been set by our base protocols. It's interesting that Web caching seems to be losing ground to CDNs so rapidly; to me, this illustrates the point perfectly. Web caching was always performed in the interest of the access provider, not the content provider (or arguably even the user). As a result, content providers don't trust Web caches. What's it going to be like out there when access providers can slip a transcoding, rewriting module into a proxy on the fly? One person who I've talked about this with pointed out the issues we had a while back in caches vs. copyright, legally. There's much more direct potential for problems here. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Tue Sep 19 20:17:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26796 for ; Tue, 19 Sep 2000 20:17:48 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA12895; Tue, 19 Sep 2000 20:13:38 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 19 Sep 2000 20:12:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA12534; Tue, 19 Sep 2000 20:12:13 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA12515; Tue, 19 Sep 2000 20:12:10 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Tue, 19 Sep 2000 20:12:10 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA24751; Tue, 19 Sep 2000 17:11:47 -0700 (PDT) Message-ID: <39C800B3.66965AA4@isi.edu> Date: Tue, 19 Sep 2000 17:11:31 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Nottingham CC: WREC Working Group , ietf-openproxy@imc.org, touch@ISI.EDU Subject: Re: End to End thoughts [long] References: <20000918201408.D2609@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > There's been a lot of talk in various places about end-to-end > problems, and their relation to intermediates (e.g., HTTP caching > proxies, surrogates, etc.). > > Things have gotten somewhat religious. Rather than go down that road, > I'd like to examine the issues and separate them into distinct > problems. > > * Network Layer > > The end-to-end principle applies to *network* layer functions; it is > not meant to preclude an application-level gateway. The E2E principle applies to all services implemented at the endpoints, not just transport. This includes reliable transfer, security, etc. It does not preclude anything, per se. It merely says that E2E services (e.g., reliable transport, app security, etc.) cannot be composed _merely_ out of equivalent hop-by-hop services. > I _think_ that most everyone will agree that functions that break > end-to-end transparency at the network layer cause problems. In other > words, > > Interception Proxies are Evil. The problem with interception proxies isn't breakage of E2E; it's breakage of standard protocols. See http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. > Proxies and surrogates can do a number of things to requests and > responses as they flow through. I've been roughly classifying them > as; > > - access control (e.g., blocking, filtering) > - request modification (URI rewriting) > - response modification (transcoding) Yes - and these are actually discussed in the original E2E paper. This is basically value-added services. There are plenty of them. The E2E principle doesn't prohibit HBH services; it just says HBH alone do not compose to yield E2E. It specifically allows (if not encourages) HBH for performance enhancement, with the caveat that it is also possible to degrade performance if not done carefully. > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. What's it going to be like out > there when access providers can slip a transcoding, rewriting module > into a proxy on the fly? CDNs use web caches, don't they? or at least what do you call the rented Akamai server? I call it a cache... (CDN is just an economic model for charging the provider for space on the cache) Joe From owner-wrec@cs.utk.edu Tue Sep 19 20:46:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27053 for ; Tue, 19 Sep 2000 20:46:46 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA16672; Tue, 19 Sep 2000 20:42:53 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 19 Sep 2000 20:41:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA16573; Tue, 19 Sep 2000 20:41:31 -0400 (EDT) Received: from mail.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA16558; Tue, 19 Sep 2000 20:41:28 -0400 (EDT) Received: from mail.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Tue, 19 Sep 2000 20:41:29 -0400 Received: by mail.mnot.net (Postfix, from userid 500) id 6A2DF976E; Tue, 19 Sep 2000 17:41:26 -0700 (PDT) Date: Tue, 19 Sep 2000 17:41:26 -0700 From: Mark Nottingham To: Joe Touch Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000919174124.A1719@mnot.net> References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39C800B3.66965AA4@isi.edu>; from touch@ISI.EDU on Tue, Sep 19, 2000 at 05:11:31PM -0700 List-Unsubscribe: On Tue, Sep 19, 2000 at 05:11:31PM -0700, Joe Touch wrote: > > The end-to-end principle applies to *network* layer functions; it is > > not meant to preclude an application-level gateway. > > The E2E principle applies to all services implemented at the endpoints, > not just transport. This includes reliable transfer, security, etc. > It does not preclude anything, per se. It merely says that > E2E services (e.g., reliable transport, app security, etc.) > cannot be composed _merely_ out of equivalent hop-by-hop services. Thanks; that makes it somewhat clearer to me. Although I've read the original paper, there's been a lot of bandying the term about, somewhat blurring its meaning in usage. > > Interception Proxies are Evil. > > The problem with interception proxies isn't breakage of E2E; > it's breakage of standard protocols. See > http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. Many have been explaining the Evils of interceptions proxies in this way, which is why I started from this angle. That having been said, I'm more interested in the effects below than these. Interception problems seem to have enough people concerned about them (although we still need to *do* something about them). In this respect, it was a poorly chosen subject line, but my perception was that these points were previously articulated as end-to-end problems. > > Proxies and surrogates can do a number of things to requests and > > responses as they flow through. I've been roughly classifying them > > as; > > > > - access control (e.g., blocking, filtering) > > - request modification (URI rewriting) > > - response modification (transcoding) > > Yes - and these are actually discussed in the original E2E paper. > This is basically value-added services. There are plenty of them. > > The E2E principle doesn't prohibit HBH services; it just > says HBH alone do not compose to yield E2E. It specifically > allows (if not encourages) HBH for performance enhancement, > with the caveat that it is also possible to degrade performance > if not done carefully. Of course; I wasn't suggesting that E2E prohibited application level gateways, etc., but that if current work goes forward without considering the social and legal effects of what they do, there will be trouble. > > It's interesting that Web caching seems to be losing ground to CDNs > > so rapidly; to me, this illustrates the point perfectly. Web caching > > was always performed in the interest of the access provider, not the > > content provider (or arguably even the user). As a result, content > > providers don't trust Web caches. What's it going to be like out > > there when access providers can slip a transcoding, rewriting module > > into a proxy on the fly? > > CDNs use web caches, don't they? or at least what do you call the > rented Akamai server? I call it a cache... > (CDN is just an economic model for charging the provider for space > on the cache) It's a surrogate which implements a cache. You've made my point well - Web caching isn't a good economic model, and even risked legal problems at one point, because it isn't done on behalf of the content provider. Rather, it is done by the access provider, who isn't concerned with cache correctness, etc. nearly as much as the content provider. Value-added services are a good thing, but there needs to be a framework to address these issues. While some content providers may not care that their content is transcoded by a proxy in front of the user, others may. For example, if a legal document is changed in any way (translated, summarized, etc.) it becomes invalid. The most oft-cited example that makes me shudder is the dynamic insertion/replacement of ads by the access provider, without permission of the content provider. While I'm sure there's a market for this out there, it brings up significant issues. I'm not sure that IETF is the best place to address this; W3C seems (to me) to have a more active view on social/legal issues. However, this is where these capabilities are being talked about, so it seemed a good starting point. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Wed Sep 20 06:15:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17155 for ; Wed, 20 Sep 2000 06:15:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA02417; Wed, 20 Sep 2000 06:11:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 06:10:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA02380; Wed, 20 Sep 2000 06:10:11 -0400 (EDT) Received: from relay1.alcatel.be (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA02367; Wed, 20 Sep 2000 06:10:07 -0400 (EDT) Received: from relay1.alcatel.be (195.207.101.119 -> alc119.alcatel.be) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 06:10:08 -0400 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e8KA9kv26149; Wed, 20 Sep 2000 12:09:47 +0200 (MET DST) Received: from alcatel.be ([138.203.66.49]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256960.0037AD96; Wed, 20 Sep 2000 12:08:09 +0200 Message-ID: <39C88C64.5ADF5D0@alcatel.be> Date: Wed, 20 Sep 2000 12:07:33 +0200 From: Jean-Sylvestre Gakwaya X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Nottingham CC: Joe Touch , WREC Working Group Subject: question about caching and replication References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I am a newbie in caching stuff :O) I have a very simplicist question :OS What is the relationship between replication and caching? I mean that to elaborate a caching mesh, or when a document is stale, problem of replication comes ... so, is there any protocol about interaction between both kind of protocols: caching and replication? Thanks in advance, Jean-Sylvestre Gakwaya, Alcatel employee From owner-wrec@cs.utk.edu Wed Sep 20 06:55:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17811 for ; Wed, 20 Sep 2000 06:55:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA04233; Wed, 20 Sep 2000 06:51:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 06:49:52 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA04138; Wed, 20 Sep 2000 06:49:51 -0400 (EDT) Received: from suncom.itep.ru (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA04125; Wed, 20 Sep 2000 06:49:42 -0400 (EDT) Received: from suncom.itep.ru (193.124.225.35 -> suncom.itep.ru) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 06:49:44 -0400 Received: from heron.itep.ru (root@heron.itep.ru [192.148.166.130]) by suncom.itep.ru (8.9.3/8.9.3) with ESMTP id OAA10807; Wed, 20 Sep 2000 14:51:14 +0400 Received: from heron.itep.ru (anovikov@venus.itep.ru [192.148.166.133]) by heron.itep.ru (8.9.3/8.9.3) with ESMTP id NAA08101; Wed, 20 Sep 2000 13:48:47 +0400 Sender: anovikov@heron.itep.ru Message-ID: <39C89612.95C66BD9@heron.itep.ru> Date: Wed, 20 Sep 2000 14:48:50 +0400 From: Alexei Novikov Organization: ITEP X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Sylvestre Gakwaya , WREC Working Group Subject: Re: question about caching and replication References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> <39C88C64.5ADF5D0@alcatel.be> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Jean-Sylvestre Gakwaya wrote: > > Hello all, > > I am a newbie in caching stuff :O) I have a very simplicist question :OS > What is the relationship between replication and caching? I mean that to > elaborate a caching mesh, or when a document is stale, problem of replication > comes ... so, is there any protocol about interaction between both kind of > protocols: caching and replication? > > Thanks in advance, Actually you can integrate replica (WWW or FTP mirror) in the caching mesh. It can be done quite easily with writing: 1) ICP daemon that will provide HITs or MISSes based on the knowledge of the replicated content. 2) Tool to create cachedigest file (for better scalability of the communications with the cachedigest enabled caches) 3) Module for the web server that will respond to the proxy requests with internal redirects to the replicated content. You can do this using Martin Hamilton's Perl modules WebCache:ICP and WebCache:Digest and <100 lines perl script for the Apache Web server. The good thing is that one can create such replicas with the authorization of the content provider (and under supervision), the bad is that ICP is poorly scalable. Alexei. From owner-wrec@cs.utk.edu Wed Sep 20 07:28:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18649 for ; Wed, 20 Sep 2000 07:28:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA07173; Wed, 20 Sep 2000 07:24:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 07:23:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA06880; Wed, 20 Sep 2000 07:23:08 -0400 (EDT) Received: from laptop44 (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA06844; Wed, 20 Sep 2000 07:22:29 -0400 (EDT) Received: from laptop44 (128.169.250.160 -> NCHM05A32.RMT.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 07:22:30 -0400 Message-ID: <001d01c022f5$447e8c90$0501a8c0@laptop44> From: "Micah Beck" To: "Alexei Novikov" , "Jean-Sylvestre Gakwaya" , "WREC Working Group" References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> <39C88C64.5ADF5D0@alcatel.be> <39C89612.95C66BD9@heron.itep.ru> Subject: Re: question about caching and replication Date: Wed, 20 Sep 2000 07:23:56 -0400 Organization: UT Computer Science Dept. MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: Content-Transfer-Encoding: 7bit Terminology in this context: replication = making a copy of the source object caching = capturing and replaying the server response Both have the effect of creating a new point of service (surrogate). /micah ----- Original Message ----- From: "Alexei Novikov" To: "Jean-Sylvestre Gakwaya" ; "WREC Working Group" Sent: Wednesday, September 20, 2000 6:48 AM Subject: Re: question about caching and replication > Jean-Sylvestre Gakwaya wrote: > > > > Hello all, > > > > I am a newbie in caching stuff :O) I have a very simplicist question :OS > > What is the relationship between replication and caching? I mean that to > > elaborate a caching mesh, or when a document is stale, problem of replication > > comes ... so, is there any protocol about interaction between both kind of > > protocols: caching and replication? > > > > Thanks in advance, > > Actually you can integrate replica (WWW or FTP mirror) in the caching > mesh. It can be done quite easily with writing: > 1) ICP daemon that will provide HITs or MISSes based on the knowledge of > the replicated content. > 2) Tool to create cachedigest file (for better scalability of the > communications with the cachedigest enabled caches) > 3) Module for the web server that will respond to the proxy requests > with internal redirects to the replicated content. > > You can do this using Martin Hamilton's Perl modules WebCache:ICP and > WebCache:Digest and <100 lines perl script for the Apache Web server. > > The good thing is that one can create such replicas with the > authorization of the content provider (and under supervision), the bad > is that ICP is poorly scalable. > > Alexei. > From owner-wrec@cs.utk.edu Wed Sep 20 12:56:43 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27352 for ; Wed, 20 Sep 2000 12:56:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA08825; Wed, 20 Sep 2000 12:52:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 12:51:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA08682; Wed, 20 Sep 2000 12:51:19 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA08669; Wed, 20 Sep 2000 12:51:17 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 12:51:17 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA19704; Wed, 20 Sep 2000 09:51:12 -0700 (PDT) Message-ID: <39C8EAEE.4BBA120D@isi.edu> Date: Wed, 20 Sep 2000 09:50:54 -0700 From: Joe Touch X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Mark Nottingham CC: WREC Working Group , ietf-openproxy@imc.org, touch@ISI.EDU Subject: Re: End to End thoughts [long] References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > On Tue, Sep 19, 2000 at 05:11:31PM -0700, Joe Touch wrote: > > > > Interception Proxies are Evil. > > > > The problem with interception proxies isn't breakage of E2E; > > it's breakage of standard protocols. See > > http://www.isi.edu/touch/pubs/hazards-outline.txt for further info. > > Many have been explaining the Evils of interceptions proxies in this way, > which is why I started from this angle. > > That having been said, I'm more interested in the effects below than these. > Interception problems seem to have enough people concerned about them > (although we still need to *do* something about them). In this respect, it > was a poorly chosen subject line, but my perception was that these points > were previously articulated as end-to-end problems. There certainly is room for work here. > Of course; I wasn't suggesting that E2E prohibited application level > gateways, etc., but that if current work goes forward without considering > the social and legal effects of what they do, there will be trouble. The IETF, far as I can tell, doesn't consider these issues, unless: 1. there are technical solutions somewhere underlying the social and/or legal AND 2. the legal issues constrain technical solutions i.e., solutions which are obviously not viable from the legal aspect are probably not worth spending time on technically > > > It's interesting that Web caching seems to be losing ground to CDNs > > > so rapidly; to me, this illustrates the point perfectly. Web caching > > > was always performed in the interest of the access provider, not the > > > content provider (or arguably even the user). As a result, content > > > providers don't trust Web caches. What's it going to be like out > > > there when access providers can slip a transcoding, rewriting module > > > into a proxy on the fly? > > > > CDNs use web caches, don't they? or at least what do you call the > > rented Akamai server? I call it a cache... > > (CDN is just an economic model for charging the provider for space > > on the cache) > > It's a surrogate which implements a cache. That's marketing doublespeak. It's a cache. > You've made my point well - Web > caching isn't a good economic model, and even risked legal problems at one > point, because it isn't done on behalf of the content provider. Rather, it > is done by the access provider, who isn't concerned with cache correctness, > etc. nearly as much as the content provider. > > Value-added services are a good thing, but there needs to be a framework to > address these issues. While some content providers may not care that their > content is transcoded by a proxy in front of the user, others may. > > For example, if a legal document is changed in any way (translated, > summarized, etc.) it becomes invalid. The primary problems with caching, in that sense, are: 1. content providers do not _want_ to provide expiration dates these dates must be determined in advance, and limit when changes will propagate. the CP's would like to 'recall' old items; this doesn't work with our current caching model, regardless of who runs the cache. the reason the CDNs are useful is that the CP's can push updated info out to the caches, in that sense 2. authentication is lacking CP's could sign their pages (e.g., PGP sign) again, there is disincentive, because it would inhibit user access (slow it down, stall it while waiting for key retrieval, etc) There is certainly a model for client-directed caching; several have worked just fine. Local premesis caching works if the organization is large (e.g., a school, a company, or a large ISP). Egress/ingress caching works on national scales, esp. where bandwidth is limited (e.g., Australia). The model is the same as TV and radio. People can decide what they want to see (e.g., PBS, request radio shows), but there is more money to be made by being advertiser-driven. E.g., I doubt people _want_ to watch infomercials all day long on the weekend, but there's money there. But you can buy pay-per-view or HBO and not have infomercials. People want to direct their cost (free); advertisers want to direct the content (and will pay). (but I digress - this may be an interesting coffeehouse chat at an upcoming IETF, though). > The most oft-cited example that makes me shudder is the dynamic > insertion/replacement of ads by the access provider, without permission of > the content provider. While I'm sure there's a market for this out there, it > brings up significant issues. Happens with local TV too. Without monitoring, it happens. > I'm not sure that IETF is the best place to address this; W3C seems (to > me) to have a more active view on social/legal issues. However, this is > where these capabilities are being talked about, so it seemed a good > starting point. These issues are addressed in the open court of public opinion, or in classes in business schools :-) Joe From owner-wrec@cs.utk.edu Wed Sep 20 13:04:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27707 for ; Wed, 20 Sep 2000 13:04:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA10237; Wed, 20 Sep 2000 13:00:57 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 12:59:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA10028; Wed, 20 Sep 2000 12:59:35 -0400 (EDT) Received: from omega.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA10010; Wed, 20 Sep 2000 12:59:33 -0400 (EDT) Received: from omega.cisco.com (171.69.63.141 -> omega.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 12:59:33 -0400 Received: from dli2-nt (dhcp-10-34-17-66.cisco.com [10.34.17.66]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA01836; Wed, 20 Sep 2000 09:59:30 -0700 (PDT) Message-Id: <4.2.0.58.20000920094807.01cac100@omega> X-Sender: lidan@omega X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 20 Sep 2000 10:00:55 -0700 To: "Micah Beck" , "Alexei Novikov" , "Jean-Sylvestre Gakwaya" , "WREC Working Group" From: Dan Li Subject: Re: question about caching and replication In-Reply-To: <001d01c022f5$447e8c90$0501a8c0@laptop44> References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> <39C88C64.5ADF5D0@alcatel.be> <39C89612.95C66BD9@heron.itep.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 07:23 AM 9/20/00 -0400, Micah Beck wrote: >Terminology in this context: > >replication = making a copy of the source object >caching = capturing and replaying the server response Moreover, replication implies object consistency, while caching offers no guarantee on freshness. So replication is inherently costlier/harder on the Internet, while on the other hand caching is increasingly unacceptable as the world embraces dynamic content. What the Internet needs is something in between, that offers guaranteed "delta consistency" and works in a CDN environment. We hope wrec will take it up as an initiative. Here is some work-in-progress: Abstract Cache consistency is a major impediment to scalable content delivery. This document describes the Web Cache Invalidation Protocol (WCIP) which uses invalidations and updates to keep changing objects up to date in web caches. Moreover, it allows automatic one-to-may relay and many-to-one aggregation in a CDN (content delivery network) environment. WCIP is an extension to HTTP. It runs between the invalidation server, the participating web caches, and channel relay points (if any). An invalidation server may maintain one or more invalidation channels, each of which cover a class of related objects. E.g., the CNNfn channel may contain web articles of the day's top financial news and stock quotes. Web caches subscribe to channel(s) they are interested in, while the invalidation server(s) send out invalidations and/or up-to-date objects to the channel(s). WCIP employs heartbeats to guarantee the freshness of the cached objects even under network or server failure. Moreover, WCIP can set up channel relay points via transparent caching, a cache hierarchy, or a CDN. A channel relay point performs application-layer multicast, i.e., channel relay (one-to-many) or channel aggregation (many-to-one). Thanks! Dan >Both have the effect of creating a new point of service (surrogate). >/micah > >----- Original Message ----- >From: "Alexei Novikov" >To: "Jean-Sylvestre Gakwaya" ; "WREC >Working Group" >Sent: Wednesday, September 20, 2000 6:48 AM >Subject: Re: question about caching and replication > > > > Jean-Sylvestre Gakwaya wrote: > > > > > > Hello all, > > > > > > I am a newbie in caching stuff :O) I have a very simplicist question :OS > > > What is the relationship between replication and caching? I mean that to > > > elaborate a caching mesh, or when a document is stale, problem of >replication > > > comes ... so, is there any protocol about interaction between both kind >of > > > protocols: caching and replication? > > > > > > Thanks in advance, > > > > Actually you can integrate replica (WWW or FTP mirror) in the caching > > mesh. It can be done quite easily with writing: > > 1) ICP daemon that will provide HITs or MISSes based on the knowledge of > > the replicated content. > > 2) Tool to create cachedigest file (for better scalability of the > > communications with the cachedigest enabled caches) > > 3) Module for the web server that will respond to the proxy requests > > with internal redirects to the replicated content. > > > > You can do this using Martin Hamilton's Perl modules WebCache:ICP and > > WebCache:Digest and <100 lines perl script for the Apache Web server. > > > > The good thing is that one can create such replicas with the > > authorization of the content provider (and under supervision), the bad > > is that ICP is poorly scalable. > > > > Alexei. > > From owner-wrec@cs.utk.edu Wed Sep 20 13:36:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28601 for ; Wed, 20 Sep 2000 13:36:24 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA15530; Wed, 20 Sep 2000 13:32:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 13:31:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA15378; Wed, 20 Sep 2000 13:31:10 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA15365; Wed, 20 Sep 2000 13:31:08 -0400 (EDT) Received: from 1-132.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 13:31:08 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id B66216601; Wed, 20 Sep 2000 13:34:03 -0700 (PDT) Date: Wed, 20 Sep 2000 13:34:03 -0700 From: Mark Nottingham To: Joe Touch Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000920133401.A890@mnot.net> References: <20000918201408.D2609@mnot.net> <39C800B3.66965AA4@isi.edu> <20000919174124.A1719@mnot.net> <39C8EAEE.4BBA120D@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39C8EAEE.4BBA120D@isi.edu>; from touch@ISI.EDU on Wed, Sep 20, 2000 at 09:50:54AM -0700 List-Unsubscribe: On Wed, Sep 20, 2000 at 09:50:54AM -0700, Joe Touch wrote: > The IETF, far as I can tell, doesn't consider these issues, unless: > > 1. there are technical solutions somewhere underlying > the social and/or legal > > AND > > 2. the legal issues constrain technical solutions > i.e., solutions which are obviously not viable > from the legal aspect are probably not worth > spending time on technically IMHO both conditions may be met; since there is a group actively discussing a framework to enable these functions, and there clearly are legal issues, even if the extent of those issues are unclear. I believe that there can be technical solutions to these problems, as it seems that there is other work in the IETF about trust models, etc. > > It's a surrogate which implements a cache. > > That's marketing doublespeak. It's a cache. Err, no, it's the terminology defined in the WREC Taxonomy. There can be significant differences in the cache implemented by a proxy and that implemented by a surrogate. > There is certainly a model for client-directed caching; several > have worked just fine. Local premesis caching works if the > organization is large (e.g., a school, a company, or a large ISP). > Egress/ingress caching works on national scales, esp. where > bandwidth is limited (e.g., Australia). There is a model, yes, but I'd debate that it's worked "just fine". Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Wed Sep 20 13:37:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28633 for ; Wed, 20 Sep 2000 13:37:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA16224; Wed, 20 Sep 2000 13:34:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 13:32:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA15589; Wed, 20 Sep 2000 13:32:37 -0400 (EDT) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA15535; Wed, 20 Sep 2000 13:32:33 -0400 (EDT) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 13:32:33 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 20 Sep 2000 11:04:01 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.4.1 Date: Wed, 20 Sep 2000 11:03:51 -0600 From: "Hilarie Orman" To: , Cc: Subject: Re: End to End thoughts [long] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28633 If you've already bought into NAT, then pointing to an interception proxy as "evil" is simply pot-kettle calling. I'd be quite happy to have application headers contain directives to intermediaries describing the semantics (esp. "stateless; copyrighted; cacheable", "multipart; modifiable by insertion", "opaque") and authorizations ("customizable by enduser", "insertions by brokers"). However, it's more realistic right now to accomplish this by context, environment, and what amount to service level agreements about content between publishers and distributors. I agree that there are problems associated with modifiable content, but there are also huge advantages. Some things really should look different depending on where they are in the network. It all depends on what you mean by content and what the intent of the publisher is. To take a minor example, in traditional publishing the consumer doesn't get to specify the color or size of the paper and the text fonts; with browsers and HTML, the user can override the publisher's specification. In the physical world, such tricks may well be illegal. We need to assure that publishers and consumers can specify and resolve their rights and preferences in protocols so that intermediaries can exercise their capabilities in accordance with their expectations. Hilarie >>> Mark Nottingham 09/18/00 09:14PM >>> There's been a lot of talk in various places about end-to-end problems, and their relation to intermediates (e.g., HTTP caching proxies, surrogates, etc.). Things have gotten somewhat religious. Rather than go down that road, I'd like to examine the issues and separate them into distinct problems. * Network Layer The end-to-end principle applies to *network* layer functions; it is not meant to preclude an application-level gateway. I _think_ that most everyone will agree that functions that break end-to-end transparency at the network layer cause problems. In other words, Interception Proxies are Evil. While it's nice to think that we can convince the world of this, it's more realistic to find out why people use them, and give them a better alternative. To my knowledge, most people use them because they need an easy way to assure that Web traffic (or at least port 80) goes through a proxy. While browser have proxy auto-configuration, it hasn't changed in quite a few years, there's no standard to implement, and it relies on JavaScript. WPAD was a good start; unfortunately, it never really went to far beyond Microsoft. Additionally, a more sensible, standard format for the configuration file would help. Over all of this, we need participation from the browser vendors, or we won't get anywhere. * Application Layer All of this being said, HTTP intermediates *do* raise issues at the application layer, which aren't end-to-end problems, but do get confused with them, as the causes are similar. Proxies and surrogates can do a number of things to requests and responses as they flow through. I've been roughly classifying them as; - access control (e.g., blocking, filtering) - request modification (URI rewriting) - response modification (transcoding) These operations are often performed in the interest of one of different parties: - content provider - access provider - user There have been numerous papers and discussions about the interesting things that can be done by intermediates. However, I don't think there's enough attention being paid to the problems that enabling these functions on intermediates can cause. * HTTP The HTTP makes a primary assumption of semantic transparency - that an entity body will not be changed 'in flight' - that, discounting transfer-encodings and so forth, what the server sends in the response is what the client gets. Jeff Mogul brought up issues with entity identity, as expressed in the ETag, in Lisbon. There was also general concern (it may have been Jeff in particular, my memory isn't that good) that an operation performed in one portion of the network may not be performed in another, causing unpredicatable behaviours. There are lots of other little examples here that should be covered, but I'll leave it for now. * URI One of the premises of URIs is that they refer to a specific, identifyable resource, and that the authority for that resource has control over it. Many applications have dependencies on this. PICS, Robots Exclusion, P3P, and other kinds of metadata systems break, sometimes disasterously, when intermediates change the semantics and/or payload of a message. The privacy implications are especially of concern. Overall, content providers have a reasonable expectation that the object which they deliver will be the one that the user gets, unless the user doesn't want it. These effects are largely social and legal; however, they're enabled by the technology that's being pushed out there. We need to reconcile the capabilities of the products and frameworks that we're building with the expectations that have been set by our base protocols. It's interesting that Web caching seems to be losing ground to CDNs so rapidly; to me, this illustrates the point perfectly. Web caching was always performed in the interest of the access provider, not the content provider (or arguably even the user). As a result, content providers don't trust Web caches. What's it going to be like out there when access providers can slip a transcoding, rewriting module into a proxy on the fly? One person who I've talked about this with pointed out the issues we had a while back in caches vs. copyright, legally. There's much more direct potential for problems here. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Wed Sep 20 13:56:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29068 for ; Wed, 20 Sep 2000 13:56:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA19108; Wed, 20 Sep 2000 13:51:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 13:50:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA18997; Wed, 20 Sep 2000 13:50:33 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA18983; Wed, 20 Sep 2000 13:50:29 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 13:50:30 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8KHoOe06392 env-from ; Wed, 20 Sep 2000 11:50:24 -0600 (MDT) Date: Wed, 20 Sep 2000 11:50:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200009201750.e8KHoOe06392@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: End to End thoughts [long] Cc: ietf-openproxy@imc.org List-Unsubscribe: > From: "Hilarie Orman" > To: , > Cc: > If you've already bought into NAT, then pointing to an interception > proxy as "evil" is simply pot-kettle calling. No, interception proxies are far worse than NAT. NAT merely breaks technical stuff. Interception proxies break all of the technical things that NAT boxes break and significantly more. E.g. AOL's SMTP redirection proxies probably break some addresses. Then interception proxies do really nasty non-technical things. They are open invitations for nasty non-technical things, from censorship to much easier snooping. For example, if some of the reports about the FBI's Carnivore are accurate, then AOL's SMTP interception proxies would far more easily and reliably do that job. > ... > To my knowledge, most people use them because they need an easy way (interception proxies) > to assure that Web traffic (or at least port 80) goes through a > proxy. ... A lot of people use various HTTP proxies, presumably including redirection proxies, to filter content. I know people who use them to "protect" their own children. (Never mind that I strongly disagree with them.) AOL's SMTP interception proxies are against spam. AOL adds header lines to SMTP messages and may filter objectionable content. Current rumors suggest that if AOL does filter SMTP on content with their SMTP redirection proxies, then they do it only by rate limiting. However, if they only rate limit, more than the censorship camel's nose is in the tent. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Wed Sep 20 14:00:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29157 for ; Wed, 20 Sep 2000 14:00:08 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA20090; Wed, 20 Sep 2000 13:56:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 13:54:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA19755; Wed, 20 Sep 2000 13:54:40 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA19742; Wed, 20 Sep 2000 13:54:37 -0400 (EDT) Received: from 1-132.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 13:54:37 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id BEE3B6601; Wed, 20 Sep 2000 13:57:33 -0700 (PDT) Date: Wed, 20 Sep 2000 13:57:33 -0700 From: Mark Nottingham To: Hilarie Orman Cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000920135732.B890@mnot.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from HORMAN@novell.com on Wed, Sep 20, 2000 at 11:03:51AM -0600 List-Unsubscribe: On Wed, Sep 20, 2000 at 11:03:51AM -0600, Hilarie Orman wrote: [...] > I'd be quite happy to have application headers contain directives > to intermediaries describing the semantics (esp. "stateless; copyrighted; > cacheable", "multipart; modifiable by insertion", "opaque") and authorizations > ("customizable by enduser", "insertions by brokers"). However, it's more > realistic right now to accomplish this by context, environment, and what > amount to service level agreements about content between > publishers and distributors. I very much agree. Right now, I think we're at a point where we can try to get a handle on what's acceptable without some form of negotiation. > I agree that there are problems associated with modifiable content, > but there are also huge advantages. Some things really should look > different depending on where they are in the network. It all depends > on what you mean by content and what the intent of the publisher > is. To take a minor example, in traditional publishing the consumer > doesn't get to specify the color or size of the paper and the text fonts; > with browsers and HTML, the user can override the publisher's > specification. In the physical world, such tricks may well be illegal. I won't dispute the benefits, but this does break some assumptions in the HTTP and URI specifications. We need to deal with that. > We need to assure that publishers and consumers can specify and > resolve their rights and preferences in protocols so that intermediaries can > exercise their capabilities in accordance with their expectations. Here's a more concrete example of the kind of problem I'm talking about: The W3C's P3P working group is putting together a platform which allows specification of an XML privacy policy based on a URI. The major mechanism for this is a metadata file in a well-known location at the origin server which dictates how policies are applied to resources. If a proxy inserts ads, rewrites URIs, or does something else to change the privacy attributes of the resource, the privacy policy is invalid. If the content provider doesn't know about this, they're making privacy guarantees for resources that are beyond their control. P3P is unaware of the potential for modification of an object in the network, because a URI points to an identifiable resource, and semantic transparency is assumed in the HTTP. While the HTTP doesn't specifically forbid lack of transparency, it does put limitations on how it may happen; Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed * only by an explicit protocol-level request when relaxed by client or origin server * only with an explicit warning to the end user when relaxed by cache or client There are many assumptions in efforts like P3P that will break when you break semantic transparency. I haven't brought this up in the WG yet, because I wanted to get comments from this group. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Wed Sep 20 15:15:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02330 for ; Wed, 20 Sep 2000 15:15:03 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA02838; Wed, 20 Sep 2000 15:11:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 15:09:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA02551; Wed, 20 Sep 2000 15:09:42 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA02535; Wed, 20 Sep 2000 15:09:40 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 15:09:41 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA03083; Wed, 20 Sep 2000 15:09:36 -0400 (EDT) Message-Id: <200009201909.PAA03083@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vernon Schryver cc: wrec@cs.utk.edu, ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] In-reply-to: Your message of "Wed, 20 Sep 2000 11:50:24 MDT." <200009201750.e8KHoOe06392@calcite.rhyolite.com> Date: Wed, 20 Sep 2000 15:09:36 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: good summary. interception proxies should really be illegal except when provided by the content-provider or by the end user. Keith From owner-wrec@cs.utk.edu Wed Sep 20 18:42:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10031 for ; Wed, 20 Sep 2000 18:42:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA27155; Wed, 20 Sep 2000 18:39:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 20 Sep 2000 18:37:37 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA27018; Wed, 20 Sep 2000 18:37:37 -0400 (EDT) Received: from nemo.corp.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA27004; Wed, 20 Sep 2000 18:37:35 -0400 (EDT) From: Received: from nemo.corp.equinix.com (207.20.85.157 -> somehost-5.equinix.net) by cs.utk.edu (smtpshim v1.0); Wed, 20 Sep 2000 18:37:35 -0400 Received: (from hardie@localhost) by nemo.corp.equinix.com (8.9.3/8.9.3) id PAA06084; Wed, 20 Sep 2000 15:37:17 -0700 (PDT) Message-Id: <200009202237.PAA06084@nemo.corp.equinix.com> Subject: Re: End to End thoughts [long] To: mnot@mnot.net (Mark Nottingham) Date: Wed, 20 Sep 2000 15:37:17 -0700 (PDT) Cc: HORMAN@novell.com (Hilarie Orman), wrec@cs.utk.edu, ietf-openproxy@imc.org In-Reply-To: <20000920135732.B890@mnot.net> from "Mark Nottingham" at Sep 20, 2000 01:57:33 PM Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit I've been trying to get a handle on how to express the problems I have with the framing of the end2end principal in this context. In the discussion below, Hilarie and Mark have obliquely pointed out where the problem lies: the distinction between service and protocol. The end2end principal derives from one of the most fundamental aspects of datagram networking, and it boils down to the notion that the end points of a network connection should be the only ones who need to care about the connection itself. The intermediate devices should be able to examine the datagram and know what to do (forward it somewhere, almost always), but they should not have to care about the connection between the two end points. The problem arises with the conflation of that network connection with a particular service provided on top of the network. It's an easy problem to have, because services have been historically provided at specific network nodes. Many URL schemes (and DNS names in general) resolve to specific nodes and specific ports, and the reason that so many people insert their service between the DNS request and the resolution is that that step is the closest one we have historically had to a service layer addressing scheme (yes, yes, SRVLOC exists--don't jump ahead). Once that resolution has taken place, though, most things boil down to a service layered on a end-to-end network connection. HTTP is a classic example of this: a unicast request/response protocol designed to make a local copy of a network-addressable resource. Making a local copy of a network-addressable resource is a pretty easy-to-describe service. The scaling problems with using that same unicast request/response protocol for every potential service on the network, though, have meant that more and more has been added to the protocol to support new service requirements or better support the scale of the existing service. As those got added in, that service ceased to be quite so easily layered on an end-to-end network connection. One early result of this was that the network addressable resource named in the HTTP URL might be provided by a node other than the node to which the address resolved; this was only the case, though, when a requestor had designated another node (a caching proxy) as a potential intermediate. Now service providers using HTTP also designate other nodes as potential agents (via surrogates and CDNs). With the service now being potentially provided through a chain that looks like: client--->caching proxy--->surrogate---->origin origin--->surrogate---->caching proxy--->client it's easy to see that the end2end connection between client and resource is not a necessary part of the service provision, even if the service provided is the same old making a local copy of a network addressable resource. There were, however, things you got for free when the client and the origin were the only parties to the service: freshness guarantees, some weak authentication, etc. Now they all those have to be made explicit. As Joe Touch has said, you can't substitute the aggregate of the hop-by-hop equivalents for an end2end connection. TLS between a client and a proxy, between the proxy and the surrogate and the surrogate and the origin does not add up to TLS between the client and the origin. As Vladis, Keith, and others have pointed out, one of the results of this is that modification can take place without the principal parties to the service being aware of that modification. That's bad, and we all know it. What we don't have a clear handle on is how to fix the problem without ripping out what we have now. I hope we can agree that we must substitute a service-based view of the applications for a connection-based view if we are to meet the current need. On a related note, I believe that one barrier to this at the moment is the continued use by the W3C of URLs as stand alone identifiers. As noted above, in some applications the resource named by a URL may be supplied by some other agent in the service; knowing that, the W3C has concluded that it is appropriate to use URLs as identifiers without reference to whether the resource is or is not available at that URL. Continuing to conflate a location and a resource once we have reached this point creates many more problems, in my view, than it can possibly solve. Working to create service addressing mechanisms that do not derive from network location seems to me a critical step to moving beyond application designs which presume the wrong things about service delivery. regards, Ted Hardie PS: If anyone reads the above as being a purist preaching, please understand that I am as big a sinner here as there is among us, and I am not trying to disavow the cruft for which I am personally responsible. > > On Wed, Sep 20, 2000 at 11:03:51AM -0600, Hilarie Orman wrote: > [...] > > I'd be quite happy to have application headers contain directives > > to intermediaries describing the semantics (esp. "stateless; copyrighted; > > cacheable", "multipart; modifiable by insertion", "opaque") and authorizations > > ("customizable by enduser", "insertions by brokers"). However, it's more > > realistic right now to accomplish this by context, environment, and what > > amount to service level agreements about content between > > publishers and distributors. > > I very much agree. Right now, I think we're at a point where we can try to > get a handle on what's acceptable without some form of negotiation. > > > > I agree that there are problems associated with modifiable content, > > but there are also huge advantages. Some things really should look > > different depending on where they are in the network. It all depends > > on what you mean by content and what the intent of the publisher > > is. To take a minor example, in traditional publishing the consumer > > doesn't get to specify the color or size of the paper and the text fonts; > > with browsers and HTML, the user can override the publisher's > > specification. In the physical world, such tricks may well be illegal. > > I won't dispute the benefits, but this does break some assumptions in > the HTTP and URI specifications. We need to deal with that. > > > > We need to assure that publishers and consumers can specify and > > resolve their rights and preferences in protocols so that intermediaries can > > exercise their capabilities in accordance with their expectations. > > > Here's a more concrete example of the kind of problem I'm talking about: > > The W3C's P3P working group is putting together a platform which allows > specification of an XML privacy policy based on a URI. The major mechanism > for this is a metadata file in a well-known location at the origin server > which dictates how policies are applied to resources. > > If a proxy inserts ads, rewrites URIs, or does something else to change the > privacy attributes of the resource, the privacy policy is invalid. If the > content provider doesn't know about this, they're making privacy guarantees > for resources that are beyond their control. > > P3P is unaware of the potential for modification of an object in the > network, because a URI points to an identifiable resource, and semantic > transparency is assumed in the HTTP. > > While the HTTP doesn't specifically forbid lack of transparency, it does put > limitations on how it may happen; > > Requirements for performance, availability, and disconnected operation > require us to be able to relax the goal of semantic transparency. The > HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly > reduce transparency when necessary. However, because non-transparent > operation may confuse non-expert users, and might be incompatible with > certain server applications (such as those for ordering merchandise), the > protocol requires that transparency be relaxed > > * only by an explicit protocol-level request when relaxed by client or > origin server > > * only with an explicit warning to the end user when relaxed by cache or > client > > There are many assumptions in efforts like P3P that will break when you > break semantic transparency. > > I haven't brought this up in the WG yet, because I wanted to get comments > from this group. > > -- > Mark Nottingham > http://www.mnot.net/ > From owner-wrec@cs.utk.edu Fri Sep 22 09:08:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13263 for ; Fri, 22 Sep 2000 09:08:15 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA10315; Fri, 22 Sep 2000 09:00:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 22 Sep 2000 08:57:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA09956; Fri, 22 Sep 2000 08:57:39 -0400 (EDT) Received: from localhost.localdomain (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA09943; Fri, 22 Sep 2000 08:57:28 -0400 (EDT) Received: from localhost.localdomain (216.73.149.66) by cs.utk.edu (smtpshim v1.0); Fri, 22 Sep 2000 08:57:28 -0400 Received: (from mcmanus@localhost) by localhost.localdomain (8.9.3/8.8.7) id TAA00798; Thu, 21 Sep 2000 19:40:31 -0400 Date: Thu, 21 Sep 2000 19:39:16 -0400 From: Patrick McManus To: Mark Nottingham Cc: WREC Working Group , ietf-openproxy@imc.org Subject: Re: End to End thoughts [long] Message-ID: <20000921193916.A791@appliedtheory.com> Reply-To: mcmanus@appliedtheory.com References: <20000918201408.D2609@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000918201408.D2609@mnot.net>; from mnot@mnot.net on Mon, Sep 18, 2000 at 08:14:08PM -0700 List-Unsubscribe: [Mark Nottingham: Mon, Sep 18, 2000 at 08:14:08PM -0700] > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. I think your conclusion doesn't go far enough. I completely agree that caching is moving from a information consumer to information provider driven model, but I think this is because of both a lack of trust on the part of the information provider (as you assert) and a desire to see more thorough deployments. Information consumers, in many situations, didn't have sufficient motivation to deploy the infrastructure that the providers do and this limited the breadth of installations. CDN as an extension of hosting has really come, and I suspect will be with us for a while.. it makes interesting economic models available as choices.. (can I go with a bargain basement origin hosting facility if I have a decent CDN? Probably depends on your content..) -P From owner-wrec@cs.utk.edu Fri Sep 22 14:14:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22475 for ; Fri, 22 Sep 2000 14:14:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA18652; Fri, 22 Sep 2000 14:10:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 22 Sep 2000 14:09:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA18463; Fri, 22 Sep 2000 14:09:13 -0400 (EDT) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA18442; Fri, 22 Sep 2000 14:09:05 -0400 (EDT) Received: from prv-mail20.provo.novell.com (137.65.81.122 -> prv-mail20.provo.novell.com) by cs.utk.edu (smtpshim v1.0); Fri, 22 Sep 2000 14:09:06 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Fri, 22 Sep 2000 12:08:57 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 22 Sep 2000 12:08:53 -0600 From: "Hilarie Orman" To: , Cc: , Subject: Re: End to End thoughts [long] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22475 Choosing a deployment method depends on the cost of the bandwidth. It comes down to a minimization problem. That's the original motivation for caching/replication and will always be a critical part of Internet scalability. It's interesting to compare this to the evolution of distribution of other forms of content, historically. New technology rolls through the same set of economic forces as the old. An important question that Andrew Odlyzko of ATT Research has been noting for some time, is that historically there is a greater economic incentive for person-person communication that for content distribution, and therefore, it may be more important to engineer infrastructure for the former rather than the latter. Hilarie >>> Patrick McManus 09/21/00 05:39PM >>> [Mark Nottingham: Mon, Sep 18, 2000 at 08:14:08PM -0700] > It's interesting that Web caching seems to be losing ground to CDNs > so rapidly; to me, this illustrates the point perfectly. Web caching > was always performed in the interest of the access provider, not the > content provider (or arguably even the user). As a result, content > providers don't trust Web caches. I think your conclusion doesn't go far enough. I completely agree that caching is moving from a information consumer to information provider driven model, but I think this is because of both a lack of trust on the part of the information provider (as you assert) and a desire to see more thorough deployments. Information consumers, in many situations, didn't have sufficient motivation to deploy the infrastructure that the providers do and this limited the breadth of installations. CDN as an extension of hosting has really come, and I suspect will be with us for a while.. it makes interesting economic models available as choices.. (can I go with a bargain basement origin hosting facility if I have a decent CDN? Probably depends on your content..) -P From owner-wrec@cs.utk.edu Wed Sep 27 12:54:54 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16618 for ; Wed, 27 Sep 2000 12:54:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA17417; Wed, 27 Sep 2000 12:50:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 27 Sep 2000 12:48:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA17194; Wed, 27 Sep 2000 12:48:44 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA17165; Wed, 27 Sep 2000 12:48:41 -0400 (EDT) Received: from 1-132.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Wed, 27 Sep 2000 12:48:41 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id 616EB6601; Wed, 27 Sep 2000 09:48:39 -0700 (PDT) Date: Wed, 27 Sep 2000 09:48:39 -0700 From: Mark Nottingham To: WREC Working Group , ietf-openproxy@imc.org Subject: [Internet-Drafts@ietf.org: I-D ACTION:draft-nottingham-cache-extensions-00.txt] Message-ID: <20000927094837.A1064@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i List-Unsubscribe: This is a draft of something I helped cook up at my previous job, with a cache vendor. Some people have been asking for this type of functionality recently, so here it is (much delayed). Cheers, ----- Forwarded message from Internet-Drafts@ietf.org ----- Date: Wed, 27 Sep 2000 06:31:15 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-nottingham-cache-extensions-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HTTP Cache Control Extensions for Direct Cache Manipulation Author(s) : M. Nottingham Filename : draft-nottingham-cache-extensions-00.txt Pages : 5 Date : 25-Sep-00 HTTP/1.1 provides for extensions to Cache-Control headers, which provide new methods of controlling caches. This document specifies extensions which allow content providers more precise control over shared caches. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nottingham-cache-extensions-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nottingham-cache-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nottingham-cache-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Thu Sep 28 03:28:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14432 for ; Thu, 28 Sep 2000 03:28:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA06122; Thu, 28 Sep 2000 03:24:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 28 Sep 2000 03:22:59 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA05948; Thu, 28 Sep 2000 03:22:59 -0400 (EDT) Received: from mx.boston.juno.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA05754; Thu, 28 Sep 2000 03:21:26 -0400 (EDT) From: Received: from mx.boston.juno.com (216.214.109.150 -> tnt1a-150.newyork.corecomm.net) by cs.utk.edu (smtpshim v1.0); Thu, 28 Sep 2000 03:21:44 -0400 Subject: from:mark,you filled out a chance to win free phone service Date: Thu, 28 Sep 2000 03:09:16 Message-Id: <777.358630.818769@mx.boston.juno.com> To: undisclosed-recipients:; List-Unsubscribe: This is not a Spam ,I RECIEVEED YOUR EMAIL FROM A POSTED WEB SITE. I went to the web site in your country, I'm the Representative for all calls going to your country.I beleive I can save you alot of money.This letter is intended for people in your country only These rates can only be offered to people out side USA, the rate I give you is a special rate only for You.IF you want conformation about the rates email me and I Will confirm the rate for you. I promise ,I WILL CUT YOUR PHONE BILL IN 1/2 IF YOU JUST GIVE ME A CHANCE!! AT&T,SPRINT and MCI long distance carriers are getting rich off of You and ME ! Please take a look at my rates, I'm sure I will beat their price. There are no monthly or minimum fees or any other hidden costs. You just pay for the time your are on the phone. If your paying less,I will beat what your paying no matter what !!!!!! For a complete rate chart and sign-up info http://www.hometown.aol.com/cheaprates99 -----CLICK HERE--- http://www.hometown.aol.com/cheaprates99 Example: Germany .05+ USA .05 =.10 per minute Country Code Per Minute Algeria-------------------------213 0.26 American Samoa------------------684 0.16 Andorra-------------------------336 0.17 Angola--------------------------244 0.36 Anguilla------------------------264 0.34 Antigu--------------------------268 0.40 Aruba---------------------------297 0.26 Bahamas-------------------------242 0.16 Bangladesh----------------------880 0.64 Barbados------------------------246 0.42 Belize--------------------------501 0.51 Bermuda-------------------------441 0.16 Brazil 51 0.10 Canada-------------------------- 0.07 Cape Verde---------------------238 0.43 Caymans-------------------------345 0.26 Dominica------------------------767 0.44 Dominican Rep.------------------809 0.14 Egypt---------------------------20 0.51 France--------------------------33 0.06 Germany-------------------------49 0.05 Grand Turk----------------------649 0.44 Grenada-------------------------473 0.42 Jordan--------------------------962 0.51 Lebanon*------------------------961 0.40 Malaysia------------------------ 60 0.10 Papua New Guinea---------------675 0.31 Sweden---------------------------46 0.04 Saudi Arabia-------------------966 0.39 Singapore------------------------65 0.08 St Helena-----------------------290 0.59 St Kitts------------------------869 0.35 St Lucia------------------------758 0.42 St Pierre-----------------------508 0.22 St Vincent----------------------784 0.42 Trinidad------------------------868 0.47 U S Virgin----------------------340 0.07 United Arab Emirates-----------971 0.17 United Kingdom------------------44 0.05 USA-----------------------------1 0.05 Add the country you're calling from to the country you're calling, to get the rate per minute Rates apply 24 hrs/day, 7 days per week NO sign-up fees, NO monthly fees, and NO surcharges You DO NOT have to SWITCH your current provider Ideal for Home and Business use Callback service is available to/from anywhere in the world. Contact us for more information and complete rate table at: mailto:cheaprates1234@earthlink.net http://hometown.aol.com/cheaprates99 If you would like to be removed from our list, please reply to: callback1234@earthlink.net with the word "remove" in the subject line. **************************************************** Re: From Lorraine,as I promised about your bill.