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 JavaScript/Java/Shockwave/... applet in an
>And who would know it was me?

Do you mean the authors of NECP? If so, then I'm confused because NECP is 
not about "modifying data in flight" - it is about load balancing multiple 
services which sit behind e.g. a single IP address. (i.e. DNS server farms, 
firewalls, proxies). As I have said repeatedly, "interception proxies" is 
only one of these applications and by no means the most widely used.

Are you confusing this with WCCP (which *only* works with "interception 

>Quoth John Martin:
> > [...]
> > Let me be absolutely clear, NECP is about communication between server
> > load-balancers (SLB) and the back-end servers they speak to.
>Were this so clear in your document my mailbox wouldn't be full of this

The very first sentance says:

    "This document describes "NECP", a lightweight protocol for
    signalling between servers and the network elements that forward
    traffic to them.  It is intended for use in a wide variety of
    server applications, including for origin servers, proxies, and
    interception proxies."

Despite the fact that "interception proxies" are listed last, they are the 
only service people are talking about.

But, you are right in general: if this is how people read the document, 
we  need to fix the document.

>If it looks like a duck and quacks like a duck, but it's not supposed to be
>a duck, the IESG ought to point out that it's a turkey by so indicating at
>the top of the document.  Also, I'd like to understand why you're not going
>experimental, where it would be expected that you'll correct your mistakes.
>Your choice of "informational" seems unfortunate at best and as
>disingenuous marketing at worst.  I can't tell which.

We used "informational" because we saw that this is what was used for 
HTTP/0.9 with which there are parallels: NECP has existed for some time 
already in slightly differing implementations and this is a codification of 
existing practice. There was no magic of deceit intended. If the IESG 
thinks we should instead go for experimental, I'd be more than happy to 
pursue that instead and bring this into WREC. However, development is not 
within the current WREC charter so we are stuck, I think?

>The fact that you mention interception proxies in the introduction has led
>to this flame war.  Having used the words, you've mentioned none of the
>risks associated with such services both from the server side and the
>client side.

OK - we can fix that. It is not the goal of NECP to describe "interception 
proxies" or their deficiencies. There is, however, a working group which 
has a document aimed at exactly that (amongst other things) - WREC.


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

Reply via email to