Stephen,
Thanks for creating a new thread to discuss this topic. It's a good
starting point for
an important discussion.
I think MTU (vs. MTI) is a very hard argument to make, for several reasons,
some of which I noted in my response to Dean.
Internet protocols are used in a very, very wide range of contexts,
e.g., enterprises of various sorts, the IoT, and public environments. In
principle one ought to make decisions about what security measures to
deploy and enable based on a perception of threat. Threats differ in
different contexts. Our current, MTI-based approach to security enables
responsible parties in each environment to make decisions about what
security to offer based on perceived threats and tradeoffs, e.g.,
performance, processing overhead, user experience, etc.
I admit that, in my experience, very few parties appear to make such
decisions in a well thought-out fashion, but they could. Suggesting that
we can make such decisions for the folks who are ultimately responsible
for the operation of services in a wide range of contexts strikes me
hubristic.
We've already made concessions for the Smart Grid context in the case of
IPsec as MTI for IPv6. To me this suggests that we were persuaded that
even MTI can be a barrier to adoption and deployment in some contexts.
Pursuing a single set of MTUstandards for a wide range of contexts seems
doomed to failure. Generating MTU RFCs for various contexts might be an
alternative. That would imply MTI protocol standards, augmented with
BCPs. Is that what you envision?
Evaluating tradeoffs of security and privacy vs. other factors is hard
when one deals with a wide range of contexts. For example, end user
devices range from big servers to laptops, to tablets, to smart phones.
Battery use if a big issue for some of these devices, as is bandwidth.
Some of the more extreme TFS mechanisms discussed would have adverse
implications for both. That's an example of why MTU, at the protocol
spec levelk,
strikes me as a bad idea.
There are a lot of middleboxes in the Internet. I am no fan of them; I'm
a true believer in the e-t-e model for everything, not just security.
But middleboxes are a fact of life and they exist because the folks who
purchase equipment and offer services have found them to be operational
necessities. Middleboxes provide ways to deal with backward
compatibility and migration issues, broken implementations from vendors,
security services for enterprises, network traffic engineering, etc. If
we argue that security against widespread nation-state surveillance is
more important than all of these other considerations, I think we risk
having the IETF be described as out of touch with reality.
Steve
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
