Keith Moore wrote:
>
> 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:
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 l
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
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
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
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 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 Java
This whole thread is perhaps the best reason to have protocols go through
working groups, so that concerns can be raised and documented, and so that
the IESG can weigh in on correctness, risks, and yes, to a certain extent
morality.
I wonder if any of the authors has explored the risks of modifyi
On Mon, 10 Apr 2000 20:50:35 MDT, Vernon Schryver <[EMAIL PROTECTED]> said:
> if "commercial insertion" is a new idea. The local TV affliate or cable
> operator's computers replace a lot of dead air and other people's ads with
> their ownas I think about it, I realize I've got to be behind t
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
> 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 j
> > > 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 end2
> 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
> > 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
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 a
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-20
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
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 d
>> 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 mig
> 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 even
>>> 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.
> >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 -> Serve
> 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
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 nu
> From: Keith Moore <[EMAIL PROTECTED]>
> ...
> 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 numbers
> > 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 implemente
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 appli
I have held off commenting until I saw what the IETF community at large
would have to say. Disclosure: I work for Network Appliance, was involved
in the very early stages (though not latterly) of NECP and fully support
its publication as an Informational RFC. I am also co-chair of WREC.
As has
> 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
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
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 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 the
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
>a
> 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 wo
Why isn't the technical notion of stealth SMTP proxies intended and
currently used by third parties to "filter" objectionable email at least
as much anathema in the IETF as the technical notion of modifying voice/IP
protocols to someday facilitate "monitoring" of "criminal" voice traffic?
Am I we
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 techn
Date: Sat, 08 Apr 2000 02:30:25 -0400
From: Peter Deutsch in Mountain View <[EMAIL PROTECTED]>
Well there you go. You think the IETF's Seal of Approval and
promotion of technical sanity can prevent our unsound vendor
practices from perpetrating Marketing BS on poor users. You're ri
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... th
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 a
> > 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.
>
>
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 s
--- 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 wit
> Sorry.. Your conclusion is based on a wrong premise.
The NAT group's draft documents speak for themselves.
> 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
> Fair enough, but my primary goal was not to justify this particular technique,
> but to address the issue of whether we should be preventing the publication of
> particular techniques, and under what ground rules
As I see it, the issue is only one of where to have the debate - at
the RFC public
--- 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
At 03:28 PM 4/8/00 -0400, Keith Moore wrote:
>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
Publication under Informational and Experimental has typically been open to
all wishing it. It is deemed an e
> 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
> hyp
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 d
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 act
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.
O
--- 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
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 that
g'day,
Keith Moore wrote:
> . . . I did not call for a ban on publication of any document. I
suggested
> that the RFC Editor consider not devoting its energies to publishing
> the document - and I only suggested this after I suggested several
> things that could be done to "fix" the document.
At 10:31 AM 4/7/00 -0400, Keith Moore wrote:
> > 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
>NAT gr
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 t
> 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 unautho
nal Message-
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
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
spoofi
The objections I've seen so far to this draft specifically cite
problems from systems such as "transparent web proxies" (which are, in
my experience, usually far from transparent) in the network which
intercept all traffic, regardless of destination address, sent to
specific well-known ports.
A q
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 prod
Daigle
> Cc: Keith Moore; [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,
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 spac
Keith,
>
>or perhaps, that building tools that actually solve these problems
>as opposed to chipping away at the edges is (a) fundamentally difficult
>(b) requires many kinds of expertise, most of them scarce, (c) has
>been frustrated by governments and patent holders who were bent
>on trying to c
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
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---th
> >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
> 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?
> 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 s
> 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
>
> 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
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
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) obtai
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 -
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
> 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 a
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
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
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 served us well
> 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
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.
> >
> >
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 o
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
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
Keith,
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 ass
> 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
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
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 determi
> 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
> > 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
> > prox
nd
draft-cerpa-necp-02.txt to that WG if and when it is formed.
-Original Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 06, 2000 9:42 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: recommendation against publi
> 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 t
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 sta
93 matches
Mail list logo
