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 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
advertisement?
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
stuff.
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
farm.
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
more
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