Re: recommendation against publication of draft-cerpa-necp-0
Peter Deutsch wrote: g'day, "Michael B. Bellopede" wrote: ... Regardless of what occurs at higher layers, there is still the problem of changing the source address in an IP packet which occurs at the network(IP) layer. The Content Services Business Unit of Cisco (Fair Disclosure time - that's my employer and my business unit) sells a product called "Local Director". LD is intended to sit in front of a cluster of cache engines containing similar data, performing automatic distribution of incoming requests among the multiple caches. It does this by intercepting the incoming IP packets intended for a specific IP address and multiplexing it among the caches. Are we doing something illegal or immoral here? No, we're offering hot spare capability, load balancing, increased performance, and so on. The net is a better place than it was a few years ago, when a web page would contain a list of links and an invitation to "please select the closest server to you". We also have a product called "Distributed Director", which is essentially a DNS server appliance which can receive incoming DNS requests (e.g for "www.cnn.com") and reroute it to one or more cache farms for distributed load balancing. If intercepting IP addresses is evil, then presumably intercepting DNS requests is more evil, since it's higher up the IP stack? No, it's a legitimate tool for designing massive Content Service Networks of the scale needed in the coming years. These are both conformant with RFC 1122/1123 (together STD-3) because they redistribute IP addresses within a stub network. Same with DHCP. The questionable practices (wrt STD-3) arise when sourcing IP addresses not delegated to your authority (i.e., running these services on transit to someone else's server), rather than running them as a head-end to your own stub. Joe
Re: recommendation against publication of draft-cerpa-necp-0
At 17.29 -0700 2000-04-07, Peter Deutsch wrote: LD is intended to sit in front of a cluster of cache engines containing similar data, performing automatic distribution of incoming requests among the multiple caches. It does this by intercepting the incoming IP packets intended for a specific IP address and multiplexing it among the caches. What you are doing is giving a product to the service provider, which is the one which owns the services which you load balance between. In the case of a transparent proxy which is discussed in this thread, the interception is done neither by the service provider (i.e. CNN or whoever) nor by the customer, and neither of them are informed about what is happening. That is a big difference. paf
Re: recommendation against publication of draft-cerpa-necp-0
Hi Patrik, Patrik Fältström wrote: At 17.29 -0700 2000-04-07, Peter Deutsch wrote: LD is intended to sit in front of a cluster of cache engines containing similar data, performing automatic distribution of incoming requests among the multiple caches. It does this by intercepting the incoming IP packets intended for a specific IP address and multiplexing it among the caches. What you are doing is giving a product to the service provider, which is the one which owns the services which you load balance between. In the case of a transparent proxy which is discussed in this thread, the interception is done neither by the service provider (i.e. CNN or whoever) nor by the customer, and neither of them are informed about what is happening. That is a big difference. I agree, and would welcome a BCP document pointing out this distinction and explaining why the later is harmful. Banning publication of technologies a priori (as I argue elsewhere) wont stop the technology being developed, wont stop the practice and just leads to the IETF abdicating it role as a meeting point for technical innovation. - peterd
RE: recommendation against publication of draft-cerpa-necp-0
1. an Internet service provider which deliberately intercepts traffic (say, an IP packet) which was intended for one address or service, and delivers it to another address or service (say that of an interception proxy) may be misrepresenting the service it provides (it's not really providing IP datagram delivery service because IP doesn't work this way). Okay, I think I see the mistake you're making. You're crossing abstraction layers and conflating two different things (the name of a service with the end point of the connection to that service). You are criticizing the moving of an endpoint when what you really object to is the misrepresentation of a service. Or do you also object to HTTP redirects, dynamic URL rewriting, CNAMEs, telephone Call Forwarding, or post office redirecting of mail after you move? I think we are confusing the issue here. Earlier in this thread I found the following written by Keith Moore: 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. Regardless of what occurs at higher layers, there is still the problem of changing the source address in an IP packet which occurs at the network(IP) layer. Michael B. Bellopede [EMAIL PROTECTED] "There is no spoon."
RE: recommendation against publication of draft-cerpa-necp-0
Dennis- That is not a fair statement to make to an end-user. My end-users have no say about what client software, services, or ISP solutions provided. -Michael B. Bellopede [EMAIL PROTECTED] Leslie Daigle wrote: As an end-user, I can be as aware as I like about the security issues, but if client software doesn't support security, and/or my ISP, services don't support it, there's nothing I can do. Huh? You have a choice: (a) obtain a client that does support security; and (b) get a new ISP. Both are plentiful.
Re: recommendation against publication of draft-cerpa-necp-0
g'day, "Michael B. Bellopede" wrote: ... Regardless of what occurs at higher layers, there is still the problem of changing the source address in an IP packet which occurs at the network(IP) layer. The Content Services Business Unit of Cisco (Fair Disclosure time - that's my employer and my business unit) sells a product called "Local Director". LD is intended to sit in front of a cluster of cache engines containing similar data, performing automatic distribution of incoming requests among the multiple caches. It does this by intercepting the incoming IP packets intended for a specific IP address and multiplexing it among the caches. Are we doing something illegal or immoral here? No, we're offering hot spare capability, load balancing, increased performance, and so on. The net is a better place than it was a few years ago, when a web page would contain a list of links and an invitation to "please select the closest server to you". We also have a product called "Distributed Director", which is essentially a DNS server appliance which can receive incoming DNS requests (e.g for "www.cnn.com") and reroute it to one or more cache farms for distributed load balancing. If intercepting IP addresses is evil, then presumably intercepting DNS requests is more evil, since it's higher up the IP stack? No, it's a legitimate tool for designing massive Content Service Networks of the scale needed in the coming years. Can a combination of DD and LD be misused? Sure, but I hope you're not suggesting that we should be cancelling these products because somebody might misuse them? There are all kinds of technologies which can be used or abused. Banning discussion of such technologies based upon an individual's sense of what is a moral or legal use of that technology (when the individual doesn't justify this through any particular creditials in either morality or the law) strikes me as somewhat naive, to say the least... - peterd -- -- Peter Deutsch work email: [EMAIL PROTECTED] Technical Leader Content Services Business Unit private: [EMAIL PROTECTED] Cisco Systems or : [EMAIL PROTECTED] Alcohol and calculus don't mix. Never drink and derive. --
