< draft-farrell-perpass-attack-00.txt   draft-farrell-perpass-attack-01.txt >
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: BCP H. Tschofenig Intended status: BCP H. Tschofenig
Expires: May 24, 2014 November 20, 2013 Expires: June 4, 2014 December 1, 2013
Pervasive Monitoring is an Attack Pervasive Monitoring is an Attack
draft-farrell-perpass-attack-00.txt draft-farrell-perpass-attack-01.txt
Abstract Abstract
The IETF has consensus that pervasive monitoring is a technical The IETF has consensus that pervasive monitoring is a technical
attack that should be mitigated in the design of IETF protocols, attack that should be mitigated in the design of IETF protocols,
where possible. where possible.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2014. This Internet-Draft will expire on June 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. It's an Attack 1. It's an Attack
[[Note: This draft is written as if IETF consensus has been [[Note (to be removed before publication): This draft is written as
established for the text.]] if IETF consensus has been established for the text.]]
The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive
monitoring and participants had strong agreement that this was an monitoring. Such pervasive surveillance requires the monitoring
attack and one that should be mitigated where possible via the design party to take actions that are indistinguishable from an attack on
of protocols that make pervasive monitoring significantly more Internet communications. Participants at that meeting therefore
expensive or infeasible. Such pervasive surveillance requires the expressed strong agreement that this was an attack that should be
monitoring party to take actions that are indistinguishable from an mitigated where possible via the design of protocols that make
attack on Internet communications. This Best Current Practice (BCP) pervasive monitoring significantly more expensive or infeasible.
documents that consensus. This Best Current Practice (BCP) formally documents that consensus,
having been through an IETF last call.
For the purposes of this BCP "pervasive monitoring" means very For the purposes of this BCP "pervasive monitoring" means very
widespread privacy-invasive gathering of protocol artefacts including widespread privacy-invasive gathering of protocol artefacts including
application content, protocol meta-data (such as headers) or keys application content, protocol meta-data (such as headers) or keys
used to secure protocols. Other forms of traffic analysis, for used to secure protocols. Other forms of traffic analysis, for
example, timing or measuring packet sizes can also be used for example, timing or measuring packet sizes can also be used for
pervasive monitoring. A fuller problem statement with more examples pervasive monitoring.
and description can be found in [ProblemStatement].
Note that the term "attack" is used here in a techincal sense that The term "attack" is used here in a technical sense that differs
differs somewhat from the natural English usage. In particular, the somewhat from common English usage. In common English usage, an
term, when used technically, implies nothing about the motivation of "attack" is an aggressive action perpetrated by an opponent, intended
the bad-actor mounting the attack, who is still called a bad-actor no to enforce the opponent's will on the attacked party. In the
matter what one really thinks about their motivation. We also use Internet, the term is used to refer to a behavior that subverts the
the term in the singluar here, even though pervasive monitoring in intent of a communicator without the agreement of the parties to the
reality may require a multi-faceted set of co-ordinated attacks. communication. It may change the content of the communication,
record the content of the communication, or through correlation with
other communication events or attempts, reveal information the
communicator did not intend to be revealed. It may also have other
effects that similarly subvert the intent of a communicator. RFC
4949 contains a more complete definition for the term "attack" as
used here. [RFC4949] Note that we also use the term in the singular
here, even though pervasive monitoring in reality may require a
multi-faceted set of coordinated attacks.
The motivation behind pervasive monitoring is not particularly In particular, the term "attack", when used technically, implies
relevant for this document, but can range from non-targeted nation- nothing about the motivation of the actor mounting the attack. The
state surveillance, to legal but privacy-unfriendly purposes by motivation behind pervasive monitoring is not relevant for this
commercial enterprises, to illegal purposes by criminals. The same document, but can range from non-targeted nation-state surveillance,
techniques can be used in each case, regardless of motivation, and we to legal but privacy-unfriendly purposes by commercial enterprises,
cannot defend against the most nefarious actors while allowing to illegal purposes by criminals. The same techniques can be used
monitoring by other actors no matter how benevolent some might regardless of motivation and we cannot defend against the most
consider those. As technology continues to advance rapidly nefarious actors while allowing monitoring by other actors no matter
techniques that have been shown to work but were once only accessible how benevolent some might consider them to be. As technology has
to nation-state actors become accessible to non-nation-state actors, advanced techniques that were once only available in constrained
so mitigating this threat is not only relevant when considering environments have become more widely accessible. Mitigating this
nation-state bad actors. attack is therefore a protection against wider usage of pervasive
monitoring.
2. And we'll work to Mitigate the Attack 2. And we'll work to Mitigate the Attack
The IETF also have consensus to, where possible, work to mitigate the The IETF also has consensus to, where possible, work to mitigate the
technical parts of the pervasive monitoring attack, in just the same technical parts of the pervasive monitoring attack, in just the same
way as we do with any other protocol vulnerability. way as we do with any other protocol vulnerability.
There are various ways in which IETF protocols can be designed in There are various ways in which IETF protocols can be designed in
order to mitigate pervasive monitoring, but those will change over order to mitigate pervasive monitoring, but those will change over
time as mitigation and attack techniques develop and so are not time as mitigation and attack techniques develop and so are not
described here. This BCP simply records the consensus to design described here. This BCP simply records the consensus to design
protocols so as to mitigate the attack, where possible. protocols so as to mitigate the attack, where possible.
Note that more limited-scope monitoring to assist with network Note that more limited-scope monitoring to assist with network
management or that is required in order to operate the network or an management or that is required in order to operate the network or an
application are not considered pervasive monitoring. There is though application are not considered pervasive monitoring. There is though
a clear potential for network management mechanisms to be abused as a clear potential for network management mechanisms to be abused as
part of pervasive monitoring, so this tension needs careful part of pervasive monitoring, so this tension needs careful
consideration in protocol design: making networks unmanageable in consideration in protocol design. Making networks unmanageable in
order to mitigate pervasive monitoring would not be an acceptable order to mitigate pervasive monitoring would not be an acceptable
outcome, but equally, ignoring pervasive monitoring in designing outcome. But equally, ignoring pervasive monitoring in designing
network management mechanisms would go against the consensus network management mechanisms would go against the consensus
documented in this BCP. An appropriate balance will likely emerge documented in this BCP. An appropriate balance will likely emerge
over time as real instances of this tension are considered. over time as real instances of this tension are considered.
It is also important to note that the term "mitigation" is also a It is also important to note that the term "mitigation" is a
technical term that does not necessarily imply an ability to technical term that does not necessarily imply an ability to
completely prevent or thwart an attack. In this case, designing IETF completely prevent or thwart an attack. As in common English usage,
protocols to mitigate pervasive monitoring will almost certainly not this term is used here in the sense of "make less severe, serious, or
completely prevent such from happening, but can increase the cost painful." [OED] In this case, designing IETF protocols to mitigate
significantly or force what was covert monitoring to be more overt, pervasive monitoring will almost certainly not completely prevent
or more likely to be detected (possibly later) via other means. And 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. And
even where the IETF has done this work well and that has been fully even where the IETF has done this work well and that has been fully
deployed, there will still be some privacy-relevant information that deployed, there will still be some privacy-relevant information that
will inevitably be disclosed by protocols. will inevitably be disclosed by protocols.
While RFC 4949 does not contain a definition for the term mitigation,
we prefer it here to the term countermeasure which is defined in RFC
4949 since the latter term is more often understood to mean putting
in place a more fully effective mitigation of an attack.
Finally, we note that the IETF is not equipped to tackle the non- Finally, we note that the IETF is not equipped to tackle the non-
technical aspects of mitigating pervasive surveillance. We hope that technical aspects of mitigating pervasive surveillance. Others will
others will step forward to tackle those. be required to step forward to tackle those if pervasive monitoring
is to be fully addressed.
3. Process Note 3. Process Note
In the past, architectural statements of this sort, e.g., [RFC1984] In the past, architectural statements of this sort, e.g., [RFC1984]
and [RFC2804] have been published as joint products of the IESG and and [RFC2804] have been published as joint products of the IESG and
IAB. However, since those documents were published, the IETF and IAB IAB. However, since those documents were published, the IETF and IAB
have separated their publication "streams" as described in [RFC4844] have separated their publication "streams" as described in [RFC4844]
and [RFC5741]. This document was initiated by both the IESG and IAB, and [RFC5741]. This document was initiated by both the IESG and IAB,
but it is being published as an IETF-stream consensus document, but it is published as an IETF-stream consensus document, having
having garnered the consensus of the IETF as approved by the IESG. garnered the consensus of the IETF as approved by the IESG.
4. Security Considerations 4. Security Considerations
This BCP is all about privacy. More information about the This BCP is all about privacy. More information about the
relationship between security and privacy threats can be found in relationship between security and privacy threats can be found in
[RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses
surveillance as a combined security-privacy threat. surveillance as a combined security-privacy threat.
5. IANA Considerations 5. IANA Considerations
There are none. We hope the RFC editor deletes this section before There are none. We hope the RFC editor deletes this section before
publication. publication.
6. Acknowledgements 6. Acknowledgements
We would like to thank the participants of the IETF 88 technical We would like to thank the participants of the IETF 88 technical
plenary for their feedback. Additionally, we would like to thank all plenary for their feedback. Thanks in particular to the following
those who contributed to their suggestions on how to improve Internet for useful suggestions that resulted in changes to this text: Jari
security on various IETF mailing lists, such as the ietf@ietf.org and Arkko, Fred Baker, Marc Blanchet, Brian Carpenter, Benoit Claise,
the perpass@ietf.org lists. Spencer Dawkins, Adrian Farrel, Russ Housley, Joel Jaeggli, Eliot
Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete Resnick, and Peter
Thanks in particular to the following for useful comments: Jari StAndre. Additionally, we would like to thank all those who
Arkko, Marc Blanchet, Benoit Claise, Spencer Dawkins, Russ Housley, contributed suggestions on how to improve Internet security and
Joel Jaeggli, Eliot Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete privacy or who commented on this on various IETF mailing lists, such
Resnick, as the ietf@ietf.org and the perpass@ietf.org lists.
7. Informative References 7. Informative References
[IETF88Plenary] [IETF88Plenary]
IETF, "IETF 88 Plenary Meeting Materials", URL: IETF, "IETF 88 Plenary Meeting Materials", URL:
https://datatracker.ietf.org/meeting/88/materials.html, https://datatracker.ietf.org/meeting/88/materials.html,
Nov 2013. Nov 2013.
[ProblemStatement] [OED] Stevenson, Angus, "Oxford Dictionary of English", Oxford
Richard Barnes, "Pervasive Monitoring: Problem Statement", University Press http://www.oxforddictionaries.com/
URL: To-Be-Published, Nov 2013. definition/english/mitigate, 2010.
[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
Statement on Cryptographic Technology and the Internet", Statement on Cryptographic Technology and the Internet",
RFC 1984, August 1996. RFC 1984, August 1996.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
May 2000. May 2000.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007. Series and RFC Editor", RFC 4844, July 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,
and Boilerplates", RFC 5741, December 2009. and Boilerplates", RFC 5741, December 2009.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
July 2013. July 2013.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
58 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/