Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02

From: Eric Burger <[email-masked]>
Date: Mon, 09 Dec 2013 07:43:48 -0500

So if the "operational realities" of the operator include a mandate to intercept, like with a law like CALEA in the United States, then pervasive monitoring is OK?

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger

-------- Original message --------
From: Eliot Lear <[email-masked]> 
Date:12/09/2013  7:29 AM  (GMT-05:00) 
To: "ietf-interest(mailer list)" <[email-masked]>,perpass <[email-masked]> 
Cc: Internet Architecture Board <[email-masked]>,'IESG' <[email-masked]> 
Subject: [perpass] comments and questions for the group on
 	draft-farrell-perpass-attack-02 

These comments follow a thread from the IAB/IESG mailing list.

There has been some confusion over how this proposed BCP should be taken
by working groups.  At least one working group chair has inferred, if
not suggested, that a document before the IESG that does not demonstrate
it has mitigated pervasive surveillance will get returned.  That
wouldn't be appropriate, in my opinion.  A working group must consider
the operational realities that it is attempting to code to.  There are
many tensions to consider, not just a narrow view of network management
(a phrase that might itself be left to ambiguous interpretation).  I
have in mind as an example a service provider that does
transparent/intercepting HTTP caching for purposes of bandwidth
preservation in bandwidth-constrained environments.  Another example
would be an environment in which security and governance are key.

As such, I propose the following two changes to clarify the text in
Section 2:

2nd para:

OLD:
>    This BCP simply records the consensus to design
>    protocols so as to mitigate the attack, where possible.

NEW:

>    This BCP simply records the consensus to design
>    protocols so as to mitigate the attack, taking into account
> operational realities of network operators.

Next para:

OLD:
>    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.  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.  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.

NEW:

>    More limited-scope monitoring or other services or to assist with
> network operations that
>    is required in order to operate the network or an application is not
>    considered pervasive monitoring,
>    There is though a clear potential
>    for such 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.  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.

And so someone operating a small ISP with a cache in Madagascar or the
SP trying to manage bandwidth on a train can also have their
considerations taken into account.  It's for a working group to decide
how far to accommodate them, of course.

Eliot

_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 14:59:18 +0100

On 12/9/13 1:43 PM, Eric Burger wrote:
> So if the "operational realities" of the operator include a mandate to
> intercept, like with a law like CALEA in the United States, then
> pervasive monitoring is OK?
>

This does not negate the existing RFCs that speak to that.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2013 11:08:36 +1300

> This does not negate the existing RFCs that speak to that.

My understanding of the debate in Vancouver was that we intend
to go one step beyond the RAVEN consensus (RFC 2804). Then, we
agreed not to consider wiretapping requirements as part of the
standards development process. This time, we agreed to treat
pervasive surveillance as an attack, and therefore to try to
make protocols resistant to it.

Which is completely disjoint from whether operators deploy
anti-surveillance measures; that is a matter of national law
and not our department.

   Brian