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

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?

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 document is not an IETF standard but it does describe a protocol. For
> protocols to work correctly, there must be certain "mandatory" minimal
> requirements on those implementing that protocol.

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.

> I can see one or two places where the word "standard" might be
> misinterpreted by readers if used out of context.

You somehow missed Section 1:

...  NECP provides a standard method for this signaling.

> >2. A primary purpose of the NECP protocol appears to be to
> >facilitate the operation of so-called interception proxies.
> Wrong. The primary purpose of NECP is to facilitate a load-balancing
> between SLBs and the services to which they direct traffic. "so-called
> interception proxies" are just one such service.

The document says:

   NECP now provides a
   standard server-to-network signalling interface.  This allows
   network elements in heterogenous environments to perform load
   balancing across a server farm, redirection to interception
   proxies, and cut-through of flows that can not be served by the

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.

> >Such  proxies violate the Internet Protocol in several ways:
> This is not about those proxies - that is a different argument.
> I  don't think it is appropriate to be drawn into an argument about the
> rights and wrongs of "interception proxies" when discussing NECP. I am
> than happy to justify their existence - with hard facts, of course - in a
> separate thread.

In whatever thread, the document fails to mention the legitimate security
concerns of those people who are concerned about interception.  I would
argue that our other flame war on wire tapping is (unfortunately) relevant.

Eliot Lear
Cisco Systems

Reply via email to