Re: [perpass] Who manages the encryption: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
Stephen Kent <kent@bbn.com> Wed, 15 January 2014 15:18 UTC
Return-Path: <kent@bbn.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 1E84E1AE38A for <perpass@ietfa.amsl.com>; Wed, 15 Jan 2014 07:18:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level:
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 8-cJ7HldxG2C for <perpass@ietfa.amsl.com>; Wed, 15 Jan 2014 07:18:46 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCAB1AE37B for <perpass@ietf.org>; Wed, 15 Jan 2014 07:18:46 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:40593 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1W3SEk-000C5v-2B; Wed, 15 Jan 2014 10:18:34 -0500
Message-ID: <52D6A6C9.9030401@bbn.com>
Date: Wed, 15 Jan 2014 10:18:33 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, perpass@ietf.org
References: <04c101cf1125$7c249c70$746dd550$@olddog.co.uk>
In-Reply-To: <04c101cf1125$7c249c70$746dd550$@olddog.co.uk>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [perpass] Who manages the encryption: 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: Wed, 15 Jan 2014 15:18:48 -0000
Adrian, ... > But you main point remains, and I have been asking a number of carriers lately > why they don't use L2 security. A whole range of answers from manageability, > through reduced capacity, to the fact that it doesn't protect against > subverted/misconfigured transit nodes. These seem like reasonable responses, and there is the fact that any L2 security mechanism will not play well with any intermediate L3 switching/routing devices. > The message seems to be that the higher up (or further out) we can run our SAs > the more secure our data (and the more under our control the fact of security > is), but the less metadata is protected and the more complex the SAs are to > manage. The tradeoffs are not trivial. E-t-e security (confidentiality, authentication, integrity, etc.) is "best" but it is also the most costly to deploy and manage in many contexts. Deploying security at an administrative boundary for an enterprise makes sense for most environments, as it is less expensive and much, much easier to manage. That's why a firewall at the interface to an ISP is generally more attractive than per-user device firewalls in an enterprise. This argues for IPsec gateways, vs. per-user device IPsec, in such environments. One can view MPLS encryption as analogous, but if the MPLS encryption is provided by an ISP, vs. an enterprise, the analogy is not quite the same. Traditionally, the security community has felt that the tradeoff between traffic flow confidentiality and e-t-e confidentiality should be skewed toward the latter. In part this is because there may be many other ways to acquire the protocol metadata, and because the extra costs associated with providing good TFC are viewed as too high. In the 80's I recall that the US DoD didn't feel that it was worth the cost of providing TFS for traffic at the SECRET level or below, and they were worried about nation state adversaries. So it's a hard sell, in my mind, to emphasize TFC for the vast majority of Internet traffic, unless the costs (capital, recurring, and user impact) are essentially zero. Steve
- [perpass] Who manages the encryption: FW: I-D Act… Adrian Farrel
- Re: [perpass] Who manages the encryption: FW: I-D… Stephen Kent