[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
- [perpass] Violating end-to-end principle: I-D Act… Adrian Farrel
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Joseph Lorenzo Hall
- Re: [perpass] Violating end-to-end principle: I-D… Theodore Ts'o
- Re: [perpass] Violating end-to-end principle: I-D… Dave Crocker
- Re: [perpass] Violating end-to-end principle: I-D… Stephen Farrell
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Christian Huitema
- Re: [perpass] Violating end-to-end principle: I-D… Phillip Hallam-Baker
- Re: [perpass] Violating end-to-end principle: I-D… Stephen Kent
- [perpass] tcpcrypt applicability (Was: Re: Violat… Stephen Farrell
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Dave Crocker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Phillip Hallam-Baker
- [perpass] Increasingly strange thread (was: .... … Leif Johansson
- Re: [perpass] Increasingly strange thread (was: .… Scott Brim
- Re: [perpass] tcpcrypt applicability (Was: Re: Vi… Stephen Kent