Re-,
Please see inline.
Cheers,
Med
-----Message d'origine-----
De : ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] De la part de Nico
Williams
Envoyé : mardi 11 avril 2017 19:50
À : Melinda Shore
Cc : ietf(_at_)ietf(_dot_)org
Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
mm-wg-effect-encrypt-09)
On Tue, Apr 11, 2017 at 09:31:41AM -0800, Melinda Shore wrote:
On 4/11/17 9:18 AM, Nico Williams wrote:
One could give a lot of advice for design of protocols with
"friendly" middle boxes. Merely saying "hey, they are good" is not
enough. We might want to revisit end-to-end protocol design as well
(e.g., maybe ICMP isn't working so well; what can we do?).
There have been a number of efforts to provide mechanisms for
applications to communicate explicitly with middleboxes. None
has gotten any traction, and for the moment it looks like
anything that requires changes to middleboxes along those
lines is unlikely to be successful. That said:
Sure, but if we wanted to have an Informational RFC describing all the
goodness and badness and history of middle-box-aware protocools, that
might not be bad, and we could detail all those protocols that failed to
get traction and why. I think such a document would end up favoring
end-to-end protocols, even if it didn't start out with that as a goal :)
[Med] This may be applicable for some cases under some conditions ... but I'm
afraid this may not be applicable to all of them. This is why it is important
to understand the intended usage (draft-dolson) before going further in the
discussion (e.g., whether it makes sense to call for a generic recommendation,
standardize a given network-located function a la BEHAVE, etc.).
For example, an operator will need to detect and mitigate DDoS attacks without
interfering with legitimate traffic issued/send to customers. "Something" is to
be done at the network side to that aim. We are investigating how endpoints can
help to achieve that goal.