Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 01 July 2015 16:17 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01D41A913B for <mpls@ietfa.amsl.com>; Wed, 1 Jul 2015 09:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, T_TVD_FUZZY_SECURITIES=0.01] 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 f_MBwcfPiW2N for <mpls@ietfa.amsl.com>; Wed, 1 Jul 2015 09:17:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20F81A9136 for <mpls@ietf.org>; Wed, 1 Jul 2015 09:17:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BFACFBDD0; Wed, 1 Jul 2015 17:17:47 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXeT8lIuxprC; Wed, 1 Jul 2015 17:17:47 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E622BDCF; Wed, 1 Jul 2015 17:17:47 +0100 (IST)
Message-ID: <559412AB.90201@cs.tcd.ie>
Date: Wed, 01 Jul 2015 17:17:47 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Eric C Rosen <erosen@juniper.net>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org" <draft-farrelll-mpls-opportunistic-encrypt@tools.ietf.org>
References: <55828B69.3070603@pi.nu> <55880C91.507@juniper.net> <559129C8.7000407@cs.tcd.ie> <559196F1.90006@juniper.net> <5591BE65.3080409@cs.tcd.ie> <55940D15.7000102@juniper.net>
In-Reply-To: <55940D15.7000102@juniper.net>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/fdqWdL6upi-fA_15YP0iiq8CaqA>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 16:17:51 -0000

Eric,

On 01/07/15 16:53, Eric C Rosen wrote:
>

I'll skip over the speculative negative rhetoric about security ADs:-)

> 
> It would certainly be interesting to hear from operators whether they
> think there really is a need for "opportunistic" security as opposed to
> PKI-based security, especially given the way that some of the evolving
> BGP security schemes seem to be relying on PKI-based techniques.  

That would be interesting yes, though its not actually at all about
whether one does or does not use a PKI. (A PKI could easily be used
to authenticate the keys belonging to endpoints implementing this
draft - that's an entirely straight forward option one could define
in a few minutes.)

But if one looks at the complexity of the RPKI and contrasts that with
this draft, there is a real divergence in approaches for sure. RPKI
is v. complex but aims to be comprehensive, has taken a long time to
develop and more to start deployment and may need to achieve
significant deployment before its most appealing benefits accrue.
The reason for that isn't the PKI in the RPKI name, but I think the
fact that it's main aim is to provide authentication and authorization
for the entire routing infrastructure.

This approach tries to be much more light weight and focus on ease
of deployment as and where beneficial but without trying to meet
every potential need.

My experience of security protocols is that the approach we're trying
to follow here is more likely to lead to useful deployment. But that
experience may or may not be replicated in this space, I'm not sure.

S.