|
Hi,
This is a very important document and a clear step forward towards long-term deployable security, by documenting the effects of pervasive encryption on network operations and management.
As RFC 7258 writes:
"Making
networks unmanageable to mitigate PM is not an acceptable outcome,
but ignoring PM would go against the consensus documented here. An
appropriate balance will emerge over time as real instances of this
tension are considered.”
And document effects, positive or negative, on existing network operational and management practices is indeed starting to consider those real instances.
RFC 7258 further says:
"While PM is an attack, other forms of monitoring that might fit the
definition of PM can be beneficial and not part of any attack, e.g.,
network management functions monitor packets or flows and anti-spam
mechanisms need to see mail message content. […]"
Consequently, if beneficial mechanisms are adversely affected (degraded or flat-out broken) in presence of pervasive encryption, documenting is the first step.
For example, if a provider uses passive performance measurement metrics and methods techniques, developed by the IETF (e.g., IPPM), in order to perform SLA management and verification, and that is negatively affected, the first step is to document
those effects.
Interestingly, another draft explores a subset of this topic: https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-03
For example, Section 3 says:
"This section identifies ways that actors can benefit by observing
(non-encrypted) transport header fields at devices in the network.”
And analysis what would happen if access to granular transport header information is not available. The implications are the need to build new tools, new methods, use active vs. passive approaches, all of which require time and money (and potentially
new protocol).
This draft also includes the following text, which describes these effects:
"The common language between network operators and application/content
providers/users is packet transfer performance at a layer that all
can view and analyze. For most packets, this has been transport
layer, until the emergence of QUIC, with the obvious exception of
VPNs and IPsec. When encryption conceals more layers in a packet,
people seeking understanding of the network operation need to rely
more on pattern inferences and other heuristics.”
Consequently, the real (second order) effect is lack of common vocabulary and language between app providers and network operators.
It seems some use-cases listed in this draft can be added to draft-mm-wg-effect-encrypt as well (although I believe all broad categories are covered).
There is one additional approach not considered in draft-mm-wg-effect-encrypt: leverage RFC 5706 more. For example, https://tools.ietf.org/html/rfc5706#section-2.5
"The introduction of a new protocol or extensions to an existing
protocol may have an impact on the operation of existing networks.
Protocol designers should outline such impacts (which may be
positive), including scaling concerns and interactions with other
protocols."
Perhaps one start is a tighter look at Manageability Considerations.
A few additional comments on the draft itself.
Abstract:
"This document discusses current
security and network management practices that may be impacted by the
shift to increased use of encryption to help guide protocol
development in support of manageable, secure networks."
The Abstract and various other paragraphs talk about “management practices”. However, that ought to be broadened to “operations and management practices” throughout, both of which make up manageability.
I believe this is the right text (from the Introduction), which should be mirrored in the Abstract and elsewhere — “manage, operate, and secure":
"This document discusses practices currently used by network operators
to manage, operate, and secure their networks and how those practices
may be impacted by a shift to increased use of encryption."
What it doesn’t describe is “service function chaining” (i.e., the ordered steering and application of those optimizations). If the network visibility goes from a 5-tuple to a 2-tuple, or if everything above the transport becomes unaccessible,
then a Classifier (RFC 7665) in a service function chain will not be able to perform its job, and the service function path will be adversely affected.
At the same time it is important that there are mechanisms provided to protect security and privacy — in this example, the layer underneath a network service header can be protected with session encryption. A goal is protecting end-user data —
but at the same time not making the network inoperable or unmanageable.
As a closing note, a real power and differentiation of the IETF is cross-area synergies. This topic should become a bridge and not a division.
Thanks,
—
Carlos Pignataro, carlos@xxxxxxxxx “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."
|