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

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

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

---

From: Robin Wilton <[email-masked]>
Date: Mon, 9 Dec 2013 14:00:49 +0100

Eliot, 

I think your second edit is probably too broad, in the sense that it could create quite a lot of room for abuse. You currently have:

>>   considered pervasive monitoring

I would suggest something along the following lines. The first part is just a rewording of your text; the part in square brackets is prompted by what I think we can learn from existing approaches to pervasive monitoring.

Where monitoring is of limited scope, or services in support of network operations are required in order to operate the network, these are not necessarily to be considered de facto pervasive monitoring [; however, thought should be given to whether they enable pervasive monitoring, either directly or as a by-product of their primary purpose].

I hope this is helpful,

Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 9 Dec 2013, at 13:29, Eliot Lear <[email-masked]> wrote:

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 13:23:36 +0000

Hi Eliot,

I've trimmed the cc list to perpass. (I'll send a link to your
mail to [email-masked] which is arguably where this discussion
should happen since the draft is in IETF LC. But I guess most
of the folks who care are on here too so its not a huge deal.)

On 12/09/2013 12:29 PM, Eliot Lear wrote:
> it has mitigated pervasive surveillance will get returned.  

Can we establish the reality here? The chair you mean is Mark
Nottingham in this [1] mail to the httpbis list.

   [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html

I definitely did not read him the way you appear to have and
that distinction matters. If you are the only one to take him
as saying that then I guess you'd agree that your changes
would be based on a fallacy. Maybe Mark can clarify but I think
its already crystal clear that he was not saying "ignore
everything else" - I'd be stunned if that was what he meant.
And I'm sure even if it were, the httpbis WG participants
would either ignore that or beat him up for it (which they've
not done).

That said, it is clear that individual WGs and other IETF
activities will have to figure out what it means to properly
consider pervasive monitoring as an attack, but the draft says
that already I think. What I read Mark as saying was that if
the httpbis WG ignored or didn't properly consider pervasive
monitoring and if this BCP gets approved then that could
impact on their schedule. There's nothing surprising there at
all IMO.

> That
> (a phrase that might itself be left to ambiguous interpretation).  

"Operational realities" is far more vague IMO. Perhaps even dangerously
so since it could be used to attempt to justify pretty much anything.
And as Eric Burger already noted, what you propose would also seem to
fly in the face of RFC 2804, which is entirely antithetical to the
intent of this draft.

I think the current wording is much better than your proposed changes.

> I
> preservation in bandwidth-constrained environments.  

The httpbis WG are discussing how to handle proxies. That's a
complex and involved thread and I don't think any of us will
benefit from re-running the discussion here. Folks who care
about that should subscribe to that list and discuss it there.

> Another example

I've no idea what that means. If you mean something that's
broader than http, then what? If you just mean for http then
again that's better dealt with in httpbis.

>>    real instances of this tension are considered.

To be clear, I'd prefer we make neither change.

> how far to accommodate them, of course.

And that's already clearly the case. This proposed BCP doesn't
do away with either working groups or common sense.

S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 15:00:54 +0100

Robin,

> Where monitoring is of limited scope, or services in support of network operations are required in order to operate the network, these are not necessarily to be considered de facto pervasive monito…

Your alternative would be fine with me.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 15:53:22 +0100

Hi Stephen,

I'm not comfortable with having this discussion just in perpass, since
the impact of what you are proposing is quite broad, as is my concern. 
This is an IETF last call comment.  The IESG directed those comments to
go to the IETF list.

On 12/9/13 2:23 PM, Stephen Farrell wrote:

>  The chair you mean is Mark

The point was and is that I wanted to respond to him to clarify that one
should not ignore everything else, when in fact I found the opposite:
since you laid out explicitly only network management considerations,
the implication is that all other considerations are excluded.  The
purpose of my change is to remove that implied exclusion, and leave this
to working groups to wrestle with.  I'm happy with Robin's wording as
well, and I don't mind you proposing other wording further to your
liking, so long as we recognize that there are other considerations.

If you can show me where in your text it allows for those other
considerations as I believe I've done in the reverse, I'll be happy to
stand corrected.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Dec 2013 15:57:31 +0100

> This is an IETF last call comment.  The IESG directed those comments to

Just on this point, Stephen pointed out that I had originally CC'd the
wrong list.  Apologies to Stephen and others for any confusion about that.

Eliot

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 09 Dec 2013 12:40:00 -0800

> so since it could be used to attempt to justify pretty much anything.

That is also my interpretation/fear here. :-/

- - ferg

-- 
Paul Ferguson
PGP Public Key ID: 0x63546533