I have been following this discussion and have little to say till now . I think it is an important BCP that should be published as soon as possible.
I was concerned when the issue of operational needs for monitoring was first brought up, as that often serves as an entry point for surveillance. I think it is as important to consider how we do operational functions to be attack resistant as it any other network service or function.
The draft does not say functionality must be abandoned. It just says we need to work on preventing pervasive surveillance attacks. This should be the case in network management and operations as it is anywhere else.
We should be careful about making unnecessary exceptions and accept that the tussle of protection and function is ongoing and can only be solved over time as the protocol work proceeds.
Avri Doria
l.wood@xxxxxxxxxxxx wrote:
SB> My view is that we need to get a much better handle on what
SB> that balance is before we publish this BCP. To do otherwise
SB> is going to stall IETF work and result in an inconsistency
SB> as IDs make the "case law".
+1
Lloyd Wood
http://sat-net.com/L.Wood/
From: ietf [ietf-bounces@xxxxxxxx] On Behalf Of Stewart Bryant [stbryant@xxxxxxxxx]
Sent: 11 December 2013 12:27
To: draft-farrell-perpass-attack@xxxxxxxxxxxxxx; ietf@xxxxxxxx
Cc: iesg@xxxxxxxx
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice
Pervasive Monitoring is an Attack
draft-farrell-perpass-attack-02.txt
This BCP simply records the consensus to design
protocols so as to mitigate the attack, where possible.
SB> "where po! ssible" has huge implications, since it does not
SB> define where on the scale unnoticeable cheap to leading
SB> in technology and cost the boundary lies.
SB> I hope that you mean "where economically feasible
SB> within the context of the application"
More limited-scope monitoring to assist with network management that
is required in order to operate the network or an application is not
considered pervasive monitoring.
SB> This discussion on the tension between monitoring for good and bad
SB> reasons focuses on network management in the technical sense.
SB> However there are many legitimate reasons for traffic analysis
SB> and traffic content monitoring that go beyond the basics of
SB> network management.
SB>
SB> Our technologies are used in many environments and we need
SB> to ensure that they are fit for off of those environments.
SB> For example ther! e are many reasons why a business may need
SB> or even be required to monitor, filter and record the content and
SB> the metadata of the traffic they flows through its networks.
SB>
SB> There is also the issue of the tension between privacy and
SB> the big data models that are the economic fuel that enables
SB> many cloud and Internet services to be affordable to many
SB> Internet users.
SB>
SB> I thus think that we need to be very careful with setting
SB> the scope of permitted monitoring enabled by protocols
SB> in such a restricted way.
SB> I think that we need to say something of the form:
SB>
SB> Note that limited-scope monitoring required in order to assist
SB> with network management or that is required in order to operate the
SB> network or an application are not considered pervasive monitoring.
SB> Equally monitoring that the user c! onsents to in order that the
SB> operator may operate the network or provide a service economically
SB> or monitoring in compliance with local regulations should not be
SB> considered an attack.
SB>
There is though a clear potential
for such limited monitoring mechanisms to be abused as part of
pervasive monitoring, so this tension needs careful consideration in
protocol design. Making networks unmanageable in order to mitigate
pervasive monitoring would not be an acceptable outcome.
SB> Again I am concerned that network management (unless you have
SB> a far broader view of what NM is than I) is simply too narrow
SB> a scope for permitting monitoring.
But
equally, ignoring pervasive monitoring in designing network
management mechanisms would go against the consensus documented in
this BCP. An appropriate balance will likely emerge over time as
real instances ! of this tension are considered.
SB> My view is that we need to get a much better handle on what
SB> that balance is before we publish this BCP. To do otherwise
SB> is going to stall IETF work and result in an inconsistency
SB> as IDs make the "case law".
SB>
SB> Some text of the following form would also be of use in the draft:
SB>
SB> An protocol defined or modified to mitigate monitoring
SB> MUST take into account the deployment needs and economic
SB> realities of the broad spectrum of operators, who will
SB> deploy the protocol both now and into the foreseeable future.
It is also important to note that the term "mitigation" is a
technical term that does not necessarily imply an ability to
completely prevent or thwart an attack. As in common English usage,
this term is used here in the sense of "make less severe, serious, or
painful." [OED] In this c! ase, designing IETF protocols to mitigate
pervasive monitoring will almost certainly not completely prevent
such from happening, but can significantly increase the cost of such
monitoring or force what was covert monitoring to be more overt or
more likely to be detected (possibly later) via other means.
SB> I think that the above is stated backwards. Surely we should state up
SB> front that the goal, as with most security, is to increase the
SB> cost of monitoring to a find a more acceptable point on the
SB> cost-return curve in the light of current technology and ideally
SB> to be able to maintain this as technical capabilities change over time.
- Stewart