At 12:44 AM 4/11/00 -0700, Derrell D. Piper wrote:
And there you have the argument for publishing this document. I much prefer a
model where we allow for free exchange of ideas, even bad ones.
hear! hear!
I tend to
believe that if someone took the time to write up a document that there's
I think various people have made a good case for eventually publishing
this particular document, once appropriate revisions have been made.
I'm very supportive of the notion of free exchange of ideas, even
through the RFC mechanism - with the understanding that:
- IETF and the RFC Editor have
Title: RE: recommendation against publication of draft-cerpa-necp-02.txt
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
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote:
I wonder if any of the authors has explored the risks of modifying data in
flight. How could this be abused by interlopers and evil doers? If I
could hack into a router implementing NECP, what damage could I do? Could
I start a nasty little
Part of the problem here is that a knife may be used as a food utensil or a
weapon. Safe handling, however, is always required, and should be
documented.
I would add two other comments. I tried to locate the RFC for HTTP/0.9,
but the best I could find was a reference to a CERN ftp site for the
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote:
Part of the problem here is that a knife may be used as a food utensil or a
weapon. Safe handling, however, is always required, and should be
documented.
Granted.
I would add two other comments. I tried to locate the RFC for HTTP/0.9,
but the best
Let's remember that a major goal of these facilities is to get a user to a
server that is 'close' to the user. Having interception done only at
distant, localized server farm facilities will not achieve that goal.
granted, but...
an interception proxy that gets the user to a server that
On Mon, 10 Apr 2000 07:00:56 EDT, Keith Moore said:
and a technology that only works correctly on the server end seems
like a matter for the server's network rather than the public
Internet - and therefore not something which should be standardized by IETF.
Much the same logic can be applied
and a technology that only works correctly on the server end seems
like a matter for the server's network rather than the public
Internet - and therefore not something which should be standardized by IETF.
Much the same logic can be applied to NAT (the way it's usually implemented).
In your previous mail you wrote:
But IP-layer interception has some fairly significant limitations
for this application. ...
There's a technical problem with IP intercepting that I've not seen
mentioned, including in the draft. Any intercepting based on TCP or UDP
port
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
And there you have the argument for publishing
Let's remember that a major goal of these facilities is to get a
user to a server that is 'close' to the user. Having interception
done only at distant, localized server farm facilities will not
achieve that goal.
...
client -- Internet - ISP - Intercept - Internet - Server1
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
That sounds overly optimistic.
user
From: Jon Crowcroft [EMAIL PROTECTED]
...
its the 21st century:
f you dont use end2end crypto, then you gotta expect people to optimize
their resources to give you the best service money can buy for the least
they have to spend.
...
That's an interesting idea. People might eventually
From: Vernon Schryver [EMAIL PROTECTED]
Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt
Date: Mon, 10 Apr 2000 10:41:43 -0600 (MDT)
From: Jon Crowcroft [EMAIL PROTECTED]
...
its the 21st century:
f you dont use end2end crypto, then you gotta expect people
At 11.50 -0400 2000-04-10, Dick St.Peters wrote:
What is the fundamental difference between choosing the best path and
choosing the best source? Arguments that the latter breaks the IP
model are simply arguments that the IP model is broken for today's
Internet and will be even more broken for
Yo Randy!
On Mon, 10 Apr 2000, Randy Bush wrote:
all these oh so brilliant folk on the anti-cacheing crusade should be
sentenced to live in a significantly less privileged country for a year,
where dialup ppp costs per megabyte of international traffic and an
engineer's salary is $100-200
One other item:
Neither this, nor many NAT I-D's, address the particular
issue of sourcing IP addresses not assigned or owned by
the host/gateway, e.g., as they affect the standards
of RFCs 1122, 1123, and 1812.
If a device creates (rewrites) IP source
Bottom line is that IP-layer interception - even when done "right" -
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be
useful to define what "right" means.
And there you have the argument for
From: Randy Bush [EMAIL PROTECTED]
...
That's an interesting idea. People might eventually finally start
using end2end crpyto not for privacy or authnetication where they
really care about either, but for performance and correctness, to
defend against the ISP's who find it cheaper to
its the 21st century:
f you dont use end2end crypto, then you gotta expect people to optimize
their resources to give you the best service money can buy for the least
they have to spend.
...
That's an interesting idea. People might eventually finally start
using end2end crpyto
all these oh so brilliant folk on the anti-cacheing crusade should be
sentenced to live in a significantly less privileged country for a year,
where dialup ppp costs per megabyte of international traffic and an
engineer's salary is $100-200 per month.
and as long as we're talking about just
I tried to send this earlier, but got a response from
[EMAIL PROTECTED] complaining that every line is a bogus majordomo
command. My logs say I sent to [EMAIL PROTECTED] and not [EMAIL PROTECTED]
or anything smilar. I did use the word "s-u-b-s-c-r-i-b-e-r-s" 3 times.
This time I've replaced all
At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote:
However, I am
fully in agreement that interception proxies imposed anyplace other
than either endpoint of the connection is a Bad Idea, because a third
Exactly. And after having read this specification, I also think these issues
are
At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote:
However, I am
fully in agreement that interception proxies imposed anyplace other
than either endpoint of the connection is a Bad Idea, because a third
Exactly. And after having read this specification, I also think these issues
At 03:42 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote:
You are confusing topological locality with administrative locality. I was
talking about the latter, and so, I believe, was Valdis.
As my later comment meant to convey, I too was clear about the distinction,
but yes I was definitely confused
At 14.35 -0700 2000-04-09, Dave Crocker wrote:
Let's remember that a major goal of these facilities is to get a
user to a server that is 'close' to the user. Having interception
done only at distant, localized server farm facilities will not
achieve that goal.
Further, I'm unclear about the
At 15.20 -0400 2000-04-07, Bill Sommerfeld wrote:
I think it's important to carefully distinguish between these sorts of
redirection. Some clarifying text in the draft to this effect would
be helpful.
That is what I have asked the authors to do.
The problems with "intercepting proxies" are
Peter,
I think that by now I've made my points and defended them adequately and
that there is little more to be acheived by continuing a public,
and largely personal, point-by-point argument. If you want to continue
this in private mail I'll consider it.
The simple fact is that I believe
--- Keith Moore [EMAIL PROTECTED] wrote:
... stuff deleted
As we have done with the NAT WG, it is
often useful to accurately document the drawbacks of a
common practice as well as to encourage exploration of
alternatives.
From my point of view there were significant forces within the
g'day,
Keith Moore wrote:
Peter,
I think that by now I've made my points and defended them adequately and
that there is little more to be acheived by continuing a public,
and largely personal, point-by-point argument. If you want to continue
this in private mail I'll consider it.
Okay,
On Sat, 08 Apr 2000 15:28:12 EDT, Keith Moore said:
The simple fact is that I believe that the idea of interception proxies
does not have sufficient technical merit to be published by IETF, and
that IETF's publication of a document that tends to promote the use
of such devices would
Peter Deutsch in Mountain View wrote:
[in part you said]
I still object to your notion that it's not censorship since people can
always go elsewhere. Where does this lead? I see the day when people
can't publish a new directory service protocol because "The IETF has
endorsed LDAP for
Keith - I argued to keep the term "transparent routing" in the
NAT terminology RFC (RFC 2663). The arguments I put forth were
solely mine and not influenced by my employer or anyone else.
didn't say that they were.
Clearly, your point of view is skewed against NATs. It is rather
--- Keith Moore [EMAIL PROTECTED] wrote:
Keith - I argued to keep the term "transparent routing" in the
NAT terminology RFC (RFC 2663). The arguments I put forth were
solely mine and not influenced by my employer or anyone else.
didn't say that they were.
Clearly, your point of
Publication under Informational and Experimental has typically been
open to all wishing it.
uh, no. this is a common myth, but it's not true, and hasn't been
true for many years.
I hope (and believe) that the *potential* for publication is open
to all, and that the process isn't biased
--- Keith Moore [EMAIL PROTECTED] wrote:
Sorry.. Your conclusion is based on a wrong premise.
The NAT group's draft documents speak for themselves.
My point exactly.
regards,
suresh
__
Do You Yahoo!?
Talk to your friends online with
Keith Moore wrote:
The industry and their customers have already decided against you on
this one.
Industry people love to make such claims. They're just marketing BS.
The Internet isn't in final form yet and I don't expect it to stabilize
for at least another decade. There's still
the problem with a "NAT working group" is that it attracts NAT
developers far more than it does the people whose interests
are harmed by NATs - which is to say, Internet users in general.
so by its very nature a "focused" NAT working group will produce
misleading results.
This bias
g'day,
Lloyd Wood wrote:
Well, look at the list of signatories to the Draft in question.
technical merits, please.
I was not arguing for the merits of the technology in question based upon who
signed it. In fact, I haven't tried to address the technical merits of the
specific document at
Peter,
I don't think I would agree that NECP is out of scope for IETF.
I think it's pefectly valid for IETF to say things like "NECP
is intended to support interception proxies. Such proxies
violate the IP architecture in the following ways: ... and
therefore cause the following problems...
I've come into this discussion rather late, however there is at least one
salient point which I believe that
Keith Moore has argued rather well...
In my understanding the role of the IETF is to promote the logical growth
and evolution of the Internet Protocols.
Whilst 'vendors' have massive
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
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
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
re; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: recommendation against publication of
draft-cerpa-necp-02.txt
Leslie,
I understand your point, but we leave ourselves open to many forms of
attacks, or errors, by assuming that "what you receive is wha
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
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
-
From: Paul Francis [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 07, 2000 12:13 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: recommendation against publication of
draft-cerpa-necp-02.txt
In my 2
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 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:
2. A primary purpose of the NECP protocol appears to be to
facilitate the operation of so-called interception proxies. Such
proxies violate the
73 matches
Mail list logo
