[perpass] comments and questions for the group on draft-farrell-perpass-attack-02
Eliot Lear <lear@cisco.com> Mon, 09 December 2013 12:29 UTC
Return-Path: <lear@cisco.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986F51AE291; Mon, 9 Dec 2013 04:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi8r05mJj8lZ; Mon, 9 Dec 2013 04:29:25 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8941ADF6E; Mon, 9 Dec 2013 04:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3142; q=dns/txt; s=iport; t=1386592160; x=1387801760; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=Oa7KuxQC6L95Ka63+bO1jBfwKNBD99mrvnoBwX/HTSk=; b=CzN9KAFOfpoPc5I70Rh77MJgmw2TmKwhF33y4HJkolsrkzHqExxjJnwz umV9yTP3SaBKsVDXZd2S3HYcGCR+mQLVRFVCPCGoY1eaxBYfBJX/+SH+s wmU4fXV7NizQQ4+SY5bqxaP0ue91/xrAgWDhQZwm9RTu1VDL5R8+274hb M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAFa2pVKQ/khM/2dsb2JhbABZgwc4g1K2FYEtFnSCJQEBAQMPFUIJCgEFMAIFDAoLAgsDAgECAUsBDAEHAQGHeAayBY8lF4EpjQ9YEYJhgUgDlDGDY5ITgyo7gSw
X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208";a="1297337"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 12:29:19 +0000
Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9CT9dV006481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 12:29:10 GMT
Message-ID: <52A5B79E.2040202@cisco.com>
Date: Mon, 09 Dec 2013 13:29:18 +0100
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: "ietf-interest(mailer list)" <ietf-interest@cisco.com>, perpass <perpass@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Auto-Response-Suppress: DR, OOF, AutoReply
Cc: Internet Architecture Board <iab@iab.org>, 'IESG' <iesg@ietf.org>
Subject: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 12:29:26 -0000
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] comments and questions for the group on… Eliot Lear
- Re: [perpass] comments and questions for the grou… Eric Burger
- Re: [perpass] comments and questions for the grou… Robin Wilton
- Re: [perpass] comments and questions for the grou… Stephen Farrell
- Re: [perpass] comments and questions for the grou… Eliot Lear
- Re: [perpass] comments and questions for the grou… Eliot Lear
- Re: [perpass] comments and questions for the grou… Eliot Lear
- Re: [perpass] comments and questions for the grou… Eliot Lear
- Re: [perpass] comments and questions for the grou… Paul Ferguson
- Re: [perpass] comments and questions for the grou… Brian E Carpenter