interception proxies
There has been a lot of discussion about the problems associated with so-called "interception proxies". This discussion is very much within the charter of the WREC WG. In fact, we even have a current draft whose sole purpose is to document such problems. The known problems draft is at: draft-ietf-wrec-known-prob-01.txt This is the first of two very useful documents being produced by WREC; the first, a taxonomy of terminology is available as: draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. To join WREC, use the following: mailto:[EMAIL PROTECTED]?Subject=subscribe ...or send a note to [EMAIL PROTECTED] with "subscribe" in the subject. I suggest we move this particular discussion to WREC. Rgds, 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 ---
Re: breaking the IP model (or not)
it's completely natural that people will try such approaches - they are trying to address real problems and they want quick solutions to those problems. In particular, they will try such approaches if they are not presented with better alternatives. there's something odd to my ear about people needing to *be presented* with better alternatives than doing harm to the architecture as opposed to those people *developing* better alternatives. I suspect there's something about the current economic climate that favors development of quick fixes over development of sane ones. but the apparent shortsightedness still bothers me. Keith
Re: breaking the IP model (or not)
It's much worse than that. In the End to End model, far too many of our problems require changing all the end systems to solve. However, that's extremely difficult to do, particularly as there is little or no incentive (the DCA/DISA had guns, and control of the IMPs in 1982/1983 to force the NCP-TCP/IP conversion - there is no equivalent agency today). Almost all of the pressure created by the growth of the Internet is on the network operators and their vendors (e.g. router vendors), rather than on the users and the end systems (and the end system vendors, e.g. PCs, Macs, Suns, etc). It's also bad that there is little or no integration of intermediate system vendors with end system vendors (or vice versa), because that results in insufficient sharing of information between those two industry segments. The IETF should be facilitating information exchange, but it isn't working as well as it should (otherwise we wouldn't have these problems, right?). So, with nearly all the pressure on the operators and the vendors that serve them, the "solutions" they come up with are necessarily pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they have to deal with the reality that they can't change the end systems themselves, or require them to be changed. This is a structural problem. Until the situation changes, we're going to keep on seeing ugly hacks that do violence to the Internet architectural model deployed, marketed, touted as "solutions." an author of RFC 1627, Erik [EMAIL PROTECTED]
Re: breaking the IP model (or not)
It's also bad that there is little or no integration of intermediate system vendors with end system vendors (or vice versa), because that results in insufficient sharing of information between those two industry segments. The IETF should be facilitating information exchange, but it isn't working as well as it should (otherwise we wouldn't have these problems, right?). it's not clear that the problems are caused by lack of information exchange, given time-to-market pressures that cause folks to ship product now and deny causing problems later.
Re: prohibiting RFC publication
At 02:38 AM 4/9/00 +0100, Martin J.G. Williams wrote: As far as i'm concerned (IMHO) if the standards bodies were to be driven by the vendors, then they would become no more than sanitised purveyors of de facto standards, and je jure standards would be relegated to being nothing more than "misty-eyed" memories. Are you saying that IETF specifications are de jure standards? If so, don't tell the State Department, they don't know that :^) IETF Specifications are indeed de facto standards - they are standards in part because the community calls them such, but mostly because the community implements them and uses them. I think what you meant to say is that they would be nothing more than purveyors of the proprietary protocols that vendors chose to make semi-public.
Re: interception proxies
From: John Martin [EMAIL PROTECTED] There has been a lot of discussion about the problems associated with so-called "interception proxies". This discussion is very much within the charter of the WREC WG. In fact, we even have a current draft whose sole purpose is to document such problems. The known problems draft is at: draft-ietf-wrec-known-prob-01.txt This is the first of two very useful documents being produced by WREC; the first, a taxonomy of terminology is available as: draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. The problems draft is interesting and depressing. All of the problems listed are technical nits. If you assume that "traffic redirection" and an "interception proxy" are good things, then you might well worry about the "lack of HTTP/1.1 compliance for proxy caches" or whether "interception proxies break client cache directives." You will not question their desirability or even their long term utility in the face of actions by users to protect their privacy or defend against censorship. You won't even worry about what's going to hit the fan when the big advertisers realize that their wonderful ads are being filtered and overwritten with other people's ads by interception proxies. I don't know whether to be depressed, encouraged, or neutral that WREC seems to not be about port 25 traffic redirection and interception proxies, such as AOL's effort. That there is no mention of the problems that IP fragmentation can cause interception proxies is depressing. To join WREC, use the following: mailto:[EMAIL PROTECTED]?Subject=subscribe ...or send a note to [EMAIL PROTECTED] with "subscribe" in the subject. I suggest we move this particular discussion to WREC. Joining that mailing list would not be useful, prudent, or honest for people with sentiments like mine. Moving the question of the wisdom of such proxies to WREC would be equivalent to moving the question of the wisdom of wiretapping to the wiretapping working group. At best the group WG consensus can be predicted. At worst, the discussion would legitimately be considered disruptive and irrelevant. It appears that the WREC working group is doing exactly as someone lamented a day or two ago about working groups in general, and not considering the question of whether the mechanisms they are working are good ideas in the larger scheme of things. WREC is only concerned with making them as good as possible. (Yes, I checked recent months of the archives at ftp://cs.utk.edu/pub/wrec/) It is interesting, but consistent with that observation that the problems draft contains no mention of problems should clients use end to end encryption or even just authentication with message authentication codes that care about the current time or the particular client. I don't know what to think of the absence of the string "https" in all three drafts. The passing, convoluted reference to encryption and SSL in section 9.2.2 of the taxonomy draft confuses me. If I were optimistic, I would hope that the taxonomy document is the wrong location is the reason its privacy section is so shallow. Vernon Schryver[EMAIL PROTECTED]
OSP
Hi , I am interested in the Open Settlement Protocol for VoIP. I have check the web site for GRIC and TransNexus, and got some information. It will be appreciated if someone here can point to me more places to get info on this topic. Thanks, Yixin (James) Zhu
Re: OSP
Yixin Zhu wrote: Hi , I am interested in the Open Settlement Protocol for VoIP. I have check the web site for GRIC and TransNexus, and got some information. It will be appreciated if someone here can point to me more places to get info on this topic. Thanks, Yixin (James) Zhu Hi, I have another link in my bookmarks which may be of som ehelp; http://www.oasis-open.org/cover/openSetProt.html Regards Himanshoo
Re: interception proxies
wrec is supposed to be about *web* replication and caching. which probably doesn't include email. so I can hardly blame them for not talking about port 25. since other kinds of interception proxies exist, perhaps they should clarify their document slightly to say it's about web interception proxies. naturally I would encourage folks who are concerned about web interception proxies to join the wrec group and/or to submit comments and corrections about their documents. Keith
RE: interception proxies
Joe, Am I to presume by your statement that you are of the mind that the time for considering whether vs. which has already come and gone? Is there anyone on this list who thinks that? -Original Message- From: Joe Touch [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 11, 2000 4:03 PM To: Vernon Schryver Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:Re: interception proxies Vernon Schryver wrote: From: John Martin [EMAIL PROTECTED] There has been a lot of discussion about the problems associated with so-called "interception proxies". This discussion is very much within the charter of the WREC WG. In fact, we even have a current draft whose sole purpose is to document such problems. The known problems draft is at: draft-ietf-wrec-known-prob-01.txt This is the first of two very useful documents being produced by WREC; the first, a taxonomy of terminology is available as: draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. The problems draft is interesting and depressing. All of the problems listed are technical nits. This was a choice - in some larger sense, if sourcing other-owned IP addresses or TCP connections is considered an architectural problem, needs to come down from above, rather than up from WREC. f I don't know whether to be depressed, encouraged, or neutral that WREC seems to not be about port 25 traffic redirection and interception proxies, such as AOL's effort. That there is no mention of the problems that IP fragmentation can cause interception proxies is depressing. The problems of IP fragmentation are not unique to web caching or replication proxies. They affect all interception proxies. The issue of inteception proxies was around long before WREC, and is more than just a caching or replication issue. Joining that mailing list would not be useful, prudent, or honest for people with sentiments like mine. Moving the question of the wisdom of such proxies to WREC would be equivalent to moving the question of the wisdom of wiretapping to the wiretapping working group. At best the group WG consensus can be predicted. At worst, the discussion would legitimately be considered disruptive and irrelevant. WREC is about proxies - there are plenty of 'architecturally conformant' ways to do proxies. If the problems with transparent proxies is an issue, WREC may be a good place (but not the only place) to solicit input. It appears that the WREC working group is doing exactly as someone lamented a day or two ago about working groups in general, and not considering the question of whether the mechanisms they are working are good ideas in the larger scheme of things. WREC is only concerned with making them as good as possible. (Yes, I checked recent months of the archives at ftp://cs.utk.edu/pub/wrec/) That's the property of WGs in general, by construction. These questions sometimes get addressed in BOFs, but there is also often too much momentum or political interest in establishing a 'standardizing presence' in an area. By the time a WG is formed, the time for 'whether' has often passed in favor of 'which'. Joe
Re: interception proxies
"BookIII, Robert" wrote: Joe, Am I to presume by your statement that you are of the mind that the time for considering whether vs. which has already come and gone? Is there anyone on this list who thinks that? With respect to 'inside the WG', yes, the assumption has been (to me) that the time had passed, with respect to the WG charter. There is always time outside the WG to do so, or (if directed) to recharter, pending interest and approval of the WG as well. Joe
Re: interception proxies
From: Joe Touch [EMAIL PROTECTED] ... The problems draft is interesting and depressing. All of the problems listed are technical nits. This was a choice - in some larger sense, if sourcing other-owned IP addresses or TCP connections is considered an architectural problem, needs to come down from above, rather than up from WREC. f 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. If only I could have had one pre-IPO share for every time I've been told "we can't think about that; we'll have to ask to marketing" ... on the other hand, most of those shares would be merely expensive wallpaper. ... That there is no mention of the problems that IP fragmentation can cause interception proxies is depressing. The problems of IP fragmentation are not unique to web caching or replication proxies. They affect all interception proxies. The issue of inteception proxies was around long before WREC, and is more than just a caching or replication issue. Which is why it was depressing. Oh, well, perhaps a future version of the Problems draft will consider that issue and say as others wrote, it's not a problem and can be fixed with big buffers watching IP ID's, avoiding UDP, assuming good MSS's or discovery prevent TCP/IP fragmentation, or whatever. ... That's the property of WGs in general, by construction. These questions sometimes get addressed in BOFs, but there is also often too much momentum or political interest in establishing a 'standardizing presence' in an area. By the time a WG is formed, the time for 'whether' has often passed in favor of 'which'. Which was exactly the lament the other day. By the time a Last Call rolls around, it's months and $B of market cap late to worry about "whether?" There are always screams about the unfairness of raising "whether" at such a late date and vague reference to nearly completed implementations that will have billions of installations by the end of the quarter, or when IPv8 replaces IPv4 at the latest, exactly as we heard in response to the initial comments about draft-cerpa-necp-02.txt. I don't have a fix for the problem, except to steadfastly refuse to heed cries from partisans that "whether?" is out of order until it really is. ... ] From: "BookIII, Robert" [EMAIL PROTECTED] ] Joe, ]Am I to presume by your statement that you are of the mind that the ] time for considering whether vs. which has already come and gone? Is there ] anyone on this list who thinks that? I don't speak for Joe, but it's clearly over. Unlike the wiretapping question, interception proxies are too near to the technical interests (and pocketbooks) of too many IETF participants. You must admit that they sound like cool hacks, unlike merely forwarding copies of bits. Vernon Schryver[EMAIL PROTECTED]
Re: interception proxies
... Joining that mailing list would not be useful, prudent, or honest for people with sentiments like mine. Moving the question of the wisdom of such proxies to WREC would be equivalent to moving the question of the wisdom of wiretapping to the wiretapping working group. At best the group WG consensus can be predicted. At worst, the discussion would legitimately be considered disruptive and irrelevant. WREC is about proxies - there are plenty of 'architecturally conformant' ways to do proxies. If the problems with transparent proxies is an issue, WREC may be a good place (but not the only place) to solicit input. Correction - slip of the keyboard. What I meant was that WREC is _NOT_ about proxies. It's about caching and replication. Proxies are one part of the architecture, but not the only part. Joe
Re: interception proxies
This was a choice - in some larger sense, if sourcing other-owned IP addresses or TCP connections is considered an architectural problem, needs to come down from above, rather than up from WREC. sounds like a convenient excuse to me... where did the wrec folks get the idea that the IP specification was obsolete? Keith
Re: interception proxies
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. agree entirely. but for this to work there have to be folks within the WG who are willing to raise a fuss. Keith
Re: interception proxies
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
Re: rfc-editor?
I have a question: so ~who~ is the RFC-Editor these days given that The RFC-Editor (aka Jon Postel) has passed on? I've groveled thru the www.ietf.org and the www.rfc-editor.org pages and can't see who all is presently acting in this role, but perhaps I simply missed it. brought to you by most of the same folk it has been for years, sadly minus one. randy
Re: rfc-editor?
I found the following in rfc2028.. 2.1 The Request for Comments Editor The RFC publication series [B] is managed by an Editor (which may in practice be one or more individuals) responsible both for the mechanics of RFC publication and for upholding the traditionally high technical and editorial standards of the RFC series. The functions of the RFC Editor are performed by one or more individuals or organizations selected in accordance with the procedures defined by the RFC Editor charter [G]. And [G] is simply.. [G] RFC Editor Charter, Work in Progress. ..and perusal with various search engines/tools yields no further information about "RFC Editor Charter", and rfc2028 was written in late 1996. [EMAIL PROTECTED] said: brought to you by most of the same folk it has been for years Well, uh, besides Joyce Reynolds, I'm curious as to who all are actively contributing to that role. Is it folks on the IAB? Is it folks at IANA (and, uh, who zactly these days is affiliated with IANA besides the well-known board? who're the doers?)? Is it just anybody at ISI? Is it part of being on the IESG being an AD? Is it WG chairs? Who gets to decide? How is it presently decided who may participate in acting in the RFC-Editor role? I'm just sorta curious cuz it seems to be an opaque object in the otherwise fairly well-defined works (of the IETF et al). thanks, JeffH
Re: interception proxies
Date: Tue, 11 Apr 2000 16:47:04 -0600 (MDT) From: Vernon Schryver [EMAIL PROTECTED] Which is why it was depressing. Oh, well, perhaps a future version of the Problems draft will consider that issue and say as others wrote, it's not a problem and can be fixed with big buffers watching IP ID's, avoiding UDP, assuming good MSS's or discovery prevent TCP/IP fragmentation, or whatever. And the latest kludge which has been called to my attention is ISP's that tamper with the MSS values in TCP SYN packets in flight. This is done to work around smaller MTU's caused by PPP over Ethernet (and other tunnelling mechanisms) interacting badly with Path MTU discovery failures, which in turn are caused by firewalls that filter out the wrong sorts of ICMP packets. Hmmm, yet another thing which IPSEC will break. - Ted
Re: interception proxies
On Tue, 11 Apr 2000, Theodore Y. Ts'o wrote: And the latest kludge which has been called to my attention is ISP's that tamper with the MSS values in TCP SYN packets in flight. This is done to work around smaller MTU's caused by PPP over Ethernet (and other tunnelling mechanisms) interacting badly with Path MTU discovery failures, which in turn are caused by firewalls that filter out the wrong sorts of ICMP packets. Hmmm, yet another thing which IPSEC will break. Any specific ISP's that one could care to name? Coming from an ISP, what I've seen in general is that most routers have just enough cycles in the forwarding path to keep up with the offered traffic, much less sit around watching for SYN's in flight so as to mutate the MSS values. In fact, I'd think this would be more of an end system issue rather than a "core" or a "backbone" issue, where the end system is the box prior to the ISP handoff and not quite under the ISP's control and not the end system as in the end2end tcp/ip sense of the word. /vijay
