RE: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 possible" 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 there 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 consents 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 case, 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]