[perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 14 January 2014 12:24 UTC

Return-Path: <adrian@olddog.co.uk>
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 155981ADED5 for <perpass@ietfa.amsl.com>; Tue, 14 Jan 2014 04:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 wg-Z6ZCLpnoM for <perpass@ietfa.amsl.com>; Tue, 14 Jan 2014 04:24:11 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2A1AE081 for <perpass@ietf.org>; Tue, 14 Jan 2014 04:24:10 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECNsfc002019; Tue, 14 Jan 2014 12:23:54 GMT
Received: from 950129200 ([62.205.119.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s0ECNoEe002002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Jan 2014 12:23:51 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Theodore Ts'o' <tytso@mit.edu>, 'Stephen Kent' <kent@bbn.com>
Date: Tue, 14 Jan 2014 12:23:52 -0000
Message-ID: <04c001cf1123$7e5c00c0$7b140240$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac8RI3uQd/KgxOxTTEC64YuTCdHoyQ==
Content-Language: en-gb
Cc: perpass@ietf.org
Subject: [perpass] Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Tue, 14 Jan 2014 12:24:13 -0000

> > >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).

Two things here (probably wandering into a minefield, but that's my ball that
rolled in):

1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regulators, morals,
or encryption of the pieces that might be deeply inspected.
You might as well say that not shooting elephants allows ISPs to do DPI!
So, I think what you are saying is that not doing IPsec on your (IP) traffic
allows the ISP to do DPI.
But doing MPLS encryption also stops transit nodes from doing DPI, but it does
not stop edge (i.e., MPLS end) nodes from doing DPI.
In some deployments (carrier's carrier, MPLS-based enterprise over ISP) the
traffic may already be MPLS, and so MPLS encryption might be what is available.

2. I think the end-to-end principle may already have been somewhat diluted by
the introduction of edges, and the deployment of tunnels. I am guessing that you
mean that the responsibility for securing traffic lies with the
originator/consumer of the traffic. And that is largely fine, but again runs
into VPN type discussions.

Adrian