Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

Alex Elsayed <eternaleye@gmail.com> Sat, 18 January 2014 06:55 UTC

Return-Path: <gip-perpass@m.gmane.org>
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 9B52E1A1F56 for <perpass@ietfa.amsl.com>; Fri, 17 Jan 2014 22:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 LFUcnM7iellF for <perpass@ietfa.amsl.com>; Fri, 17 Jan 2014 22:55:19 -0800 (PST)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7200B1A1F1F for <perpass@ietf.org>; Fri, 17 Jan 2014 22:55:19 -0800 (PST)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <gip-perpass@m.gmane.org>) id 1W4Po8-00013Z-4z for perpass@ietf.org; Sat, 18 Jan 2014 07:55:04 +0100
Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <perpass@ietf.org>; Sat, 18 Jan 2014 07:55:04 +0100
Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <perpass@ietf.org>; Sat, 18 Jan 2014 07:55:04 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: perpass@ietf.org
From: Alex Elsayed <eternaleye@gmail.com>
Date: Tue, 14 Jan 2014 01:18:38 -0800
Lines: 24
Message-ID: <lb2vd4$4um$1@ger.gmane.org>
References: <mailman.42.1389384009.839.perpass@ietf.org> <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <52D40D16.7060307@bbn.com> <20140113161349.GA22541@thunk.org> <52D41A06.2000008@bbn.com> <20140113185350.GA23463@thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-50-132-41-203.hsd1.wa.comcast.net
User-Agent: KNode/4.12
Subject: Re: [perpass] Fwd: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
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: Sat, 18 Jan 2014 06:55:20 -0000

Theodore Ts'o wrote:

> On Mon, Jan 13, 2014 at 11:53:26AM -0500, Stephen Kent wrote:
>> >It helps against some attacks, but it doesn't help for others, right?
>> >After all, if you are a US national, you might not trust that the
>> >Chinese Telecom won't pass your traffic to the MSS.  (Or if you are a
>> >German national, that AT&T won't decrypto your traffic and then pass
>> >it off to the NSA...)
>> yep. IPsec, under the control of a subscriber, offers more protection,
>> in princple.
> 
> Or put another way, MPLS-mediated encryption violates the end-to-end
> principle.  It also allows ISP's to violate net neutrality principles
> as well (i.e., by allowing them to do deep packet inspection and then
> prioritizing some traffic over others).
> 
> - Ted

On the other hand, encryption occurring at the MPLS layer in the ISP in no 
way prevents someone from using IPsec for traffic that ISP carries - in 
fact, there are cases (ISP wishes to prevent parties from eavedropping 
without the ISP's signoff while customer wishes to prevent eavesdropping 
period; possibly others) where the incentives would naturally support the 
deployment of both.