From owner-wrec@cs.utk.edu Fri Apr 7 04:52:37 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04846 for ; Fri, 7 Apr 2000 04:52:36 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA23281; Fri, 7 Apr 2000 04:47:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 7 Apr 2000 04:47:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA23262; Fri, 7 Apr 2000 04:47:20 -0400 (EDT) Received: from tyholt.uninett.no (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA23240; Fri, 7 Apr 2000 04:47:16 -0400 (EDT) Received: from tyholt.uninett.no (158.38.60.10 -> tyholt.uninett.no) by cs.utk.edu (smtpshim v1.0); Fri, 7 Apr 2000 04:47:16 -0400 Received: from bakke.uninett.no (IDENT:im@bakke.uninett.no [158.38.60.84]) by tyholt.uninett.no (8.9.3/8.8.8) with ESMTP id KAA24236 for ; Fri, 7 Apr 2000 10:47:09 +0200 (METDST) Message-Id: <200004070847.KAA24236@tyholt.uninett.no> X-Mailer: exmh version 2.1.1 10/15/1999 To: wrec@cs.utk.edu Subject: recommendation against publication of draft-cerpa-necp-02.txt (fwd) MIME-Version: 1.0 Content-Type: message/rfc822 Content-ID: <2654.955097228.1@bakke.uninett.no> Content-Description: forwarded message Date: Fri, 07 Apr 2000 10:47:09 +0200 From: Ingrid Melve List-Unsubscribe: Return-Path: owner-ietf+censored@dokka.maxware.no Delivery-Date: Thu Apr 6 19:21:21 2000 Return-Path: Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by tyholt.uninett.no (8.9.3/8.8.8) with ESMTP id TAA08858; Thu, 6 Apr 2000 19:21:20 +0200 (METDST) Received: (from majordomo@localhost) by dokka.maxware.no (8.9.3/8.9.3) id TAA30366 for ietf+censored-list; Thu, 6 Apr 2000 19:15:38 +0200 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA30361 for ; Thu, 6 Apr 2000 19:15:29 +0200 Received: by ietf.org (8.9.1a/8.9.1a) id MAA11210 for ietf-outbound.09@ietf.org; Thu, 6 Apr 2000 12:50:03 -0400 (EDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11003; Thu, 6 Apr 2000 12:42:31 -0400 (EDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA15198; Thu, 6 Apr 2000 12:41:33 -0400 (EDT) Message-Id: <200004061641.MAA15198@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: rfc-ed@rfc-editor.org Subject: recommendation against publication of draft-cerpa-necp-02.txt cc: moore@cs.utk.edu, iesg@ietf.org, ietf@ietf.org From: Keith Moore Date: Thu, 06 Apr 2000 12:41:33 -0400 X-Loop: ietf@ietf.org Precedence: bulk List-Unsubscribe: X-Filter-Ruleset: ietf+censored 17 MIME-Version: 1.0 I am writing to request that the RFC Editor not publish draft-cerpa-necp-02.txt as an RFC in its current form, for the following reasons: 1. The document repeatedly, and misleadingly, refers to NECP as a standard. I do not believe this is appropriate for a document which is not on the IETF standards track. It also refers to some features as "mandatory" even though it's not clear what it means for a non-standard to have mandatory features. 2. A primary purpose of the NECP protocol appears to be to facilitate the operation of so-called interception proxies. Such proxies violate the Internet Protocol in several ways: (1) they redirect traffic to a destination other than the one specified in the IP header, (2) they impersonate other IP hosts by using those hosts' IP addresses as source addresses in traffic they generate, (3) for some interception proxies, traffic which is passed on to the destination host, is modified in transit, and any packet-level checksums are regenerated. IP allows for the network to delay, drop, or duplicate IP packets, as part of a best effort to route them to their intended destination. But it does not allow the above practices. This document implicitly treats such behavior as legitimate even though it violates the primary standard on which all Internet interoperability depends. 3. Aside from the technical implications of intercepting traffic, redirecting it to unintended destinations, or forging traffic from someone else's IP address - there are also legal, social, moral and commercial implications of doing so. In my opinion IETF should not be lending support to such dubious practices by publishing an RFC which implicitly endorses them, even though the authors are employed by major research institutions and hardware vendors. 4. Furthermore, while any of the above practice might be deemed "morally" acceptable in limited circumstances (such as when the interception proxy is being operated by the same party as the one which operates the host being impersonated) in general these are very dangerous. There have been numerous cases where network elements employing practices similar to the above have been demonstrated to harm interoperability. (e.g. there is a widely-used SMTP firewall product which breaks SMTP extension negotiation, and a traffic shaping product was recently found to corrupt data in TCP streams generated by certain kinds of hosts) This document contains language touting the benefits of NECP but very little language describing the danger of using the above techniques which NECP was designed to support. Where the document does mention the problems, it is misleading or incomplete. For example, the Introduction says However, it [an interception proxy] can cause problems: users have no way to go directly to origin servers, as may be required in some cases (e.g., servers that authenticate using a client's source IP address). The proxy has a high-level understanding of the application protocol; it can detect these cases and decide which flows should be cut through to origin servers. The latter sentence is a false assertion - even though the proxy has a high level understanding of the protocol, the proxy is not generally able to determine when cut-through is required. For example, the service being impersonated by the interception proxy may have uses for the client's source address which are outside of the protocol being intercepted and for which the proxy cannot be knowledgable. Such uses may be both active (in that they involve attempts to establish other traffic between the origin server and the client, or between the client and other hosts on the network), or passive (in which the origin server uses the client's IP address without attempting to communicate with it), or even deferred (in which an attempt is made to communicate with the client's IP address at a later time). In addition, the *user* may have a requirement for his client to talk directly to an origin server, or the content provider may have a requirement for the origin server to talk directly to a client, simply because they expect communications integrity. By its very nature an interception proxy ignores the requirements of the user and/or the content provider. The document refers to two other documents which it says further describe the dangers of interception proxies: "Internet Web Replication and Caching Taxonomy" [reference 3], and "Known HTTP Proxy/Caching Problems". Both of these appear to be works in progress, and the latter document does not even have a reference. Until such documents are published, or at least until they are deemed ready for publication by their creators, it is impossible to evaluate whether they contain sufficient and accurate information to inform readers of the NECP document about the dangers of interception proxies. 5. While in one sense NECP is an attempt to alleviate some of the harm done by interception proxies, this document is clearly intended to encourage and promote the use of such proxies by providing a uniform cross-vendor interface between such proxies and network elements. Given that NECP is intended to support violations of the Internet Protocol, and that such violations are known to harm interoperability, such promotion is a misuse of the RFC document series. In summary, my recommendation is that the document not be published until: - the promotional material is removed, leaving only technical justification and specification - the document is changed to point out that interception proxies are nonstandard, that they violate the Internet Protocol, and that they are known to degrade interoperability - a disclaimer is added, which points out that interception proxies are engaged in interception, misrepresentation, and forgery of network traffic, that such practices are not endorsed by IETF, and that they may be illegal in some jurisdictions. - the documents describing the dangers of interception proxies which are referenced by the NECP document are ready for publication, and are deemed reasonably complete and accurate. But I would also recommend that the document not be published at all, as I believe that publication of this document will do far more to degrade the interoperability of the Internet than it can do to help it. There may indeed be value in publishing the document as a contribution to the historic record of Internet development, as it certainly reflects some current trends. However this goal could be accomplished by delaying publication of the NECP document by several years, or at least, until the publication of technically sound, standardized, solutions for the problems that interception proxies attempt to address. best regards, Keith Moore - This message was passed through ietf+censored@alvestrand.no, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand. From owner-wrec@cs.utk.edu Wed Apr 12 16:46:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03018 for ; Wed, 12 Apr 2000 16:46:34 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA15154; Wed, 12 Apr 2000 16:37:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 12 Apr 2000 16:37:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA15135; Wed, 12 Apr 2000 16:37:38 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA15121; Wed, 12 Apr 2000 16:37:36 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Wed, 12 Apr 2000 16:37:36 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02963 for ; Wed, 12 Apr 2000 13:37:34 -0700 (PDT) Message-ID: <38F4DE6B.80837A11@isi.edu> Date: Wed, 12 Apr 2000 13:36:59 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: wrec@cs.utk.edu Subject: [Fwd: interception proxies] Content-Type: multipart/mixed; boundary="------------BF64761BE29F257CCC321E1C" List-Unsubscribe: This is a multi-part message in MIME format. --------------BF64761BE29F257CCC321E1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------BF64761BE29F257CCC321E1C Content-Type: message/rfc822 Content-Disposition: inline Delivery-Date: Tue, 11 Apr 2000 18:03:54 -0700 Return-Path: owner-ietf-outbound@ietf.org Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id SAA07145; Tue, 11 Apr 2000 18:03:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA25265; Tue, 11 Apr 2000 18:03:51 -0700 (PDT) Received: by ietf.org (8.9.1a/8.9.1a) id UAA24831 for ietf-outbound.06@ietf.org; Tue, 11 Apr 2000 20:30:02 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24515 for ; Tue, 11 Apr 2000 20:10:32 -0400 (EDT) Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id RAA00529; Tue, 11 Apr 2000 17:10:29 -0700 (PDT) Message-ID: <38F3BED4.26704EFD@isi.edu> Date: Tue, 11 Apr 2000 17:09:56 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Keith Moore CC: Vernon Schryver , ietf@ietf.org Subject: Re: interception proxies References: <200004112359.TAA07437@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii X-Loop: ietf@ietf.org Content-Transfer-Encoding: 7bit FWIW, there _was_ discussion in WREC of the hazards of transparent web caching. I dug up an old e-mail, describing the hazards of transparent web caching which I summarized at the time, when WREC was forming. A copy of the note, admittedly very rough (just an outline, and a very rough one at that) is at: http://www.isi.edu/touch/pubs/hazards-outline.txt I would be glad to host further discussion on the WREC maillist as to how to augment the list and flesh it out to a full I-D before the next IETF, if there is sufficient interest. Joe --------------BF64761BE29F257CCC321E1C-- From owner-wrec@cs.utk.edu Wed Apr 12 16:46:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03029 for ; Wed, 12 Apr 2000 16:46:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA15007; Wed, 12 Apr 2000 16:37:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 12 Apr 2000 16:37:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA14989; Wed, 12 Apr 2000 16:37:11 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA14973; Wed, 12 Apr 2000 16:37:08 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Wed, 12 Apr 2000 16:37:08 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA02675; Wed, 12 Apr 2000 13:37:02 -0700 (PDT) Message-ID: <38F4DE4B.19597105@isi.edu> Date: Wed, 12 Apr 2000 13:36:27 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vernon Schryver CC: ietf@ietf.org Subject: Re: interception proxies References: <200004120504.XAA05262@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > My impression from the two WG documents is that in the WG consensus is > that HTTP interception proxies are at least tolerable and often necessary > and good, and by extension probably also for SMTP and everything else. The arch document defines, it doesn't condone or condemn. As to the known-probs doc, that focuses on problems of the sort that TCPIMPL did - errors in the implementation, not deliberately changing specs. > Yes, I noticed that "W" in "WREC" doesn't stand for "mail". It's also > clear that intercepting or proxying are at most aspects of the "RE" and > the "C", although I don't see how that is relevant to whether the WG is > committed to interception proxies. Intercepting is also done in other contexts: - DNS - email - TCP for relay over subnets e.g., over wireless or intermittently-connected links > Yes, I realize that draft wasn't a product of the WREC WG. The two WREC > documents cannot be read as deprecating interception proxies and can be > read as advocating them by what they fail to say. I do not agree with this statement. Failing to condemn cannot be taken as an endorsement. It means only that the documents define, rather than compare or advocate, architectural components. > ] From: Joe Touch > > ] FWIW, there _was_ discussion in WREC of the hazards of transparent web > ] caching. I dug up an old e-mail, describing the hazards of transparent > ] web caching which I summarized at the time, when WREC was forming. > ] > ] A copy of the note, admittedly very rough (just an outline, and a very > ] rough one at that) is at: > ] > ] http://www.isi.edu/touch/pubs/hazards-outline.txt > > I really like "in effect, it is a use of IP spoofing to do replay attacks." > > (Why a 3rd document instead of added to Problems?) Because problems focuses on errors of implementation, not of architectural design. I would advocate that there is the need for a separate statement on design in this case. > ] I would be glad to host further discussion on the WREC maillist as to > ] how to augment the list and flesh it out to a full I-D before the next > ] IETF, if there is sufficient interest. > > Do you two think that either the IETF or the WREC working group might > agree with the thrust of that outline? It sounds as if your answer is > "yes" and that my sense of WREC, IETF, and maybe industry sentiment is > wrong. I'll take that over to WREC, and we can have that discussion there first. Joe From owner-wrec@cs.utk.edu Wed Apr 12 17:00:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03333 for ; Wed, 12 Apr 2000 17:00:53 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA17462; Wed, 12 Apr 2000 16:52:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 12 Apr 2000 16:52:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA17444; Wed, 12 Apr 2000 16:52:09 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA17431; Wed, 12 Apr 2000 16:52:07 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Wed, 12 Apr 2000 16:52:08 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA05406; Wed, 12 Apr 2000 13:52:03 -0700 (PDT) Message-ID: <38F4E1D0.20A08E0B@isi.edu> Date: Wed, 12 Apr 2000 13:51:28 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf@ietf.org, wrec@cs.utk.edu Subject: Re: interception proxies References: <200004121433.KAA11030@angels.heaven.net> <14580.47617.154623.427207@saint.heaven.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit "Dick St.Peters" wrote: > > Would you settle for "The IP spec authors didn't have enough foresight > to foresee a need to rewrite source addresses" ? :) > > Whatever anyone thinks of it, people are doing it. On the right are > people saying it is immoral, evil, and dangerous, not to mention > prohibited by the gods, and they refuse to talk about it. On the left > are people doing it, each their own way because there is no standard > and not even any public discussion. Intercepting connections and sourcing packets with addresses not owned by you (or within your stub subnet) violates one of the few standards we have (STD003 - the combination of RFCs 1122 and 1123). Intercepting connections by rewriting IP headers in a gateway violates a proposed staandard (RFC 1812). It is not immoral, evil or dangerous; there are standards (existing and proposed), and they are being violated. Joe From owner-wrec@cs.utk.edu Wed Apr 12 20:35:28 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05814 for ; Wed, 12 Apr 2000 20:35:28 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA03580; Wed, 12 Apr 2000 20:27:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 12 Apr 2000 20:27:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA03562; Wed, 12 Apr 2000 20:27:11 -0400 (EDT) Received: from raptor.ebuilt.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA03540; Wed, 12 Apr 2000 20:27:07 -0400 (EDT) Received: from raptor.ebuilt.net (216.237.34.38) by cs.utk.edu (smtpshim v1.0); Wed, 12 Apr 2000 20:27:07 -0400 Received: from mana (darth-vader.ebuilt.com [216.237.34.33]) by raptor.ebuilt.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2XTSAGV9; Wed, 12 Apr 2000 17:26:47 -0700 From: "Roy T. Fielding" To: Subject: surrogates are not tunnels Date: Wed, 12 Apr 2000 17:23:37 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal List-Unsubscribe: Content-Transfer-Encoding: 7bit The definition of surrogate in http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-03.txt surrogate (a.k.a. "reverse proxies", "web server accelerators") An intermediary program which acts as a server or tunnel for the purpose of responding to requests on behalf of one or more origin servers. Requests are serviced internally from a cache or by tunnelling them on to origin servers. The implementation requirements for surrogates have not been standardized; depending on the implementation, surrogates may or may not respond to the cache directives defined in [1] . Surrogates are also known as "reverse proxies" and "(origin) server accelerators". is not accurate because it refers to "tunnelling". A surrogate does not tunnel requests -- it forwards them. Likewise, the content may be transformed or redirected in the process. Note that it is impossible for an HTTP tunnel to cache responses. HTTP defines these things as "gateways". While I understand the reluctance to use such an overloaded term, there is no way to avoid including all aspects of an HTTP-to-HTTP gateway when defining this new term, unless you want to add more restrictive requirements (such as: "surrogates" only applies to HTTP-to-HTTP gateways, or perhaps only non-transforming HTTP-to-HTTP gateways). The implementation requirements for HTTP-aware "surrogates" have been standardized. They are all the requirements for gateways in HTTP. Changing the name doesn't change those requirements. Changing the name doesn't make the currently broken implementations of "reverse proxies" any more compliant with HTTP. ........................................................................... Roy T. Fielding fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 2652 McGaw Ave. fax:+1.949.609.0001 Irvine, CA 92614-5840 USA http://www.eBuilt.com ........................................................................... From owner-wrec@cs.utk.edu Wed Apr 12 21:14:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06231 for ; Wed, 12 Apr 2000 21:14:29 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA07378; Wed, 12 Apr 2000 21:06:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 12 Apr 2000 21:06:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA07360; Wed, 12 Apr 2000 21:05:59 -0400 (EDT) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA07334; Wed, 12 Apr 2000 21:05:54 -0400 (EDT) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 12 Apr 2000 21:05:54 -0400 Received: (from hardie@localhost) by kiwi.equinix.com (8.9.3/8.9.3) id SAA15133; Wed, 12 Apr 2000 18:05:42 -0700 (PDT) Message-Id: <200004130105.SAA15133@kiwi.equinix.com> Subject: Re: surrogates are not tunnels To: fielding@ebuilt.com (Roy T. Fielding) Date: Wed, 12 Apr 2000 18:05:42 -0700 (PDT) Cc: wrec@cs.utk.edu In-Reply-To: from "Roy T. Fielding" at Apr 12, 2000 05:23:37 PM From: hardie@equinix.com Reply-to: hardie@equinix.com X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Roy, Surrogates are network elements which act on behalf of an origin server and either service a request from a cache or pass the request on to the origin server. In some implementations, the surrogates are truly tunnels when they pass the requests on, as they pass the request on unmodified and either do not interact with the reply (even to cache it) or are not in the data path of the reply. You are certainly correct that gateway is an overloaded term, as are cache and proxy. I first floated the term surrogate in order to try to capture the flavor of "proxy" while escaping some of the baggage. This wasn't an attempt to get out of meeting the requirements for specific participants in an HTTP exchange, but to try to focus on the fact that a network element acting on behalf of an origin server had different characteristics from other participants. It may well be that a surrogate that is implemented as a gateway should follow the rules set forth for gateways, but there are other possible implementations and other issues which are less understood. If you have followed the IETF list over the past burst of traffic related NECP, you will have seen a lot of comments indicating that hosts acting on behalf of origin servers are a "local matter" and not subject to standardization. That may be, but I believe we need to engage in some pretty thorough study of exactly how they interact with other potential participants in the HTTP request/response stream. Mark Nottingham of Akamai has a paper entitled "On Defining a Role for Demand-Driven Surrogate Origin Servers" at the next WCW, and you may want to talk to him about his take on the issue as well. regards, Ted Hardie > > The definition of surrogate in > http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-03.txt > > surrogate (a.k.a. "reverse proxies", "web server accelerators") > An intermediary program which acts as a server or tunnel for the > purpose of responding to requests on behalf of one or more origin > servers. Requests are serviced internally from a cache or by > tunnelling them on to origin servers. The implementation > requirements for surrogates have not been standardized; depending > on the implementation, surrogates may or may not respond to the > cache directives defined in [1] . Surrogates are also known as > "reverse proxies" and "(origin) server accelerators". > > is not accurate because it refers to "tunnelling". A surrogate does > not tunnel requests -- it forwards them. Likewise, the content may be > transformed or redirected in the process. Note that it is impossible > for an HTTP tunnel to cache responses. > > HTTP defines these things as "gateways". While I understand the > reluctance to use such an overloaded term, there is no way to avoid > including all aspects of an HTTP-to-HTTP gateway when defining this > new term, unless you want to add more restrictive requirements > (such as: "surrogates" only applies to HTTP-to-HTTP gateways, or > perhaps only non-transforming HTTP-to-HTTP gateways). > > The implementation requirements for HTTP-aware "surrogates" have been > standardized. They are all the requirements for gateways in HTTP. > Changing the name doesn't change those requirements. Changing the name > doesn't make the currently broken implementations of "reverse proxies" > any more compliant with HTTP. > > ........................................................................... > Roy T. Fielding fielding@ebuilt.com > eBuilt, Inc. tel:+1.949.609.0000 > 2652 McGaw Ave. fax:+1.949.609.0001 > Irvine, CA 92614-5840 USA http://www.eBuilt.com > ........................................................................... > From owner-wrec@cs.utk.edu Thu Apr 13 01:10:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11993 for ; Thu, 13 Apr 2000 01:10:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA20478; Thu, 13 Apr 2000 01:02:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 13 Apr 2000 01:02:51 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA20460; Thu, 13 Apr 2000 01:02:50 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA20432; Thu, 13 Apr 2000 01:02:45 -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); Thu, 13 Apr 2000 01:02:46 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id 22C7C6600; Wed, 12 Apr 2000 22:02:44 -0700 (PDT) Date: Wed, 12 Apr 2000 22:02:44 -0700 From: Mark Nottingham To: "Roy T. Fielding" Cc: wrec@cs.utk.edu Subject: Re: surrogates are not tunnels Message-ID: <20000412220243.A25032@mnot.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: ; from fielding@ebuilt.com on Wed, Apr 12, 2000 at 05:23:37PM -0700 List-Unsubscribe: On Wed, Apr 12, 2000 at 05:23:37PM -0700, Roy T. Fielding wrote: > The definition of surrogate in > http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-03.txt > > surrogate (a.k.a. "reverse proxies", "web server accelerators") > An intermediary program which acts as a server or tunnel for the > purpose of responding to requests on behalf of one or more origin > servers. Requests are serviced internally from a cache or by > tunnelling them on to origin servers. The implementation > requirements for surrogates have not been standardized; depending > on the implementation, surrogates may or may not respond to the > cache directives defined in [1] . Surrogates are also known as > "reverse proxies" and "(origin) server accelerators". > > is not accurate because it refers to "tunnelling". A surrogate does > not tunnel requests -- it forwards them. Likewise, the content may be > transformed or redirected in the process. Note that it is impossible > for an HTTP tunnel to cache responses. I would agree that the wording "service internally from a cache or by tunnelling them on to origin servers" is unfortunate, but a surrogate may act as a gateway or a tunnel; there may be perfectly valid reasons why a surrogate might be configured to tunnel some requests back to the master origin server, for whatever reason. That having been said, this would not be a typical use of a surrogate, and the word 'tunnel' probably does more harm than good; it deserves to be a footnote. I'd be comfortable if the section 'acts as a server... on to origin servers' were replaced with something that established that a) a surrogate is a gateway and b) it appears as an origin server to downstream clients. > The implementation requirements for HTTP-aware "surrogates" have been > standardized. They are all the requirements for gateways in HTTP. > Changing the name doesn't change those requirements. Changing the name > doesn't make the currently broken implementations of "reverse proxies" > any more compliant with HTTP. "Gateway" may provide a very general framework for requirements (such as message and connection handling, etc), but this completely ignores the fact that a surrogate (or at least, a demand-driven surrogate, to use the taxonomy's language) implements a cache, or the context that it operates in (nominated by the master origin server, appears as an origin server to its clients). I'm presenting a paper at WCW5 that attempts to motivate the establishment of a distinct role for demand-driven surrogate origin servers, and identify some of the problems and opportunities that they present. Hecklers welcome. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Thu Apr 13 06:18:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25581 for ; Thu, 13 Apr 2000 06:18:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA08715; Thu, 13 Apr 2000 06:13:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 13 Apr 2000 06:13:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA08693; Thu, 13 Apr 2000 06:13:12 -0400 (EDT) Received: from mx01-ext.netapp.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA08673; Thu, 13 Apr 2000 06:13:09 -0400 (EDT) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by cs.utk.edu (smtpshim v1.0); Thu, 13 Apr 2000 06:13:09 -0400 Received: (qmail 14490 invoked from network); 13 Apr 2000 10:32:52 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 13 Apr 2000 10:32:52 -0000 Received: from johnm (jfm-laptop.europe.netapp.com [192.168.10.134]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id DAA25793; Thu, 13 Apr 2000 03:13:06 -0700 (PDT) Message-Id: <4.2.0.58.20000413115846.03f11c00@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 13 Apr 2000 12:07:39 +0200 To: Vernon Schryver , ietf@ietf.org From: John Martin Subject: Re: interception proxies Cc: wrec@cs.utk.edu In-Reply-To: <200004112247.QAA29258@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Vernon, At 04:47 PM 11/04/00 -0600, Vernon Schryver wrote: >Call me a non-team playing scab, but I refuse to the honor the old guild >work rule that limits the questions I can consider. If sourcing >other-owned etc. or anything else is an architectural or other problem, >then professional pride ought to force one to raise the issue insetad of >waiting for the AD, IESG, IAB, or a plenary to redirect things. But I >realize that's a minority view, and not just in IETF working groups or >even the IETF. When WREC was originally proposed to the IESG, its scope was much broader. Since the area was, at the time, the subject of much confusion, our charter was changed by the IESG to begin with a taxonomy and a list of known problems with caching and replication as is done today. At the time, I disagreed but complied. With hindsight - and given recent discussions - I think that their decision was correct. (If for no other reason that we now know what to call these "interception proxy" things). Most of us who started WREC have indeed an interest in caching and replication but not necessarily "interceptions proxies". This type of proxy is only one way to do caching / replication - and certainly by no means the most common. (The most common - by far - are actually standard, run-of-the-mill proxies configured explicitly in users' browsers). Rgds, John (WREC co-chair) --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Thu Apr 13 21:58:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18097 for ; Thu, 13 Apr 2000 21:58:04 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA15374; Thu, 13 Apr 2000 21:53:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 13 Apr 2000 21:53:28 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA15356; Thu, 13 Apr 2000 21:53:28 -0400 (EDT) Received: from raptor.ebuilt.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA15343; Thu, 13 Apr 2000 21:53:25 -0400 (EDT) Received: from raptor.ebuilt.net (216.237.34.38) by cs.utk.edu (smtpshim v1.0); Thu, 13 Apr 2000 21:53:25 -0400 Received: from mana (darth-vader.ebuilt.com [216.237.34.33]) by raptor.ebuilt.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2XTSA2VN; Thu, 13 Apr 2000 18:53:02 -0700 From: "Roy T. Fielding" To: "Mark Nottingham" Cc: Subject: RE: surrogates are not tunnels Date: Thu, 13 Apr 2000 18:49:54 -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.2911.0) In-Reply-To: <20000412220243.A25032@mnot.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal List-Unsubscribe: Content-Transfer-Encoding: 7bit > > The implementation requirements for HTTP-aware "surrogates" have been > > standardized. They are all the requirements for gateways in HTTP. > > Changing the name doesn't change those requirements. Changing the name > > doesn't make the currently broken implementations of "reverse proxies" > > any more compliant with HTTP. > > "Gateway" may provide a very general framework for requirements (such as > message and connection handling, etc), but this completely ignores the fact > that a surrogate (or at least, a demand-driven surrogate, to use the > taxonomy's language) implements a cache, or the context that it operates in > (nominated by the master origin server, appears as an origin server to its > clients). How does it ignore it? The HTTP specifications (going back to October 1995) include overlapping requirements for each role portrayed by some piece of compliant software: client/server, cache/no-cache, and user-agent/proxy/gateway/origin-server. By your description, a demand-driven surrogate is defined by HTTP as a gateway (implying both client and server requirements along with the requirements on an intermediary) with an optional cache. Both the semantic and protocol syntax requirements for such a beast are fully defined by HTTP/1.1. What is not defined is the administration framework and such protocol additions required to dynamically manipulate the arrangement of such beasts, since that was outside the scope of the HTTP communication path itself. As a reminder, here are the definitions from RFC 2616: gateway A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway. tunnel An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. ........................................................................... Roy T. Fielding fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 2652 McGaw Ave. fax:+1.949.609.0001 Irvine, CA 92614-5840 USA http://www.eBuilt.com ........................................................................... From owner-wrec@cs.utk.edu Fri Apr 14 00:36:54 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21327 for ; Fri, 14 Apr 2000 00:36:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA24076; Fri, 14 Apr 2000 00:32:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 14 Apr 2000 00:32:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA24058; Fri, 14 Apr 2000 00:32:20 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA24044; Fri, 14 Apr 2000 00:32:15 -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); Fri, 14 Apr 2000 00:32:16 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id C1D956600; Thu, 13 Apr 2000 21:32:15 -0700 (PDT) Date: Thu, 13 Apr 2000 21:32:15 -0700 From: Mark Nottingham To: "Roy T. Fielding" Cc: wrec@cs.utk.edu Subject: Re: surrogates are not tunnels Message-ID: <20000413213215.A26345@mnot.net> References: <20000412220243.A25032@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: ; from fielding@ebuilt.com on Thu, Apr 13, 2000 at 06:49:54PM -0700 List-Unsubscribe: On Thu, Apr 13, 2000 at 06:49:54PM -0700, Roy T. Fielding wrote: > The HTTP specifications (going back to October 1995) include overlapping > requirements for each role portrayed by some piece of compliant software: > client/server, cache/no-cache, and user-agent/proxy/gateway/origin-server. Well said. I'd go further to summarise: * both user-agents and proxies are clients. * proxies, gateways and origin-servers are servers. * proxies and clients may implement a cache. Correct? I'm putting forward the notion that the (proxy | client) + cache relationship is designed for and well understood, while the (origin server | gateway) + cache relationship is not. Things are further muddied by the fact that a surrogate is gateway + cache + client. > By your description, a demand-driven surrogate is defined by HTTP as a > gateway (implying both client and server requirements along with the > requirements on an intermediary) with an optional cache. Both the > semantic and protocol syntax requirements for such a beast are fully > defined by HTTP/1.1. The specification makes very little distinction in requirements between a proxy and a gateway. Most distinctions are either a) requirements for proxies that are absent for gateways or b) noting that a gateway can be used to translate to a different protocol (which is probably the most widely used meaning of gateway, even if they can be used HTTP->HTTP). The requirements for caches presuppose that they act on behalf of a client (i.e., in a user-agent or a proxy). A gateway cache is populated on behalf of the origin server, and operates in a very different context. There are a lot of broken implementations out there, mostly caused by people leveraging proxy/cache software as a demand-driven surrogate, without considering the protocol implications. While some of this could be avoided by a careful reading of the spec as to the difference between 'proxy' and 'gateway', in many places it's not clear, or complete. There's also a fair amount of pressure to add protocol features specific to the unique situation a surrogate is in. IMHO, this leads to the need for clearer requirements for such a device; one way of doing so may be to create a new role for it. A sizeable amount of internet traffic now flows through surrogates, and if some reports are to be believed, that proportion will only increase in the future. Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Fri Apr 14 02:10:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03288 for ; Fri, 14 Apr 2000 02:10:31 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA00130; Fri, 14 Apr 2000 02:06:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 14 Apr 2000 02:06:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA00109; Fri, 14 Apr 2000 02:06:11 -0400 (EDT) Received: from raptor.ebuilt.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id CAA00096; Fri, 14 Apr 2000 02:06:09 -0400 (EDT) Received: from raptor.ebuilt.net (216.237.34.38) by cs.utk.edu (smtpshim v1.0); Fri, 14 Apr 2000 02:06:09 -0400 Received: from mana (darth-vader.ebuilt.com [216.237.34.33]) by raptor.ebuilt.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2XTSA250; Thu, 13 Apr 2000 23:05:59 -0700 From: "Roy T. Fielding" To: "Mark Nottingham" Cc: Subject: RE: surrogates are not tunnels Date: Thu, 13 Apr 2000 23:02:50 -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.2911.0) In-Reply-To: <20000413213215.A26345@mnot.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal List-Unsubscribe: Content-Transfer-Encoding: 7bit > > The HTTP specifications (going back to October 1995) include overlapping > > requirements for each role portrayed by some piece of compliant software: > > client/server, cache/no-cache, and user-agent/proxy/gateway/origin-server. > > Well said. I'd go further to summarise: > > * both user-agents and proxies are clients. As are HTTP-to-HTTP gateways -- they act as a client for their interaction with the inbound (origin) servers. HTTP-to-OTHER gateways are also clients, but in that case they only have to obey the OTHER protocol's client requirements. In many cases, this OTHER protocol is just a private company's bastardized HTTP for their internal purposes. > * proxies, gateways and origin-servers are servers. > * proxies and clients may implement a cache. Anything except a tunnel (while acting as a tunnel) can implement a cache. > Correct? > > I'm putting forward the notion that the (proxy | client) + cache > relationship is designed for and well understood, while the (origin server | > gateway) + cache relationship is not. Things are further muddied by the fact > that a surrogate is gateway + cache + client. I disagree. While there is certainly more to learn out there regarding all aspects of the Web architecture, these surrogate things were both known about and planned for in HTTP/1.1. In fact, that is most of the planning I did for 1.1 -- making the message rules such that any intermediary can process a message without necessarily knowing all of the semantics of the message. This was the key to enabling hierarchical cache mechanisms, which was my goal at the time, and it applied to both incoming request streams (proxy hierarchies) and outgoing response steams (server-side cache distribution networks). That isn't to say that HTTP/1.1 gets everything right by any means, but this part was pretty well understood at the time (late 1994/1995). Most of the problems that remain in HTTP/1.1 are things that we couldn't fix without breaking backwards-compatibility with HTTP/1.0. >... > There are a lot of broken implementations out there, mostly caused by people > leveraging proxy/cache software as a demand-driven surrogate, without > considering the protocol implications. While some of this could be avoided > by a careful reading of the spec as to the difference between 'proxy' and > 'gateway', in many places it's not clear, or complete. There's also a fair > amount of pressure to add protocol features specific to the unique situation > a surrogate is in. > > IMHO, this leads to the need for clearer requirements for such a device; one > way of doing so may be to create a new role for it. A sizeable amount of > internet traffic now flows through surrogates, and if some reports are to be > believed, that proportion will only increase in the future. Oh, there is definitely room for additional requirements and protocol extensions for managed cache control, and even for newer, more efficient standards for those OTHER protocols. What I was objecting to was the statement (in the taxonomy) which says the "requirements for surrogates have not been standardized." That statement is false for HTTP. ........................................................................... Roy T. Fielding fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 2652 McGaw Ave. fax:+1.949.609.0001 Irvine, CA 92614-5840 USA http://www.eBuilt.com ........................................................................... From owner-wrec@cs.utk.edu Fri Apr 14 02:43:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03514 for ; Fri, 14 Apr 2000 02:43:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA02352; Fri, 14 Apr 2000 02:38:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 14 Apr 2000 02:38:48 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA02334; Fri, 14 Apr 2000 02:38:47 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id CAA02314; Fri, 14 Apr 2000 02:38:43 -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); Fri, 14 Apr 2000 02:38:44 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id E90606600; Thu, 13 Apr 2000 23:38:44 -0700 (PDT) Date: Thu, 13 Apr 2000 23:38:44 -0700 From: Mark Nottingham To: "Roy T. Fielding" Cc: wrec@cs.utk.edu Subject: Re: surrogates are not tunnels Message-ID: <20000413233844.C26345@mnot.net> References: <20000413213215.A26345@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: ; from fielding@ebuilt.com on Thu, Apr 13, 2000 at 11:02:50PM -0700 List-Unsubscribe: On Thu, Apr 13, 2000 at 11:02:50PM -0700, Roy T. Fielding wrote: > > Oh, there is definitely room for additional requirements and protocol > extensions for managed cache control, and even for newer, more efficient > standards for those OTHER protocols. What I was objecting to was the > statement (in the taxonomy) which says the "requirements for surrogates > have not been standardized." That statement is false for HTTP. OK, that sounds like a good piece of common ground to start with. I'd agree that the basic requirements within the framework of a gateway are valid and applicable to a surrogate. I've noted both problems with current implementations (mostly caused by misuse of proxy software, but also a few brought about by ambiguity in the protocol) and opportunities for making a surrogate more efficient; this is the bulk of what I intend to present. This has been very helpful in clarifing the issues; thanks. -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Fri Apr 14 16:08:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13785 for ; Fri, 14 Apr 2000 16:08:35 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA04978; Fri, 14 Apr 2000 15:57:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 14 Apr 2000 15:57:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA04960; Fri, 14 Apr 2000 15:57:07 -0400 (EDT) Received: from octo.memory.se (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA04945; Fri, 14 Apr 2000 15:57:04 -0400 (EDT) Received: from octo.memory.se (193.13.247.17 -> octo.memory.se) by cs.utk.edu (smtpshim v1.0); Fri, 14 Apr 2000 15:57:04 -0400 Received: from [193.13.248.140] by octo.memory.se for id VAA16639; Fri Apr 14 21:56:41 2000 Received: from henrik.localdomain (localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id HAA10349; Fri, 14 Apr 2000 07:33:19 +0200 Message-ID: <38F6AD9F.26B3CFAB@hem.passagen.se> Date: Fri, 14 Apr 2000 07:33:19 +0200 X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.13-reiserfs i586) MIME-Version: 1.0 Subject: Re: surrogates are not tunnels References: <20000412220243.A25032@mnot.net> <20000413213215.A26345@mnot.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark Nottingham From: Henrik Nordstrom Sender: hno@hem.passagen.se Cc: wrec@cs.utk.edu List-Unsubscribe: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > Well said. I'd go further to summarise: > > * both user-agents and proxies are clients. > * proxies, gateways and origin-servers are servers. > * proxies and clients may implement a cache. > > Correct? Att kinds of servers may implement a cache, especially gateways. -- Henrik Nordstrom From owner-wrec@cs.utk.edu Mon Apr 17 19:09:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11330 for ; Mon, 17 Apr 2000 19:09:56 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA20034; Mon, 17 Apr 2000 19:05:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 17 Apr 2000 19:05:13 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA20016; Mon, 17 Apr 2000 19:05:13 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA19996; Mon, 17 Apr 2000 19:05:08 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Mon, 17 Apr 2000 19:05:08 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id RAA10440 env-from ; Mon, 17 Apr 2000 17:05:01 -0600 (MDT) Date: Mon, 17 Apr 2000 17:05:01 -0600 (MDT) From: Vernon Schryver Message-Id: <200004172305.RAA10440@calcite.rhyolite.com> To: Erik.Nordmark@eng.sun.com, touch@ISI.EDU Subject: Re: interception proxies Cc: moore@cs.utk.edu, wrec@cs.utk.edu List-Unsubscribe: > From: Joe Touch > To: Erik Nordmark > > This doesn't list what I thought was an obvious issue. > > If multiple nodes are originating packets with the same source > > IP address it will be rather hard for them to ensure the required > > uniqueness on the IP ID field (unique for the combination > > of source IP, destination IP and protocol). > > > > I suspect that most of boxes that play these games don't worry about > > IP ID which might cause garbage reassembly should the same > > IP ID be used when multiple such boxes are sending to the same IP address. > > > Good point. > > I suspect they ignore the issue because of how they demux to multiple > boxes; > if the demux is by a hash of source IP address, then there's no need for > coordination thereafter. That's ok for the redirected ISP customers and the box itself, but what about the distant server that is getting less than half of the (addr, port, addr, port) 4-tuple? I thought the point was that the distant SMTP or HTTP server would be getting second or later IP fragments with colliding IP ID's, identical source (proxy's) and destination (server's) IP addresses, and so with no clue which IP fragments belong to which stream. > I'll certainly add that to the list. There's a corrolary at the TCP > level, of port reuse, etc. Is that a sign of good things happening to the document? I've been hoping to see some activity in the WREC list about either hijacking--uh--redirecting proxy hazards documement or the document NECP Is something happening behind the scenes? If so, please forget I asked. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Mon Apr 17 19:19:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11380 for ; Mon, 17 Apr 2000 19:19:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA20944; Mon, 17 Apr 2000 19:15:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 17 Apr 2000 19:15:05 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA20926; Mon, 17 Apr 2000 19:15:04 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA20909; Mon, 17 Apr 2000 19:15:02 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Mon, 17 Apr 2000 19:15:02 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id QAA25230; Mon, 17 Apr 2000 16:14:57 -0700 (PDT) Message-ID: <38FB9AEF.DE26210D@isi.edu> Date: Mon, 17 Apr 2000 16:14:55 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vernon Schryver CC: Erik.Nordmark@eng.sun.com, moore@cs.utk.edu, wrec@cs.utk.edu, touch@ISI.EDU Subject: Re: interception proxies References: <200004172305.RAA10440@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > > From: Joe Touch > > To: Erik Nordmark > > > > This doesn't list what I thought was an obvious issue. > > > If multiple nodes are originating packets with the same source > > > IP address it will be rather hard for them to ensure the required > > > uniqueness on the IP ID field (unique for the combination > > > of source IP, destination IP and protocol). > > > > > > I suspect that most of boxes that play these games don't worry about > > > IP ID which might cause garbage reassembly should the same > > > IP ID be used when multiple such boxes are sending to the same IP address. > > > > > > Good point. > > > > I suspect they ignore the issue because of how they demux to multiple > > boxes; > > if the demux is by a hash of source IP address, then there's no need for > > coordination thereafter. > > That's ok for the redirected ISP customers and the box itself, but > what about the distant server that is getting less than half of the > (addr, port, addr, port) 4-tuple? I thought the point was that > the distant SMTP or HTTP server would be getting second or later > IP fragments with colliding IP ID's, identical source (proxy's) > and destination (server's) IP addresses, and so with no clue which > IP fragments belong to which stream. I was describing a (easy) case where the demux is by source IP only; in that case, IP IDs can be reused by the different servers, because there is no potential collision of the tuples. There are certainly cases where the demux is not by source IP, in which case the different servers (or clients) sharing an IP address need to coordinate IP IDs. > > I'll certainly add that to the list. There's a corrolary at the TCP > > level, of port reuse, etc. > > Is that a sign of good things happening to the document? > I've been hoping to see some activity in the WREC list about either > hijacking--uh--redirecting proxy hazards documement or the document > NECP Is something happening behind the scenes? If so, please forget > I asked. Thus far I haven't seen enough feedback to determine. I'm looking for direction: - (preferred) separate hazards ID - roll into known problems (I've discussed with others why I think this is outside 'known probs' - in the sense that I feel KP is about unintended non-compliance, not deliberate extension/augmentation with new mechanism) I don't know what 'hijacking' would mean - I'm in WREC, so I'd be glad to have it run through that group (that's what I was expecting, in fact). I would assume it would be cited/referred by an update to NECP, but not rolled-in per se. Any other thoughts? Joe From owner-wrec@cs.utk.edu Mon Apr 17 20:05:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11778 for ; Mon, 17 Apr 2000 20:05:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA23760; Mon, 17 Apr 2000 20:01:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 17 Apr 2000 20:01:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA23742; Mon, 17 Apr 2000 20:01:34 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA23710; Mon, 17 Apr 2000 20:01:24 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Mon, 17 Apr 2000 20:01:25 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id SAA11671 for wrec@cs.utk.edu env-from ; Mon, 17 Apr 2000 18:01:22 -0600 (MDT) Date: Mon, 17 Apr 2000 18:01:22 -0600 (MDT) From: Vernon Schryver Message-Id: <200004180001.SAA11671@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: Joe Touch > ... > > > I suspect they ignore the issue because of how they demux to multiple > > > boxes; > > > if the demux is by a hash of source IP address, then there's no need for > > > coordination thereafter. > > > > That's ok for the redirected ISP customers and the box itself, but > > what about the distant server that is getting less than half of the > > (addr, port, addr, port) 4-tuple? I thought the point was that > > the distant SMTP or HTTP server would be getting second or later > > IP fragments with colliding IP ID's, identical source (proxy's) > > and destination (server's) IP addresses, and so with no clue which > > IP fragments belong to which stream. > > I was describing a (easy) case where the demux is by source IP only; in > that case, IP IDs can be reused by the different servers, because there > is no potential collision of the tuples. > > There are certainly cases where the demux is not by source IP, in which > case the different servers (or clients) sharing an IP address need to > coordinate IP IDs. Either I don't understand or we're not communicating. I don't see how a redirection proxy can ever be designed to demux packets from the Internet by IP source address. Those source addresses are in the great beyond and will be different or the same for local customers depending on chance and the popularity of the distant server. I'm talking about client A, IP address 10.1 client B, IP address 10.2 redirection proxy P, IP address 192.0.2.1 distant HTTP server S, IP address 172.16.0.1 Clients A and B try to open HTTP/TCP/IP connections with S. They both have private Ethernets and so like MTU=1500 ad MSS=1460, and they have typically misconfigured PPP/modem links with MTU=512. Both clients send SYN's to get rolling. Since they're using common operating systems that don't try hard, they both use the same IP ID's their corresponding HTTP/TCP/IP packets. The first thing they do after the 3-way handshake is try to GET similar 600 byte URLs. Or perhaps they do 1000 byte PUT's. Thus, they both send IP fragments with the same IP ID's, the same IP destination address, and differing only in IP source address (10.1. vs.10.2) and fragmentary HTTP payload. The proxy P takes all of their IP packets and rewrites their sources addresses of 10.1 and 10.2 to its own 192.0.2.1. The proxy then sends the modified IP packets to server S. Server S is never confused as long as S receives unfragmented TCP segments, surely including the SYN's. However, what does server S do when it gets the second IP fragments? The fragments from the HTTP clients as received at S have the same IP source and destination addresses and IP ID's. At best they'll have differing IP offsets and lengths, but at worst even those will be the same. The only fix is for the proxy P to assign its own IP's, but that has serious problems given the small size of the IP ID and relatively long lifetimes (a few seconds) of client streams. 64K packets in a few seconds is not impressive in a world of Tbit/sec routers. 64K 500 byte packets in 3 seconds is only 10 MByte/sec, less than a single FDDI interface. Consider that many popular web sites can't answer in less than 10 seconds, and you're talking about less than a T3. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Mon Apr 17 20:43:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12097 for ; Mon, 17 Apr 2000 20:43:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA25991; Mon, 17 Apr 2000 20:39:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 17 Apr 2000 20:39:01 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA25968; Mon, 17 Apr 2000 20:39:00 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA25950; Mon, 17 Apr 2000 20:38:58 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Mon, 17 Apr 2000 20:38:58 -0400 Received: from isi.edu (sci.isi.edu [128.9.160.93]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id RAA06654; Mon, 17 Apr 2000 17:38:54 -0700 (PDT) Message-ID: <38FBAE9C.5389012F@isi.edu> Date: Mon, 17 Apr 2000 17:38:52 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vernon Schryver CC: wrec@cs.utk.edu Subject: Re: interception proxies References: <200004180001.SAA11671@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > > From: Joe Touch > > > ... > > > > I suspect they ignore the issue because of how they demux to multiple > > > > boxes; > > > > if the demux is by a hash of source IP address, then there's no need for > > > > coordination thereafter. > > > > > > That's ok for the redirected ISP customers and the box itself, but > > > what about the distant server that is getting less than half of the > > > (addr, port, addr, port) 4-tuple? I thought the point was that > > > the distant SMTP or HTTP server would be getting second or later > > > IP fragments with colliding IP ID's, identical source (proxy's) > > > and destination (server's) IP addresses, and so with no clue which > > > IP fragments belong to which stream. > > > > I was describing a (easy) case where the demux is by source IP only; in > > that case, IP IDs can be reused by the different servers, because there > > is no potential collision of the tuples. > > > > There are certainly cases where the demux is not by source IP, in which > > case the different servers (or clients) sharing an IP address need to > > coordinate IP IDs. > > Either I don't understand or we're not communicating. > I don't see how a redirection proxy can ever be designed to demux packets > from the Internet by IP source address. Those source addresses are in > the great beyond and will be different or the same for local customers > depending on chance and the popularity of the distant server. I'm speaking of a redirection proxy sitting at the entry of a web farm. In that case, the redirection proxy never really terminates a connection; it forwards the SYN to one of the web farm boxes, and changes the IP address in the process: > I'm talking about > > client A, IP address 10.1 > client B, IP address 10.2 > redirection proxy P, IP address 192.0.2.1 > distant HTTP server S, IP address 172.16.0.1 > > Clients A and B try to open HTTP/TCP/IP connections with S. They > both have private Ethernets and so like MTU=1500 ad MSS=1460, and > they have typically misconfigured PPP/modem links with MTU=512. > > Both clients send SYN's to get rolling. Since they're using common > operating systems that don't try hard, they both use the same IP ID's > their corresponding HTTP/TCP/IP packets. > The first thing they do after the 3-way handshake is try to GET similar > 600 byte URLs. Or perhaps they do 1000 byte PUT's. Thus, they both send > IP fragments with the same IP ID's, the same IP destination address, > and differing only in IP source address (10.1. vs.10.2) and fragmentary > HTTP payload. > > The proxy P takes all of their IP packets and rewrites their sources > addresses of 10.1 and 10.2 to its own 192.0.2.1. The proxy then sends > the modified IP packets to server S. Ahh - that would be 'bad.' (i.e., that's not the case I was thinking of which wouldn't be a problem). I was thinking of rewriting destination addresses, not sources. E.g: client A @ 10.1 client B @ 10.2 redirection P @ 192.0.2.1 HTTP server S @ 172.16.0.1 local HTTP 'server' (cache) C at 192.0.2.2 local HTTP 'server' (cache) D at 192.0.2.3 A sends to S P 'nat's' the dest S to the dest C C responds to A (alternately, P responds to A, and relays by opening a new connection to C) B sends to S P 'nat's' the dest S to the dest D D responds to B... E.g., - P demuxes to each local cache based on the source address in this case, C and D need not coordinate IP IDs; they're necessarily distinct. Joe From owner-wrec@cs.utk.edu Mon Apr 17 22:00:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13563 for ; Mon, 17 Apr 2000 22:00:18 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA02081; Mon, 17 Apr 2000 21:55:45 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Mon, 17 Apr 2000 21:55:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA02063; Mon, 17 Apr 2000 21:55:45 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA02048; Mon, 17 Apr 2000 21:55:39 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Mon, 17 Apr 2000 21:55:41 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id TAA15855 for wrec@cs.utk.edu env-from ; Mon, 17 Apr 2000 19:55:38 -0600 (MDT) Date: Mon, 17 Apr 2000 19:55:38 -0600 (MDT) From: Vernon Schryver Message-Id: <200004180155.TAA15855@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: Joe Touch > ... > I'm speaking of a redirection proxy sitting at the entry of a web farm. > In that case, the redirection proxy never really terminates a > connection; it forwards the SYN to one of the web farm boxes, and > changes the IP address in the process: But that is the virtuous strain of redirection proxy instead of the hijacking brand. We know it's administratively cleaner. Even if there were problems in the virtuous strain, the common administrative control should allow technical fixes or patches for redirection hazzards, such as ensuring that there is no cause for unexpected internal IP fragmentation. My proposed rule of thumb fits here, that a hack that doesn't play with IPSEC or application layer encryption or authentication is probably a bad idea. > ... > A sends to S > P 'nat's' the dest S to the dest C > ... A NAT box can also do the wrong thing with IP fragmentation, and in more plausible scenarioes than 600 byte URL's or PUT's. Consider two client hosts behind a single NAT box that has been configured with a 500 byte PPP MTU, path MTU discovery is not working (probably a redundant statement in this case), both client hosts are using ~1500 byte MSS's and MTU's, and are fetching from the same HTTP server. The NAT box will be receiving IP packets with identical IP source and destination addresses, but differing IP ID's. Somehow I suspect many NAT boxes won't do the require (equivalent of) IP fragment reassembly to recover the port numbers to know how to demux the stream from the Internet into correct local destination IP and Ethernet addresses. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Tue Apr 18 01:33:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20536 for ; Tue, 18 Apr 2000 01:33:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA11740; Tue, 18 Apr 2000 01:29:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 01:29:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA11722; Tue, 18 Apr 2000 01:29:30 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA11709; Tue, 18 Apr 2000 01:29:28 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 01:29:28 -0400 Received: from isi.edu (pen-i.isi.edu [128.9.102.3]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id WAA05051; Mon, 17 Apr 2000 22:29:24 -0700 (PDT) Message-ID: <38FBF2B1.598E4AB2@isi.edu> Date: Mon, 17 Apr 2000 22:29:22 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vernon Schryver CC: wrec@cs.utk.edu Subject: Re: interception proxies References: <200004180155.TAA15855@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > > From: Joe Touch > > > ... > > I'm speaking of a redirection proxy sitting at the entry of a web farm. > > In that case, the redirection proxy never really terminates a > > connection; it forwards the SYN to one of the web farm boxes, and > > changes the IP address in the process: > > But that is the virtuous strain of redirection proxy instead of the > hijacking brand. It's only virtuous if the redirection proxy is in the same AD as the web farm. The web farm may be a web cache farm. > My proposed rule of thumb fits here, that a hack that doesn't play > with IPSEC or application layer encryption or authentication is > probably a bad idea. I'm not proposing that it's a good idea. It's clear that the 'system' - redirection proxy and set of web caches redirected to - are responsible for maintaining the IP ID uniqueness, since they, as a whole, intend to represent a single IP address. (in the trivial case I outlined, that uniqueness is ensured by the use of source-determined demux; anytime packets with the same source/dest pair can go to the different endpoints, uniqueness must be otherwise avoided, e.g., out of band messages between the endpoints.) The same applies, BTW, for port reuse and TCP sequence spaces. Sets of endpoints aliasing as a single must coordinate and ensure uniqueness. > > ... > > A sends to S > > P 'nat's' the dest S to the dest C > > ... > > A NAT box can also do the wrong thing with IP fragmentation, and in more > plausible scenarioes than 600 byte URL's or PUT's. Consider two client > hosts behind a single NAT box that has been configured with a 500 byte > PPP MTU, path MTU discovery is not working (probably a redundant statement > in this case), both client hosts are using ~1500 byte MSS's and MTU's, > and are fetching from the same HTTP server. The NAT box will be receiving > IP packets with identical IP source and destination addresses, but > differing IP ID's. Somehow I suspect many NAT boxes won't do the require > (equivalent of) IP fragment reassembly to recover the port numbers to know > how to demux the stream from the Internet into correct local destination > IP and Ethernet addresses. Hmmm - is that observation in the NAT specs? If not, is it something that should be addressed separately there, or in the Transparency Hazards doc?? Joe From owner-wrec@cs.utk.edu Tue Apr 18 01:55:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21865 for ; Tue, 18 Apr 2000 01:55:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA13151; Tue, 18 Apr 2000 01:51:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 01:51:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA13133; Tue, 18 Apr 2000 01:51:10 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA13120; Tue, 18 Apr 2000 01:51:06 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 01:51:07 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id XAA19689 for wrec@cs.utk.edu env-from ; Mon, 17 Apr 2000 23:51:05 -0600 (MDT) Date: Mon, 17 Apr 2000 23:51:05 -0600 (MDT) From: Vernon Schryver Message-Id: <200004180551.XAA19689@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: Joe Touch > ... > redirection proxy and set of web caches redirected to - are responsible > for maintaining the IP ID uniqueness, since they, as a whole, intend to > represent a single IP address. > > (in the trivial case I outlined, that uniqueness is ensured by the use > of source-determined demux; anytime packets with the same source/dest > pair can go to the different endpoints, uniqueness must be otherwise > avoided, e.g., out of band messages between the endpoints.) > > The same applies, BTW, for port reuse and TCP sequence spaces. Sets of > endpoints aliasing as a single must coordinate and ensure uniqueness. yep. As long as local system maintains the illusion to the remote peer of being a correctly functioning host, everything else, including geographical dispersion is an irrelevant internal implementation detail. IPSEC and application layer security are canaries that swoon early when third parties try to improve the situation. > > A NAT box can also do the wrong thing with IP fragmentation, and in more > > plausible scenarioes than 600 byte URL's or PUT's. Consider two client > ... > Hmmm - is that observation in the NAT specs? If not, is it something > that should be addressed separately there, or in the Transparency > Hazards doc?? As I understand your document, it's off topic. I understand it as "Third Party Redirection Proxies Considered Harmful." The bit about third party HTTP redirection proxies being based on replay attacks exemplifies the sense. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Tue Apr 18 02:55:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28636 for ; Tue, 18 Apr 2000 02:55:11 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA15122; Tue, 18 Apr 2000 02:48:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 02:48:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA15104; Tue, 18 Apr 2000 02:48:03 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id CAA15091; Tue, 18 Apr 2000 02:48:01 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 02:48:02 -0400 Received: from isi.edu (pen-i.isi.edu [128.9.102.3]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id XAA12308; Mon, 17 Apr 2000 23:47:58 -0700 (PDT) Message-ID: <38FC051B.E0FD1DA5@isi.edu> Date: Mon, 17 Apr 2000 23:47:55 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Vernon Schryver CC: wrec@cs.utk.edu, touch@ISI.EDU Subject: Re: interception proxies References: <200004180551.XAA19689@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > > > A NAT box can also do the wrong thing with IP fragmentation, and in more > > > plausible scenarioes than 600 byte URL's or PUT's. Consider two client > > ... > > > Hmmm - is that observation in the NAT specs? If not, is it something > > that should be addressed separately there, or in the Transparency > > Hazards doc?? > > As I understand your document, it's off topic. > I understand it as "Third Party Redirection Proxies Considered Harmful." > The bit about third party HTTP redirection proxies being based on > replay attacks exemplifies the sense. The only question is whether there is something similar between NATs and transparent proxies. Maybe "modifying IP packets considered harmful". The issue with NATs may best be added under "even within the same AD, transparent proxies are dangerous because..." including the IP ID and TCP port and sequence number issues there seems on-topic. (?) Joe From owner-wrec@cs.utk.edu Tue Apr 18 04:18:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29208 for ; Tue, 18 Apr 2000 04:18:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA20660; Tue, 18 Apr 2000 04:13:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 04:13:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA20642; Tue, 18 Apr 2000 04:13:01 -0400 (EDT) Received: from mx01-ext.netapp.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA20613; Tue, 18 Apr 2000 04:12:59 -0400 (EDT) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 04:12:59 -0400 Received: (qmail 20268 invoked from network); 18 Apr 2000 08:34:46 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 18 Apr 2000 08:34:46 -0000 Received: from johnm ([192.168.199.36]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id BAA17529; Tue, 18 Apr 2000 01:12:51 -0700 (PDT) Message-Id: <4.2.0.58.20000418095546.04052300@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 18 Apr 2000 10:09:25 +0200 To: Vernon Schryver , Erik.Nordmark@eng.sun.com, touch@ISI.EDU From: John Martin Subject: Re: interception proxies Cc: moore@cs.utk.edu, wrec@cs.utk.edu In-Reply-To: <200004172305.RAA10440@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 05:05 PM 17/04/00 -0600, Vernon Schryver wrote: >Is that a sign of good things happening to the document? >I've been hoping to see some activity in the WREC list about either >hijacking--uh--redirecting proxy hazards documement or the document >NECP Is something happening behind the scenes? If so, please forget >I asked. NECP is not within the scope of WREC's current charter. NECP is being revised, however, and we can expect a new version within the next few weeks or so. With respect to interception proxies, I would very much like to see these discussed further on WREC. Our issues document could probably do with wider review than just WREC. But one very common mis-conception I have noticed is about the point at which redirection occurs. In my experience, the redirection takes place only at either source or destination, or more specifically, at a point which is under the same administrative control as the end-user or (e.g.) the web server itself. A lot of the recent discussion on the IETF list seemed to assume that this happened "somewhere in the middle". I'm not saying this is not possible, just that it is not happening today (to my knowledge). In the future, I think that it will get more, not less difficult to do this too - e.g. when traffic is already tagged / labelled it will be more difficult to intercept in the middle of its path. In the meantime, there are many other ways to redirect clients to the closest proxy. One common way is to simply use the DNS to give a response dependant on the client's source IP address (for either the proxy or the destination web server); many corporates do this today already - Akamai have built a whole business out of it. John --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Tue Apr 18 10:55:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05618 for ; Tue, 18 Apr 2000 10:55:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA15927; Tue, 18 Apr 2000 10:43:47 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 10:43:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA15909; Tue, 18 Apr 2000 10:43:46 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA15896; Tue, 18 Apr 2000 10:43:42 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 10:43:43 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id IAA27247 for wrec@cs.utk.edu env-from ; Tue, 18 Apr 2000 08:43:36 -0600 (MDT) Date: Tue, 18 Apr 2000 08:43:36 -0600 (MDT) From: Vernon Schryver Message-Id: <200004181443.IAA27247@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: Joe Touch > ... > The only question is whether there is something similar between NATs and > transparent proxies. Maybe "modifying IP packets considered harmful". > The issue with NATs may best be added under "even within the same AD, > transparent proxies are dangerous because..." including the IP ID and > TCP port and sequence number issues there seems on-topic. (?) Agreed, NAT's and redirecting proxies are technically similar. (However, I'm not sure that 'a "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification' is similar to a NAT box or a redirecting proxy.) Is there an RFC that includes the many complaints that have been made about NAT boxes in the main IETF list? vjs From owner-wrec@cs.utk.edu Tue Apr 18 11:14:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05989 for ; Tue, 18 Apr 2000 11:14:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA18863; Tue, 18 Apr 2000 11:02:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 11:02:54 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA18845; Tue, 18 Apr 2000 11:02:53 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA18831; Tue, 18 Apr 2000 11:02:44 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 11:02:45 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA27464 for wrec@cs.utk.edu env-from ; Tue, 18 Apr 2000 09:02:42 -0600 (MDT) Date: Tue, 18 Apr 2000 09:02:42 -0600 (MDT) From: Vernon Schryver Message-Id: <200004181502.JAA27464@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: John Martin > ... > But one very common mis-conception I have noticed is about the point at > which redirection occurs. In my experience, the redirection takes place > only at either source or destination, or more specifically, at a point > which is under the same administrative control as the end-user or (e.g.) > the web server itself. You're mistaken, as America Online's SMTP redirection proxies demonstrate. As I pointed out in the main IETF list, AOL is openly redirecting all SMTP traffic from their dialups and nominally IP-addresed to the Internet at large to boxes operated by AOL. Currently those seem to boxes do no more than add SMTP Received: headers, but realsoonnow are supposed to added an X-Apparently-From: header and to filter the entire message if the box considers it spam. For at least a year, I think HTTP redirection proxies have been operated by some ISP's, justified by the familiar efficiency reasoning. In both cases the ISP must be viewed as a third party, and in security terms, a man in the middle. > A lot of the recent discussion on the IETF list seemed to assume that this > happened "somewhere in the middle". I'm not saying this is not possible, > just that it is not happening today (to my knowledge). In the main IETF list I quoted some of AOL's words on the subject and pointed to others. Again, this differs from what many ISP's (e.g. UUNet) have done, configuring their routers to block all TCP packets from their customers to distant port 25's. > In the future, I > think that it will get more, not less difficult to do this too - e.g. when > traffic is already tagged / labelled it will be more difficult to intercept > in the middle of its path. I don't see how tagging or labeling might prevent such games by third parties, unless you mean something based on encryption, and even then a secret shared only by the endpoints and used for something like a message authentication code (MAC) is required. Otherwise a man in the middle can replace or modify tags, labels, and MAC's just as it does IP addresses. IP addresses can be viewed as tags or labels. > In the meantime, there are many other ways to redirect clients to the > closest proxy. One common way is to simply use the DNS to give a response > dependant on the client's source IP address (for either the proxy or the > destination web server); many corporates do this today already - Akamai > have built a whole business out of it. Yes, and no one I know really objects to those techniques...well, sometimes I grumble about it when one of Akamai's servers hiccups as seems to be happening a lot this week. And some of those techniques make it between hard and impossible to save useful bookmarks. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Tue Apr 18 11:21:43 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06173 for ; Tue, 18 Apr 2000 11:21:42 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA19737; Tue, 18 Apr 2000 11:09:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 11:09:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA19719; Tue, 18 Apr 2000 11:09:38 -0400 (EDT) Received: from prv-mail20.provo.novell.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA19691; Tue, 18 Apr 2000 11:09:35 -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); Tue, 18 Apr 2000 11:09:36 -0400 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 18 Apr 2000 09:08:30 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 18 Apr 2000 09:08:24 -0600 From: "Gary Tomlinson" To: , , , Cc: , Subject: Re: interception proxies 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 LAA06173 Known HTTP Proxy/Caching Problems draft-ietf-wrec-known-prob-01.txt >>> John Martin 04/18/00 02:09AM >>> >At 05:05 PM 17/04/00 -0600, Vernon Schryver wrote: >>Is that a sign of good things happening to the document? >>I've been hoping to see some activity in the WREC list about either >>hijacking--uh--redirecting proxy hazards documement or the document >>NECP Is something happening behind the scenes? If so, please forget >>I asked. > >NECP is not within the scope of WREC's current charter. NECP is being >revised, however, and we can expect a new version within the next few weeks >or so. > >With respect to interception proxies, I would very much like to see these >discussed further on WREC. Our issues document could probably do with wider >review than just WREC. > Much of the discussion that is occurring with interception proxies could be addressed in the Known HTTP Proxy/Caching Problems draft. This draft has some of the know interception proxy issues discussed, but could be greatly expanded to include the discussions that have occured over the past four months. >But one very common mis-conception I have noticed is about the point at >which redirection occurs. In my experience, the redirection takes place >only at either source or destination, or more specifically, at a point >which is under the same administrative control as the end-user or (e.g.) >the web server itself. > >A lot of the recent discussion on the IETF list seemed to assume that this >happened "somewhere in the middle". I'm not saying this is not possible, >just that it is not happening today (to my knowledge). In the future, I >think that it will get more, not less difficult to do this too - e.g. when >traffic is already tagged / labelled it will be more difficult to intercept >in the middle of its path. > >In the meantime, there are many other ways to redirect clients to the >closest proxy. One common way is to simply use the DNS to give a response >dependant on the client's source IP address (for either the proxy or the >destination web server); many corporates do this today already - Akamai >have built a whole business out of it. > The whole issue and associated problems with proxy service discovery IHMO is another excellent topic for discussion and inclusion in the Known HTTP Proxy/Caching Problems draft as well. I for one would like to see this draft have broader review and participation. Its clear to me that once this draft embodies a consensus of the known problems, it will serve as an excellent set of requirements for a rechartered WREC to develop a architecture for this domain. >John Gary From owner-wrec@cs.utk.edu Tue Apr 18 11:46:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06660 for ; Tue, 18 Apr 2000 11:46:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA22645; Tue, 18 Apr 2000 11:34:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 11:34:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA22622; Tue, 18 Apr 2000 11:34:19 -0400 (EDT) Received: from web1405.mail.yahoo.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA22600; Tue, 18 Apr 2000 11:34:14 -0400 (EDT) Received: from web1405.mail.yahoo.com (128.11.23.169 -> web1405.mail.yahoo.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 11:34:14 -0400 Received: (qmail 22198 invoked by uid 60001); 18 Apr 2000 15:34:09 -0000 Message-ID: <20000418153409.22197.qmail@web1405.mail.yahoo.com> Received: from [209.239.210.165] by web1405.mail.yahoo.com; Tue, 18 Apr 2000 08:34:09 PDT Date: Tue, 18 Apr 2000 08:34:09 -0700 (PDT) From: Pyda Srisuresh Subject: Re: interception proxies To: Vernon Schryver , wrec@cs.utk.edu Cc: nat@livingston.com, holdrege@lucent.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: --- Vernon Schryver wrote: > > From: Joe Touch > > > ... > > The only question is whether there is something similar between NATs and > > transparent proxies. Maybe "modifying IP packets considered harmful". > > The issue with NATs may best be added under "even within the same AD, > > transparent proxies are dangerous because..." including the IP ID and > > TCP port and sequence number issues there seems on-topic. (?) > > Agreed, NAT's and redirecting proxies are technically similar. > > (However, I'm not sure that 'a "transparent proxy" is a proxy that does > not modify the request or response beyond what is required for proxy > authentication and identification' is similar to a NAT box or a redirecting > proxy.) > > Is there an RFC that includes the many complaints that have been made about > NAT boxes in the main IETF list? > Not an RFC. But, a draft addressing precisely this. It is titled "Protocol Complications with the IP Network Address Translator". . The draft should be going out for an IETF-wide last call shortly(It's in Steve Coya's list of things to do). Any comments and input are most welcome. Thanks. > > vjs > cheers, suresh ===== __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com From owner-wrec@cs.utk.edu Tue Apr 18 12:13:38 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07267 for ; Tue, 18 Apr 2000 12:13:37 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA11002; Tue, 18 Apr 2000 09:43:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 09:43:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA10984; Tue, 18 Apr 2000 09:43:18 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA10968; Tue, 18 Apr 2000 09:43:16 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 09:43:16 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA22692; Tue, 18 Apr 2000 09:42:12 -0400 (EDT) Message-Id: <200004181342.JAA22692@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joe Touch cc: Vernon Schryver , wrec@cs.utk.edu Subject: Re: interception proxies In-reply-to: Your message of "Mon, 17 Apr 2000 23:47:55 PDT." <38FC051B.E0FD1DA5@isi.edu> Date: Tue, 18 Apr 2000 09:42:12 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > Maybe "modifying IP packets considered harmful". I think this is the right tack. Anything you do to modify an IP packet in transit - in ways not anticipated by the design of IP - should at least be considered suspect, because the chances are good that it will break *something*. There are cases for which such practices will do only minimal harm, but the only way to find out where the safe territory lies is to analyze the kinds of harm that can be done and to identify conditions where the harm done doesn't actually cause real problems. Keith From owner-wrec@cs.utk.edu Tue Apr 18 12:42:32 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07774 for ; Tue, 18 Apr 2000 12:42:31 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA28379; Tue, 18 Apr 2000 12:30:27 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 12:30:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA28360; Tue, 18 Apr 2000 12:30:26 -0400 (EDT) Received: from anchor-post-30.mail.demon.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA28347; Tue, 18 Apr 2000 12:30:24 -0400 (EDT) Received: from anchor-post-30.mail.demon.net (194.217.242.88 -> anchor-post-30.mail.demon.net) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 12:30:25 -0400 Received: from alethea.demon.co.uk ([194.222.10.198] helo=IAN-NTLAP) by anchor-post-30.mail.demon.net with smtp (Exim 2.12 #1) id 12hatL-000Jrd-0U for wrec@cs.utk.edu; Tue, 18 Apr 2000 17:30:23 +0100 From: Ian Cooper To: wrec@cs.utk.edu Subject: Adelaide social get-together "minutes" Date: Tue, 18 Apr 2000 17:30:04 +0100 Organization: Mirror Image Internet Message-ID: <3tvofs4hjbnhkkinbmhk6ahv91lev61flo@4ax.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Gary Tomlinson, Ivan Lovric, Oskar Batuner, Joe Touch and I (and apologies to the other 3 guys that were there on the Monday for not getting your names) got together while we were in Adelaide to try and work out what the group is doing, where we can go next, and how to get there. It looks as though the Taxonomy is pretty much done. While there may be issues regarding Content Distribution Networks that may not be covered, we felt that it is better to progress the Taxonomy at this point. Ivan has a document with issues related to CDN terminology that he will translate and post. The Known Problems document should be extended. As Gary has already noted, many of the issues regarding interception proxies could be included in this draft. Our thinking was to include problems that need to be solved somehow, which would then give the group some future direction. I.e., identify the architectural issues that need to be solved, and then move on to discuss the architecture. It would be very useful if we could get moving on this so that we have something of value to discuss in Pittsburgh. The draft suggests mailing details of problems to John Dilley, although as current-keeper-of-the-XML-source it would make some sense to copy them to me too. Since John's move, we've lost access to the URL previously included for the "current" copies. Rather than continually re-issuing the draft at this stage, I'll contact webmaster@wrec to see about getting regular copies posted there instead. It may also be appropriate to change the name of the draft. Does "Known HTTP Proxy/Caching Problems" cover everything we need to be thinking about? Any immediate protocol related stuff that we need to do for business should be handled outside WREC at this time. There are already a variety of groups and other mailing lists set up for some of these things. From owner-wrec@cs.utk.edu Tue Apr 18 13:02:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08219 for ; Tue, 18 Apr 2000 13:02:34 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA00283; Tue, 18 Apr 2000 12:50:50 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 12:50:50 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA00265; Tue, 18 Apr 2000 12:50:50 -0400 (EDT) Received: from mx01-ext.netapp.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA00252; Tue, 18 Apr 2000 12:50:48 -0400 (EDT) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 12:50:48 -0400 Received: (qmail 954 invoked from network); 18 Apr 2000 17:12:42 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 18 Apr 2000 17:12:42 -0000 Received: from johnm (jfm-laptop.europe.netapp.com [192.168.10.134]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id JAA26446; Tue, 18 Apr 2000 09:50:41 -0700 (PDT) Message-Id: <4.2.0.58.20000418171234.00cc87e0@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 18 Apr 2000 18:45:21 +0200 To: Vernon Schryver , wrec@cs.utk.edu From: John Martin Subject: Re: interception proxies In-Reply-To: <200004181502.JAA27464@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 09:02 AM 18/04/00 -0600, Vernon Schryver wrote: >You're mistaken, as America Online's SMTP redirection proxies demonstrate. >As I pointed out in the main IETF list, AOL is openly redirecting all SMTP >traffic from their dialups and nominally IP-addresed to the Internet at >large to boxes operated by AOL. Currently those seem to boxes do no >more than add SMTP Received: headers, but realsoonnow are supposed to >added an X-Apparently-From: header and to filter the entire message if >the box considers it spam. I don't think I'm mistaken - perhaps I wasn't clear. What I mean is that ISPs do this for their own customers only. Isn't that what you are saying AOL does? The point is that I know of no ISP who applies an interception proxy to, say, traffic transiting their network from a peer. >For at least a year, I think HTTP redirection proxies have been operated by >some ISP's, justified by the familiar efficiency reasoning. Yes - true...? >In both cases the ISP must be viewed as a third party, and in >security terms, a man in the middle. OK. That is the confusion. I was viewing the ISP as being in the same administrative domain, at least that is true for most dialup ISPs. In this case, the customer has a choice to change ISP if they don't like their policies. >Yes, and no one I know really objects to those techniques...well, sometimes >I grumble about it when one of Akamai's servers hiccups as seems to be >happening a lot this week. And some of those techniques make it between >hard and impossible to save useful bookmarks. I suspect that those techniques will ultimately lead to a deprecation in the use of interception proxies at source (for web traffic). But that is a few years away and we still have the problem of 100 or so Akamai-like companies - how does the user determine the closest / best proxy? I still believe the key is in proxy discovery. Or rather, replica discovery - since the content will be controlled by the content provider, even if is distributed by a third party. This will lead to a brokerage system similar to the peering and transit relationships we have already between ISPs... but what is still missing is how the user gets told where to look. DNS is one answer but may not be the best. E.g. I may not want the fastest / closest but rather the cheapest. This is what I hope we can start to work on in WREC. But first, we need to get our current documents rock solid, get some wider review (particularly of the known problems) and get them published and discussed widely. John --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Tue Apr 18 13:49:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09026 for ; Tue, 18 Apr 2000 13:49:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA05136; Tue, 18 Apr 2000 13:44:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 13:44:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA05117; Tue, 18 Apr 2000 13:44:38 -0400 (EDT) Received: from post.scotent.co.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA05100; Tue, 18 Apr 2000 13:44:35 -0400 (EDT) Received: from post.scotent.co.uk (194.128.108.250 -> post.scotent.co.uk) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 13:44:35 -0400 Received: from senmail2.scotent.co.uk ([10.71.2.26]) by post.scotent.co.uk (UUNET PIPEX simple 1.31) id SAA07806; Tue, 18 Apr 2000 18:42:02 +0100 (BST) Received: by SENMAIL2 with Internet Mail Service (5.0.1460.8) id ; Tue, 18 Apr 2000 18:41:40 +0100 Message-ID: <8708DF0C492CD211A2140008C72877C202C212EA@SENMAIL2> From: "John Waterson, ITS, SENM" To: "'John Martin'" , Vernon Schryver , wrec@cs.utk.edu Subject: RE: interception proxies Date: Tue, 18 Apr 2000 18:41:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain List-Unsubscribe: Hope I'm not intruding here as I'm not affiliated in any way, but as a network bod whose job is currently affected by these issues, I've been following the discussion with interest. John Martin wrote: > >In both cases the ISP must be viewed as a third party, and in > >security terms, a man in the middle. > > OK. That is the confusion. I was viewing the ISP as being in the same > administrative domain, at least that is true for most dialup ISPs. > In this case, the customer has a choice to change ISP if they don't > like their policies. I have to agree with Vernon on this one - the ISP *is* a third party, and the "change your provider" argument isn't always appropriate. Case in point: we offer a variety of HTTP-based services to our customers, several of which require the assistance of some hand-made redirection hacks to function properly. For certain of our customers - all of whom use the same dialup ISP - these hacks consistently but mysteriously break. After much scratching of heads over this, and having eliminated most other Firewall-y/explicit client-side proxying issues, it's now looking suspiciously like the problem stems from an interception-style proxy used by the ISP in question (exact reason as yet unknown). Now ideally, we'd like to get rid of our internal redirect hacking anyway, but that isn't straightforward for other reasons. In the meantime, what are we meant to do: tell our customers that it's a problem with their ISP, and insist that they switch? Doesn't really wash from a customer care perspective, does it? J. ________________________________________________________________________ This message is sent in confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. From owner-wrec@cs.utk.edu Tue Apr 18 14:41:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09741 for ; Tue, 18 Apr 2000 14:41:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA09675; Tue, 18 Apr 2000 14:36:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 14:36:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA09657; Tue, 18 Apr 2000 14:36:34 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA09641; Tue, 18 Apr 2000 14:36:32 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 14:36:32 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA23831; Tue, 18 Apr 2000 14:35:27 -0400 (EDT) Message-Id: <200004181835.OAA23831@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John Martin cc: Vernon Schryver , wrec@cs.utk.edu Subject: Re: interception proxies In-reply-to: Your message of "Tue, 18 Apr 2000 18:45:21 +0200." <4.2.0.58.20000418171234.00cc87e0@pop.netapp.com> Date: Tue, 18 Apr 2000 14:35:27 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > OK. That is the confusion. I was viewing the ISP as being in the same > administrative domain, at least that is true for most dialup ISPs. I think that's a big stretch. > In this > case, the customer has a choice to change ISP if they don't like their > policies. I don't see how this matters. The typical customer doesn't know whether the ISP is intercepting his traffic. All the customer knows is that his internet phone application, or game or whatever, doesn't work. And he's at least as likely to blame the vendor of the application as the ISP. And it's not always the case that the customer has the ability to change ISPs...it depends on where the customer is and how many ISPs serve that area and how many of those otherwise provide the service that the customer needs. When I travelled to Adelaide recently I was pretty much stuck with the dialup service provided by my ISP (interception proxy and all) because there was not enough time to find a better service. Not all problems are solved by competition, especially where the ability to make good decisions depends on knowledge of subtle technical issues. Keith From owner-wrec@cs.utk.edu Tue Apr 18 14:56:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10028 for ; Tue, 18 Apr 2000 14:56:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA11695; Tue, 18 Apr 2000 14:52:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 18 Apr 2000 14:52:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA11677; Tue, 18 Apr 2000 14:52:33 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA11663; Tue, 18 Apr 2000 14:52:27 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Tue, 18 Apr 2000 14:52:27 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA01432 for wrec@cs.utk.edu env-from ; Tue, 18 Apr 2000 12:52:24 -0600 (MDT) Date: Tue, 18 Apr 2000 12:52:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200004181852.MAA01432@calcite.rhyolite.com> To: wrec@cs.utk.edu Subject: Re: interception proxies List-Unsubscribe: > From: John Martin > ... > I don't think I'm mistaken - perhaps I wasn't clear. What I mean is that > ISPs do this for their own customers only. Isn't that what you are saying > AOL does? I don't think it makes sense to say that hosts of customers of an ISP are under the administrative control of the ISP. That idea would have the hosts of some outfits under the administrative control of their direct competitors. > >In both cases the ISP must be viewed as a third party, and in > >security terms, a man in the middle. > > OK. That is the confusion. I was viewing the ISP as being in the same > administrative domain, at least that is true for most dialup ISPs. In this > case, the customer has a choice to change ISP if they don't like their > policies. Thank you very much, but that I use ISDN does not put my computers in anyone else's administrative domain. And neither would the use of DSL, cable modems, ATM or FR PVC's or SVC's, or old fashioned leased lines. What does customer choice have to do with anything? As much as I'm shocked and horrified by third party redirection proxies, I don't like the idea of government rules on them. The topic at hand concerns the technical problems of redirection proxies, perhaps especially redirection proxies in administrative domains that differ from the domains of both the client and the server. > ... > I suspect that those techniques will ultimately lead to a deprecation in > the use of interception proxies at source (for web traffic). But that is a > few years away and we still have the problem of 100 or so Akamai-like > companies - how does the user determine the closest / best proxy? Why not the same way the the best ISP is determined? Note also that there "closest/best proxy" is not a simple metric. Is it fastest, most accurate, least likely to drop TCP connections, or best ad filtering? And never mind about the many ways to define "best ad filtering." What is best by any of those metrics for the person running an HTTP client is often not best for the people running the HTTP server. The many parties running the wires in between have their own, differing ways to determine "closest/best" > I still believe the key is in proxy discovery. Or rather, replica discovery > - since the content will be controlled by the content provider, even if is > distributed by a third party. This will lead to a brokerage system similar > to the peering and transit relationships we have already between ISPs... > but what is still missing is how the user gets told where to look. DNS is > one answer but may not be the best. E.g. I may not want the fastest / > closest but rather the cheapest. Maybe so, although for both technical and non-technical reasons, I have doubts. but never mind. > This is what I hope we can start to work on in WREC. But first, we need to > get our current documents rock solid, get some wider review (particularly > of the known problems) and get them published and discussed widely. yes. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Wed Apr 19 01:02:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19281 for ; Wed, 19 Apr 2000 01:02:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA19206; Wed, 19 Apr 2000 00:54:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 19 Apr 2000 00:54:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA19187; Wed, 19 Apr 2000 00:54:06 -0400 (EDT) Received: from ircache.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA19173; Wed, 19 Apr 2000 00:54:04 -0400 (EDT) Received: from ircache.net (192.52.106.29 -> ack.ircache.net) by cs.utk.edu (smtpshim v1.0); Wed, 19 Apr 2000 00:54:04 -0400 Received: from surf.ircache.net (surf.scd.ucar.edu [128.117.28.53]) by ircache.net (8.8.6/8.8.6) with ESMTP id VAA09908; Tue, 18 Apr 2000 21:54:03 -0700 (PDT) Received: from localhost (wessels@localhost) by surf.ircache.net (8.8.6/8.8.6) with ESMTP id WAA13965; Tue, 18 Apr 2000 22:53:57 -0600 (MDT) Date: Tue, 18 Apr 2000 22:53:57 -0600 From: Duane Wessels To: squid-users@ircache.net, ircache@ircache.net, isp-caching@isp-caching.com, wrec@cs.utk.edu Subject: Programme of the 5th Web Caching and Content Delivery Workshop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: The 5th Web Caching and Content Delivery Workshop will be held in Lisbon on 22-24 May 2000 adjacent to the TERENA Networking Conference. 35 papers were submitted by the end of March 2000. The Programme Committee has selected 16 papers to be presented in four workshop sessions. 12 papers were found to be of particular interest and authors were invited to present a poster. In addition, a keynote speech will open the workshop, which also hosts a panel on Content Distribution Technologies, a BoF on Web Performance Benchmarking and a BoF on standardization issues. The (provisional) programme is now available at: http://www.terena.nl/conf/wcw/programme.html More information on the Workshop venue, the logistics and how to register is available at http://www.terena.nl/conf/wcw/ Please note that the availability of hotel rooms at special reduced prices can be guaranteed only if you register before April 22nd. From owner-wrec@cs.utk.edu Wed Apr 19 15:38:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12755 for ; Wed, 19 Apr 2000 15:38:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA20291; Wed, 19 Apr 2000 15:34:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 19 Apr 2000 15:34:09 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA20271; Wed, 19 Apr 2000 15:34:08 -0400 (EDT) Received: from octo.memory.se (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA20257; Wed, 19 Apr 2000 15:34:05 -0400 (EDT) Received: from octo.memory.se (193.13.247.17 -> octo.memory.se) by cs.utk.edu (smtpshim v1.0); Wed, 19 Apr 2000 15:34:06 -0400 Received: from [193.13.248.90] by octo.memory.se for wrec@cs.utk.edu id VAC02774; Wed Apr 19 21:33:48 2000 Received: from henrik.localdomain (localhost [127.0.0.1]) by henrik.localdomain (8.9.3/8.9.3) with SMTP id VAA20641; Wed, 19 Apr 2000 21:25:07 +0200 Message-ID: <38FE0813.63A95C50@hem.passagen.se> Date: Wed, 19 Apr 2000 21:25:07 +0200 X-Mailer: Mozilla 3.01 (X11; I; Linux 2.2.13-reiserfs i586) MIME-Version: 1.0 Subject: Re: interception proxies References: <200004181443.IAA27247@calcite.rhyolite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Vernon Schryver From: Henrik Nordstrom Sender: hno@hem.passagen.se Cc: wrec@cs.utk.edu List-Unsubscribe: Content-Transfer-Encoding: 7bit Vernon Schryver wrote: > Agreed, NAT's and redirecting proxies are technically similar. With the significant distinction that NAT is performed on all traffic, while transparent proxies are only done on some. -- Henrik Nordstrom From owner-wrec@cs.utk.edu Wed Apr 19 16:58:01 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14255 for ; Wed, 19 Apr 2000 16:58:00 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA29755; Wed, 19 Apr 2000 16:53:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Wed, 19 Apr 2000 16:53:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA29737; Wed, 19 Apr 2000 16:53:15 -0400 (EDT) Received: from boreas.isi.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA29723; Wed, 19 Apr 2000 16:53:13 -0400 (EDT) Received: from boreas.isi.edu (128.9.160.161 -> boreas.isi.edu) by cs.utk.edu (smtpshim v1.0); Wed, 19 Apr 2000 16:53:13 -0400 Received: from isi.edu (pen-bc.isi.edu [128.9.144.252]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21036; Wed, 19 Apr 2000 13:53:05 -0700 (PDT) Message-ID: <38FE1CAF.9B9FC9EF@isi.edu> Date: Wed, 19 Apr 2000 13:53:03 -0700 From: Joe Touch X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Henrik Nordstrom CC: Vernon Schryver , wrec@cs.utk.edu Subject: Re: interception proxies References: <200004181443.IAA27247@calcite.rhyolite.com> <38FE0813.63A95C50@hem.passagen.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik Nordstrom wrote: > > Vernon Schryver wrote: > > > Agreed, NAT's and redirecting proxies are technically similar. > > With the significant distinction that NAT is performed on all traffic, > while transparent proxies are only done on some. NATs can do redirection based on any subsets of IP or TCP/UDP headers, just like redirecting proxies. From owner-wrec@cs.utk.edu Thu Apr 20 11:29:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13113 for ; Thu, 20 Apr 2000 11:29:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA06783; Thu, 20 Apr 2000 11:24:35 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 20 Apr 2000 11:24:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA06765; Thu, 20 Apr 2000 11:24:32 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA06746; Thu, 20 Apr 2000 11:24:27 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Apr 2000 11:24:27 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA23767 env-from ; Thu, 20 Apr 2000 09:22:21 -0600 (MDT) Date: Thu, 20 Apr 2000 09:22:21 -0600 (MDT) From: Vernon Schryver Message-Id: <200004201522.JAA23767@calcite.rhyolite.com> To: nat@livingston.com, wrec@cs.utk.edu Subject: draft-ietf-nat-protocol-complications (was Re: interception proxies) Cc: holdrege@lucent.com, srisuresh@yahoo.com List-Unsubscribe: > From: Pyda Srisuresh > To: Vernon Schryver , wrec@cs.utk.edu > Cc: nat@livingston.com, holdrege@lucent.com > ... > > Is there an RFC that includes the many complaints that have been made about > > NAT boxes in the main IETF list? > > Not an RFC. But, a draft addressing precisely this. > It is titled "Protocol Complications with the IP Network Address Translator". > . ... That draft does not mention anything about the IP fragmentation problem that we were talking about in the WREC list that provoked that comment. Many people act on the silly superstition that a 56 Kbit/sec modem or 128 Kbit/sec ISDN link is faster with a tiny MTU. When they do that, IP fragmentation must occur except when Path MTU works. (Do most NAT boxes do the right things when they see the DF bit?) (That draft doesn't list ICMP as an application whose payloads can need to be modified; consider the packet headers in some ICMP payloads.) NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection proxies are likely to do the wrong things when the bits in the payload that need to be modified are not in the first IP fragment, at least unless they do (the equivalent) of IP fragment reassembly before forwarding. Neither kind of box can even redirect incoming IP fragments to the correct local host, since the UDP and TCP port numbers are only in the first fragment. Tiny incoming IP fragments seem most likely when both TCP hosts or more than one UDP application (there can be >2 with multicast) are using NAT boxes. I've seen people run servers for various applications behind NAT boxes, including HTTP, SMTP and proprietary applications. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Thu Apr 20 18:50:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22437 for ; Thu, 20 Apr 2000 18:50:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA20382; Thu, 20 Apr 2000 18:44:40 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 20 Apr 2000 18:44:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA20364; Thu, 20 Apr 2000 18:44:39 -0400 (EDT) Received: from bbcr.uwaterloo.ca (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA20351; Thu, 20 Apr 2000 18:44:38 -0400 (EDT) Received: from bbcr.uwaterloo.ca (129.97.34.2 -> bbcr.uwaterloo.ca) by cs.utk.edu (smtpshim v1.0); Thu, 20 Apr 2000 18:44:38 -0400 Received: from hotmail.com (boutaba.uwaterloo.ca [129.97.34.80]) by bbcr.uwaterloo.ca (8.8.8/8.8.8) with ESMTP id RAA28543; Thu, 20 Apr 2000 17:33:53 -0400 (EDT) Message-ID: <38FF77B9.BC3D2D29@hotmail.com> Date: Thu, 20 Apr 2000 17:33:45 -0400 From: Networking 2000 Organization: Networking 2000 X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Networking 2000 Call for Participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; List-Unsubscribe: Content-Transfer-Encoding: 7bit +--------------------------------------------------------------+ | apologies if you receive multiple copies of this email | +--------------------------------------------------------------+ IFIP NETWORKING 2000 PARIS, May 14-19, 2000 CALL FOR PARTICIPATION http://netconf.lip6.fr/net2000 Networking 2000 conference is a joint conference of: HPN (High Performance Networking) Aaren 1987, Liege 1988, Berlin 1990, Liege 1992, Grenoble 1994, Palma 1995, New York 1997, Vienna 1998, Paris 2000. BC (Broadband Communications) Paris 1995, Montreal 1996, Lisboa 1997, Stuttgart 1998, Hong-Kong 1999, Paris 2000. PCN (Performance of Communication Networks) Paris 1981, Zurich 1984, Rio de Janeiro 1987, Barcelona 1990, Raleigh 1993, Lund 1998, Paris 2000. In addition to the conference program with its 3 parallel tracks, 12 tutorials and 9 mini-conferences featuring hot topics in networking are scheduled. -------------------------------------------------------------------------- From owner-wrec@cs.utk.edu Thu Apr 20 22:14:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25287 for ; Thu, 20 Apr 2000 22:14:09 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA00671; Thu, 20 Apr 2000 22:09:52 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Thu, 20 Apr 2000 22:09:52 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA00653; Thu, 20 Apr 2000 22:09:51 -0400 (EDT) Received: from ns.falconstor.net.tw (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA00640; Thu, 20 Apr 2000 22:09:37 -0400 (EDT) Received: from ns.falconstor.net.tw (202.145.80.152 -> as2po24.tc.ficnet.net.tw) by cs.utk.edu (smtpshim v1.0); Thu, 20 Apr 2000 22:09:39 -0400 Received: from SanJose (h1-168.falconstor.net.tw [172.30.1.168]) by ns.falconstor.net.tw (8.9.3/8.9.3) with SMTP id KAA19521; Fri, 21 Apr 2000 10:09:05 +0800 Message-ID: <002401bfab36$98bbee60$a8011eac@falconstor.net.tw> From: "Eric Chen" To: , , , , , Cc: Subject: FINAL CFP and deadline extension for SAINT -- please distribute Date: Fri, 21 Apr 2000 10:09:09 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01BFAB79.A28CEB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01BFAB79.A28CEB40 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear Colleagues, Please distribute the attached CFPs. My apologies if you receive = multiples copies as it is sent to multiple=20 mailing lists. --- Eric Chen SAINT-2001 Publicity Co-Chair =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D FINAL Call for Papers and Participation --DEADLINE EXTENSION-- The 2001 Symposium on Applications and the Internet SAINT-2001 http://computer.org/tab/TCI/SAINT/ http://www.ipsj.or.jp/kokusai/saint.htm (mirror site) San Diego, California, USA, January 8-12, 2001 This conference provides a forum for engineers and scientists in = academia, industry, and government to present their latest findings in the area of = Internet applications and the underlying technologies to support those applications. Areas of particular interest include, but anot limited to: - Agents and the Internet - Collaboration Technology - Digital Libraries - Distributed & Parallel Applications - Domain Specific Languages - E-Commerce - Internet Services - Mobile Computing - Multimedia Technology Tutorial & Workshops -------------------- The tutorial and workshops submissions deadlines have passed. Paper Submission ---------------- Form of Manuscript: Not to exceed 25 double-spaced, 8.5x11-inch pages (including figures, tables and regerences) in 10-12 point font. Number = each page, include an abstract, five to ten keywords, and the technical = area(s) most relevant to your pape, and the corresponding author's e-mail = address. Subnmission: All submissions will be done electronically. To submit a paper, go to http://witanweb.iit.nrc.ca/saint2001/ and follow the instructions. Important Deadlines ------------------- Paper Submission: May 8, 2000 (NEW DEADLINE -- this is FIRM) Author Notification: August 15, 2000 Final Manuscript: October 1, 2000 Proceedings ----------- The Proceedings of the conference and the workshops will be published by the IEEE Computer Society Press. Organizing & Program Committees ------------------------------- General Co-Chairs Ming T. Liu, The Ohio State Univ., USA Iwao Toda, Fujitsu Labs, Japan Program Co-Chairs Fred Douglis, AT&T Labs-Research, USA Katsuo Ikeda, Kyoto Univ., Japan For Further Information, Please Contact --------------------------------------- Mike Liu, The Ohio State University, Dept. of CIS, Columbus, = OH43210-1277, USA Phone: +1-614-292-6552; Fax: +1-614-292-2911; E-mail: = mike.liu@osu.edu or see the conference home page: http://computer.org/tab/TCI/SAINT/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_000_0021_01BFAB79.A28CEB40 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
 
   Please distribute the attached = CFPs.  My=20 apologies if you receive multiples copies as it is sent to multiple=20
mailing lists.
 
--- Eric Chen
SAINT-2001 Publicity Co-Chair
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 =      =20 FINAL Call for Papers and Participation
--DEADLINE = EXTENSION--

The=20 2001 Symposium on Applications and the=20 Internet
      SAINT-2001
  http://computer.org/tab/TCI/S= AINT/
      =20 http://www.ipsj.or.jp/ko= kusai/saint.htm=20 (mirror site)
  San Diego, California, USA,    = January=20 8-12, 2001

This conference provides a forum for engineers and = scientists=20 in academia,
industry, and government to present their latest = findings in the=20 area of
Internet applications and the underlying technologies to = support=20 those
applications. Areas of particular interest include, but anot = limited=20 to:

 - Agents and the Internet
 - Collaboration=20 Technology
 - Digital Libraries
 - Distributed & = Parallel=20 Applications
 - Domain Specific Languages
 -=20 E-Commerce
 - Internet Services
 - Mobile = Computing
 -=20 Multimedia Technology

Tutorial &=20 Workshops
--------------------
The tutorial and workshops = submissions=20 deadlines have passed.

Paper = Submission
----------------
Form of=20 Manuscript: Not to exceed 25 double-spaced, 8.5x11-inch = pages
(including=20 figures, tables and regerences) in 10-12 point font. Number = each
page,=20 include an abstract, five to ten keywords, and the technical = area(s)
most=20 relevant to your pape, and the corresponding author's e-mail=20 address.

Subnmission: All submissions will be done = electronically. To=20 submit a
paper, go to http://witanweb.iit.nrc.ca= /saint2001/=20 and follow the
instructions.

Important=20 Deadlines
-------------------
  Paper=20 Submission:     May 8, 2000 (NEW DEADLINE -- this is = FIRM)
  Author Notification:  August 15, 2000
  = Final=20 Manuscript:     October 1,=20 2000

Proceedings
-----------
  The Proceedings of the=20 conference and the workshops will be published
by the IEEE Computer = Society=20 Press.

Organizing & Program=20 Committees
-------------------------------
General = Co-Chairs
 =20 Ming T. Liu, The Ohio State Univ., USA
  Iwao Toda, Fujitsu = Labs,=20 Japan
Program Co-Chairs
  Fred Douglis, AT&T = Labs-Research,=20 USA
  Katsuo Ikeda, Kyoto Univ., Japan

For Further = Information,=20 Please Contact
---------------------------------------
Mike Liu, = The Ohio=20 State University, Dept. of CIS, Columbus, OH43210-1277, = USA
  =20 Phone: +1-614-292-6552; Fax: +1-614-292-2911; E-mail: mike.liu@osu.edu
or see the = conference=20 home page: http://computer.org/tab/TCI/S= AINT/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
------=_NextPart_000_0021_01BFAB79.A28CEB40-- From owner-wrec@cs.utk.edu Fri Apr 21 03:17:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09722 for ; Fri, 21 Apr 2000 03:17:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA14441; Fri, 21 Apr 2000 03:13:25 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 21 Apr 2000 03:13:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA14421; Fri, 21 Apr 2000 03:13:24 -0400 (EDT) Received: from web1405.mail.yahoo.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA14403; Fri, 21 Apr 2000 03:13:21 -0400 (EDT) Received: from web1405.mail.yahoo.com (128.11.23.169 -> web1405.mail.yahoo.com) by cs.utk.edu (smtpshim v1.0); Fri, 21 Apr 2000 03:13:21 -0400 Received: (qmail 24384 invoked by uid 60001); 21 Apr 2000 07:13:20 -0000 Message-ID: <20000421071320.24383.qmail@web1405.mail.yahoo.com> Received: from [209.239.198.221] by web1405.mail.yahoo.com; Fri, 21 Apr 2000 00:13:20 PDT Date: Fri, 21 Apr 2000 00:13:20 -0700 (PDT) From: Pyda Srisuresh Subject: Re: draft-ietf-nat-protocol-complications (was Re: interception proxies) To: Vernon Schryver , nat@livingston.com, wrec@cs.utk.edu Cc: holdrege@lucent.com, srisuresh@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: --- Vernon Schryver wrote: > > From: Pyda Srisuresh > > To: Vernon Schryver , wrec@cs.utk.edu > > Cc: nat@livingston.com, holdrege@lucent.com > > > > ... > > > Is there an RFC that includes the many complaints that have been made > about > > > NAT boxes in the main IETF list? > > > > Not an RFC. But, a draft addressing precisely this. > > It is titled "Protocol Complications with the IP Network Address > Translator". > > . ... > > > That draft does not mention anything about the IP fragmentation problem > that we were talking about in the WREC list that provoked that comment. > I dont know the exact problem you were talking about in the WREC list. But, IP fragmentation problem is listed as one of known NAT limitations in section 6.3 of as follows. We will add a note at the end of section-1 in the Complications draft, refering readers to known NAT limitations listed in RFC 2663 and the traditional-nat draft. 6.3. Translation of outbound TCP/UDP fragmented packets in NAPT setup Translation of outbound TCP/UDP fragments (i.e., those originating from private hosts) in NAPT setup are doomed to fail. The reason is as follows. Only the first fragment contains the TCP/UDP header that would be necessary to associate the packet to a session for translation purposes. Subsequent fragments do not contain TCP/UDP port information, but simply carry the same fragmentation identifier specified in the first fragment. Say, two private hosts originated fragmented TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, it is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted. > Many people act on the silly superstition that a 56 Kbit/sec modem or 128 > Kbit/sec ISDN link is faster with a tiny MTU. When they do that, IP > fragmentation must occur except when Path MTU works. (Do most NAT boxes > do the right things when they see the DF bit?) (That draft doesn't list What excatly is your concern with NAT boxes and DF bit? Please elaborate. > ICMP as an application whose payloads can need to be modified; consider > the packet headers in some ICMP payloads.) > Agreed. This is part of NAT operation described in traditional-nat draft. I dont believe, this belongs in "NAT complications" draft. > NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection NAT boxes are not same as ALGs. NAT boxes are those that implement a NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some number of ALGs. > proxies are likely to do the wrong things when the bits in the payload > that need to be modified are not in the first IP fragment, at least unless > they do (the equivalent) of IP fragment reassembly before forwarding. > You will need an ALG to do any kind of modification to the payload. What is the problem with IP fragments here? > Neither kind of box can even redirect incoming IP fragments to the correct > local host, since the UDP and TCP port numbers are only in the first > fragment. > When IP fragments are directed to the NAT box, NAT will need to reassemble the fragments into a single MTU prior to translation. And, NAT devices do just that. > Tiny incoming IP fragments seem most likely when both TCP hosts or more > than one UDP application (there can be >2 with multicast) are using NAT > boxes. I've seen people run servers for various applications behind > NAT boxes, including HTTP, SMTP and proprietary applications. > I believe, this is addressed in my previous comment already. > > Vernon Schryver vjs@rhyolite.com cheers, suresh __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com From owner-wrec@cs.utk.edu Fri Apr 21 12:09:05 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19957 for ; Fri, 21 Apr 2000 12:09:05 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA13230; Fri, 21 Apr 2000 12:02:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Fri, 21 Apr 2000 12:02:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA13212; Fri, 21 Apr 2000 12:02:27 -0400 (EDT) Received: from calcite.rhyolite.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA13199; Fri, 21 Apr 2000 12:02:23 -0400 (EDT) Received: from calcite.rhyolite.com (38.159.140.3 -> calcite.rhyolite.com) by cs.utk.edu (smtpshim v1.0); Fri, 21 Apr 2000 12:02:23 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id KAA01646 env-from ; Fri, 21 Apr 2000 10:01:29 -0600 (MDT) Date: Fri, 21 Apr 2000 10:01:29 -0600 (MDT) From: Vernon Schryver Message-Id: <200004211601.KAA01646@calcite.rhyolite.com> To: nat@livingston.com, wrec@cs.utk.edu Subject: Re: draft-ietf-nat-protocol-complications Cc: holdrege@lucent.com, srisuresh@yahoo.com List-Unsubscribe: > From: Pyda Srisuresh > To: Vernon Schryver , nat@livingston.com, > wrec@cs.utk.edu > Cc: holdrege@lucent.com, srisuresh@yahoo.com > ... > But, IP fragmentation problem is listed as one of known NAT limitations > in section 6.3 of as follows. draft-ietf-nat-traditional-03.txt is at neither ftp.isi.edu nor http://www.ietf.org/internet-drafts but please don't send me a private copy. I've intentionally not subscribed to nat@livingston.com. If you think the document says enough about IP fragmentation, then fine. > ... > What excatly is your concern with NAT boxes and DF bit? Please elaborate. My guess is that many NAT boxes choose to pretend to be too-smart-by-half bridges instead of routers and ignore the DF bit. > > ICMP as an application whose payloads can need to be modified; consider > > the packet headers in some ICMP payloads.) > > Agreed. This is part of NAT operation described in traditional-nat draft. > I dont believe, this belongs in "NAT complications" draft. If I were writing a document listing complications of NAT, I would include at least a reference to descriptions of other serious problem. > > NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection > > NAT boxes are not same as ALGs. NAT boxes are those that implement a > NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some > number of ALGs. I think I now understand the very positive, even pollyannaish tone of the document. And note again, that while I think third party redirection proxies are somewhere between criminal and completely unethical and immoral, I think NAT boxes have been and will continue for at least a while to be better than any of the (un)available alternatives, and so one might think my prejudices would cause me to not sensitive to a overly rosey pictures. > ... > > Neither kind of box can even redirect incoming IP fragments to the correct > > local host, since the UDP and TCP port numbers are only in the first > > fragment. > > > When IP fragments are directed to the NAT box, NAT will need to > reassemble the fragments into a single MTU prior to translation. > And, NAT devices do just that. They should, but do most? Public experience with somewhat related boxes is relevant. It was always completely obvious that an FDDI-Ethernet bridge must act like a router for large IP/FDDI packets, and generate IP fragments if allowed by the DF bit and send ICMP errors if not. However, for years more than one vendor of such bridges insisted in public simply droppping large FDDI frames was perfectly fine, and that FDDI hosts should just know enough to not use the FDDI MTU. The best FDDI-Ethernet bridges would IP fragment (and at wire speed), but none sent both honored the DF bit and sent ICMP errors. Vernon Schryver vjs@rhyolite.com From owner-wrec@cs.utk.edu Sat Apr 22 11:37:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16529 for ; Sat, 22 Apr 2000 11:37:05 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA19324; Sat, 22 Apr 2000 11:32:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Sat, 22 Apr 2000 11:32:26 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA19305; Sat, 22 Apr 2000 11:32:25 -0400 (EDT) Received: from web1406.mail.yahoo.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA19292; Sat, 22 Apr 2000 11:32:23 -0400 (EDT) Received: from web1406.mail.yahoo.com (128.11.23.170 -> web1406.mail.yahoo.com) by cs.utk.edu (smtpshim v1.0); Sat, 22 Apr 2000 11:32:24 -0400 Received: (qmail 12769 invoked by uid 60001); 22 Apr 2000 15:32:23 -0000 Message-ID: <20000422153223.12768.qmail@web1406.mail.yahoo.com> Received: from [209.239.202.152] by web1406.mail.yahoo.com; Sat, 22 Apr 2000 08:32:23 PDT Date: Sat, 22 Apr 2000 08:32:23 -0700 (PDT) From: Pyda Srisuresh Subject: Re: draft-ietf-nat-protocol-complications To: Vernon Schryver , nat@livingston.com, wrec@cs.utk.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: --- Vernon Schryver wrote: > > From: Pyda Srisuresh > > To: Vernon Schryver , nat@livingston.com, > > wrec@cs.utk.edu > > Cc: holdrege@lucent.com, srisuresh@yahoo.com > > > ... > > But, IP fragmentation problem is listed as one of known NAT limitations > > in section 6.3 of as follows. > > draft-ietf-nat-traditional-03.txt is at neither ftp.isi.edu nor > http://www.ietf.org/internet-drafts > Well, the following URL still works for me. http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-03.txt > but please don't send me a private copy. I've intentionally not > subscribed to nat@livingston.com. If you think the document says enough > about IP fragmentation, then fine. > Will do. > > > ... > > What excatly is your concern with NAT boxes and DF bit? Please elaborate. > > My guess is that many NAT boxes choose to pretend to be too-smart-by-half > bridges instead of routers and ignore the DF bit. > > I dont think so. I believe, NAT boxes do behave like standard routers with regard to DF bit. > > > ICMP as an application whose payloads can need to be modified; consider > > > the packet headers in some ICMP payloads.) > > > > Agreed. This is part of NAT operation described in traditional-nat draft. > > I dont believe, this belongs in "NAT complications" draft. > > If I were writing a document listing complications of NAT, I would > include at least a reference to descriptions of other serious problem. > > Will do. > > > NAT boxes (or perhaps "ALG" in the terms of that draft) and redirection > > > > NAT boxes are not same as ALGs. NAT boxes are those that implement a > > NAT type (typically NAPT or Basic-NAT, as described RFC 2663) and some > > number of ALGs. > > I think I now understand the very positive, even pollyannaish tone > of the document. And note again, that while I think third party > redirection proxies are somewhere between criminal and completely > unethical and immoral, I think NAT boxes have been and will continue > for at least a while to be better than any of the (un)available > alternatives, and so one might think my prejudices would cause me > to not sensitive to a overly rosey pictures. > > > > ... > > > Neither kind of box can even redirect incoming IP fragments to the > correct > > > local host, since the UDP and TCP port numbers are only in the first > > > fragment. > > > > > When IP fragments are directed to the NAT box, NAT will need to > > reassemble the fragments into a single MTU prior to translation. > > And, NAT devices do just that. > > They should, but do most? > I believe, they do. As recipients of end-node packets, they are required to confirm to RFC 1122 ("Requirements for Internet Hosts -- Communication Layers"). Beyond this, I cannot comment further on existing NAT implementations. I am not aware of DF-bit violation problems, specifically with NAT routers. > Public experience with somewhat related boxes is relevant. It was always > completely obvious that an FDDI-Ethernet bridge must act like a router > for large IP/FDDI packets, and generate IP fragments if allowed by the DF > bit and send ICMP errors if not. However, for years more than one vendor > of such bridges insisted in public simply droppping large FDDI frames was > perfectly fine, and that FDDI hosts should just know enough to not use > the FDDI MTU. The best FDDI-Ethernet bridges would IP fragment (and at > wire speed), but none sent both honored the DF bit and sent ICMP errors. > Vernon - If there exists a large-scale problem in the market with regard to violation of DF bit semantics by NAT routers, I agree, we ought to document that, just as much as we ought to document such a problem with regard to FDDI-ethernet bridges or even some routers for that matter. But, I am not aware of such a large-scale problem with NAT routers. > > Vernon Schryver vjs@rhyolite.com > regards, suresh __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com From owner-wrec@cs.utk.edu Sat Apr 22 21:25:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21133 for ; Sat, 22 Apr 2000 21:25:04 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA18769; Sat, 22 Apr 2000 21:20:24 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Sat, 22 Apr 2000 21:20:24 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA18751; Sat, 22 Apr 2000 21:20:23 -0400 (EDT) Received: from ids2.idsonline.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA18738; Sat, 22 Apr 2000 21:20:22 -0400 (EDT) Received: from ids2.idsonline.com (205.177.236.32 -> ids2.idsonline.com) by cs.utk.edu (smtpshim v1.0); Sat, 22 Apr 2000 21:20:22 -0400 Received: from 21rst-century.com (laurel-md-186.idsonline.com [209.8.42.186]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id VAA25264; Sat, 22 Apr 2000 21:32:12 -0400 Message-ID: <39024F7B.7590BF26@21rst-century.com> Date: Sat, 22 Apr 2000 21:18:52 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Pyda Srisuresh CC: Vernon Schryver , nat@livingston.com, wrec@cs.utk.edu Subject: Re: draft-ietf-nat-protocol-complications References: <20000422153223.12768.qmail@web1406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Pyda Srisuresh wrote: > --- Vernon Schryver wrote: > > > From: Pyda Srisuresh > > > To: Vernon Schryver , nat@livingston.com, > > > wrec@cs.utk.edu > > > Cc: holdrege@lucent.com, srisuresh@yahoo.com > > > > > ... > > > But, IP fragmentation problem is listed as one of known NAT limitations > > > in section 6.3 of as follows. > > > > draft-ietf-nat-traditional-03.txt is at neither ftp.isi.edu nor > > http://www.ietf.org/internet-drafts > > > > Well, the following URL still works for me. > http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-03.txt > Odd, I find that http://www.ietf.org/internet-drafts/draft-ietf-nat-traditional-04.txt is required Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc P.O. Box 99 Clifton, Virginia 20124 Phone : 703-222-3250 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-wrec@cs.utk.edu Tue Apr 25 08:35:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10907 for ; Tue, 25 Apr 2000 08:35:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA29742; Tue, 25 Apr 2000 08:29:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.12); Tue, 25 Apr 2000 08:29:58 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA29724; Tue, 25 Apr 2000 08:29:57 -0400 (EDT) Received: from darren2.lnk.telstra.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA29702; Tue, 25 Apr 2000 08:29:47 -0400 (EDT) Received: from darren2.lnk.telstra.net (139.130.53.33 -> darren2.lnk.telstra.net) by cs.utk.edu (smtpshim v1.0); Tue, 25 Apr 2000 08:29:49 -0400 Received: (from root@localhost) by darren2.lnk.telstra.net (8.9.1/8.8.7) id MAA16605; Tue, 25 Apr 2000 12:29:42 GMT From: Darren Reed Message-Id: <200004251229.WAA29833@avalon.reed.wattle.id.au> Subject: Re: Vern Schryver's comments on IP Fragments and NAT To: wrec@cs.utk.edu, vjs@calcite.rhyolite Date: Tue, 25 Apr 100 22:29:18 +1000 (EST) In-Reply-To: from "James R Grinter" at Apr 25, 0 01:08:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text List-Unsubscribe: [...] > I'm talking about > > client A, IP address 10.1 > client B, IP address 10.2 > redirection proxy P, IP address 192.0.2.1 > distant HTTP server S, IP address 172.16.0.1 > > Clients A and B try to open HTTP/TCP/IP connections with S. They > both have private Ethernets and so like MTU=1500 ad MSS=1460, and > they have typically misconfigured PPP/modem links with MTU=512. > > Both clients send SYN's to get rolling. Since they're using common > operating systems that don't try hard, they both use the same IP ID's > their corresponding HTTP/TCP/IP packets. > The first thing they do after the 3-way handshake is try to GET similar > 600 byte URLs. Or perhaps they do 1000 byte PUT's. Thus, they both send > IP fragments with the same IP ID's, the same IP destination address, > and differing only in IP source address (10.1. vs.10.2) and fragmentary > HTTP payload. For packets going out, the problem is for the web server at the other end and you're right - it's got no chance in hell in being able to sanely deal with this situation. If the NAT box was changing the IP ID field so that all packets went out with "different" ones, then yes, it has a chance. > However, what does server S do > when it gets the second IP fragments? The fragments from the HTTP > clients as received at S have the same IP source and destination addresses > and IP ID's. At best they'll have differing IP offsets and lengths, > but at worst even those will be the same. Right. > The only fix is for the proxy P to assign its own IP's, but that has You mean IP ID's here, I assume, not IP's ? > serious problems given the small size of the IP ID and relatively long > lifetimes (a few seconds) of client streams. 64K packets in a few > seconds is not impressive in a world of Tbit/sec routers. 64K 500 byte > packets in 3 seconds is only 10 MByte/sec, less than a single FDDI > interface. Consider that many popular web sites can't answer in less > than 10 seconds, and you're talking about less than a T3. I think the main requirement here is that successive packets to the destination host must have different IP ID's (pre-fragmentation). [...] > > ... > > A sends to S > > P 'nat's' the dest S to the dest C > > ... > > A NAT box can also do the wrong thing with IP fragmentation, and in more > plausible scenarioes than 600 byte URL's or PUT's. Consider two client > hosts behind a single NAT box that has been configured with a 500 byte > PPP MTU, path MTU discovery is not working (probably a redundant statement > in this case), both client hosts are using ~1500 byte MSS's and MTU's, > and are fetching from the same HTTP server. The NAT box will be receiving > IP packets with identical IP source and destination addresses, but > differing IP ID's. Somehow I suspect many NAT boxes won't do the require > (equivalent of) IP fragment reassembly to recover the port numbers to know > how to demux the stream from the Internet into correct local destination > IP and Ethernet addresses. The NAT box is just as helpless as the web server. If both packets sent by the web server have the same IP ID, are destined for different ports but the same IP# and require demux'ing in the NAT box, if any fragmentation occurs, the NAT box cannot defragment or send fragments to the correct destination. Even if the initial packets come in with different port #'s, the later fragments do not. There's no real way around this, so long as both origins can be the "same" at any given point in time. Darren p.s. I'm not on this list, someone forwarded me this as being relevant to IP Filter...