The use of "load balancing" technologies is growing rapidly
because these devices provide useful functionality. These
devices utilize many different techniques, only some of which
can be characterized as "interception proxies" or "reverse
network address translation." For example, using MAC
The use of "load balancing" technologies is growing rapidly
because these devices provide useful functionality. These
devices utilize many different techniques, only some of which
can be characterized as "interception proxies" or "reverse
network address translation." For example, using MAC
Keith,
Without comments on other aspects of the technology in question, I
would like to make some observations about the security aspects of
the processing you cite as violating IP.
By now we all should know that it is a bad idea to rely on an
unauthenticated IP address as a basis for
Howdy,
Stephen Kent wrote:
Thus, if anyone is
really concerned about know with whom they are communicating, and
whether a packet was modified in transit, they should be using these
standards security technologies. Many web sites for which these
security concerns are significant already
By now we all should know that it is a bad idea to rely on an
unauthenticated IP address as a basis for determining the source of a
packet. Similarly. the IP header checksum offers no security. We
have a variety of IETF standard protocols (e.g., IPsec and TLS) that
provide suitable
Leslie,
I understand your point, but we leave ourselves open to many forms of
attacks, or errors, by assuming that "what you receive is what was
sent" in this era of the Internet. Security is not black and white,
but the gray area we're discussing does bother me. If one cares
about knowing
On Fri, 07 Apr 2000 13:07:29 EDT, Stephen Kent said:
but the gray area we're discussing does bother me. If one cares
about knowing where the data originated, and that it has not been
altered, then one needs to make use of the tools provided to address
that concern. if one doesn't use the
A fine argument in the abstract, but reality bites.
Stephen Kent wrote:
sent" in this era of the Internet. Security is not black and white,
but the gray area we're discussing does bother me. If one cares
about knowing where the data originated, and that it has not been
altered, then one
Keith Moore wrote:
. . .
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.
You will need
From: [EMAIL PROTECTED]
...
they ARE concerned about spam, hackers, etc. Unfortunately, a lot of them
Get It Very Wrong, and do stuff like bounce SMTP 'MAIL FROM:', or Do The
Wrong Thing with NTP traffic, etc etc.
I have to conclude that there's a lot of sites that *do* care very much,
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)
On Fri, 07 Apr 2000 12:16:05 MDT, Vernon Schryver [EMAIL PROTECTED] said:
It's worse than that, as AOL is demonstrating with their port 25 redirecting.
Hmm.. I don't correspond with that many AOL people. What are they doing NOW?
If your skin doesn't crawl at the thought of a third party
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
Applications can gain a lot of security by building on top of a lower
layer secure communication substrate, such as that provided by IPsec
or TLS. Such substrates allow the application developer to make
assumptions about the security of the basic communication path, and
have these
Stephen,
perhaps the reason that the tools are not used is that they are not
adequate for the task. but it certainly does not follow that "if
one doesn't use the tools, then one does not care very much".
Keith
If one cares
about knowing where the data originated, and that it has not been
On Fri, 07 Apr 2000 11:25:40 PDT, Dennis Glatting said:
Huh? You have a choice: (a) obtain a client that does support
security; and (b) get a new ISP. Both are plentiful.
Only if a client supporting security is available for your software
(which might be be something other than Netscape/IE -
Dennis Glatting wrote:
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
Keith,
Stephen,
perhaps the reason that the tools are not used is that they are not
adequate for the task. but it certainly does not follow that "if
one doesn't use the tools, then one does not care very much".
or perhaps, one does not care enough ...
Steve
In my 20+ years of security experience in the Internet community, it
has often been the arguments for the need to make do with existing
features or to adopt quick fix solutions that have retarded the
deployment of better security technology. In retrospect, this
approach has not
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
Getting a new ISP, however, is NOT necessarily an option. You'd argue I
give up a cable modem for a dialup ISP? I don't think so. Application
level security (SSL, TLS, SSH) work fine for my needs and transit the
equipment I must use to exist on a cable modem.
You have made the choice to
Keith Moore wrote:
. . .
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.
You will
From: [EMAIL PROTECTED]
...
If your skin doesn't crawl at the thought of a third party adding headers
to your SMTP messages, you need to take some time out to think about things.
You mean *other* than the required RFC822 Received: headers, and/or the
RFC2476-approved re-writing? Gaak
perhaps the reason that the tools are not used is that they are not
adequate for the task. but it certainly does not follow that "if
one doesn't use the tools, then one does not care very much".
or perhaps, one does not care enough ...
or perhaps, that building tools that actually solve
Paul,
I have a time machine.
I just went back 20 years in time, convinced everybody that it
was always more important to implement proper security than to
make do with existing features and quick fix solutions. Having
thus changed the future, I went back forward in time.
Guess what---there
Christian,
Suppose, rhetorically, that we were to encrypt every IP packet using IPSEC.
What happens if a box takes your packet and deliver it to the "wrong"
address, for example to an ISP controlled cache? Well, the cache cannot do
anything with it, except drop it to the floor. We are thus
Date: Fri, 07 Apr 2000 15:00:22 -0400
From: Daniel Senie [EMAIL PROTECTED]
Ah, no. In the real world of the Internet today, we have LOTS of folks
who get their Internet connectivity via cable modems and DSL. Many
vendors of such services, in order to help preserve IP address
Steve,
Suppose, rhetorically, that we were to encrypt every IP packet using IPSEC.
What happens if a box takes your packet and deliver it to the "wrong"
address, for example to an ISP controlled cache? Well, the cache cannot do
anything with it, except drop it to the floor. We are thus faced
From: Keith Moore [EMAIL PROTECTED]
Date: Fri, 07 Apr 2000 15:15:57 -0400
the problem is that one person's idea of improved service may be
another person's idea of degraded service. getting stale data
to me faster may not be much help. I would argue that it
is up to the
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
Keith Moore wrote:
. . .
You seem to be saying that because we have a higher service layered
on top of IP that we can disregard the IP service model. I disagree.
No, I'm saying you purported to be offended by IP address
redirection when what you really objected to was unauthorized
I have a hammer.
It's been driving nails just fine for twenty years. It's a first rate
hammer, for which I paid top dollar. It's a really useful tool. But when I
try to open beer bottles with it, I end up with glass splinters in my beer.
What gives?
As has been pointed out many times in
Keith Moore wrote:
. . .
You seem to be saying that because we have a higher service layered
on top of IP that we can disregard the IP service model. I disagree.
No, I'm saying you purported to be offended by IP address
redirection when what you really objected to was unauthorized
33 matches
Mail list logo
