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

Mark Tinka <mark.tinka@seacom.mu> Thu, 09 January 2014 13:15 UTC

Return-Path: <mark.tinka@seacom.mu>
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 97B2A1AE1D9 for <mpls@ietfa.amsl.com>; Thu, 9 Jan 2014 05:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.589
X-Spam-Level:
X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311] 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 MHefDBu_DPO1 for <mpls@ietfa.amsl.com>; Thu, 9 Jan 2014 05:15:03 -0800 (PST)
Received: from the-host.seacom.mu (ge-0.ln-01-jnb.za.seacomnet.com [41.87.104.245]) by ietfa.amsl.com (Postfix) with ESMTP id E7AF71AE2BB for <mpls@ietf.org>; Thu, 9 Jan 2014 05:15:01 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=the-host.localnet) by the-host.seacom.mu with esmtp (Exim 4.80.1) (envelope-from <mark.tinka@seacom.mu>) id 1W1FRR-0003Vr-Iz; Thu, 09 Jan 2014 15:14:33 +0200
From: Mark Tinka <mark.tinka@seacom.mu>
Organization: SEACOM
To: mpls@ietf.org, adrian@olddog.co.uk
Date: Thu, 09 Jan 2014 15:14:29 +0200
User-Agent: KMail/1.13.6 (Linux/2.6.37.6-24-desktop; KDE/4.6.0; i686; ; )
References: <20140109114335.11656.57445.idtracker@ietfa.amsl.com> <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk>
In-Reply-To: <01be01cf0d31$13fdea40$3bf9bec0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1808822.iEuItDjuWL"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201401091514.32953.mark.tinka@seacom.mu>
Cc: stephen.farrell@cs.tcd.ie
Subject: Re: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mark.tinka@seacom.mu
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: <http://www.ietf.org/mail-archive/web/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: Thu, 09 Jan 2014 13:15:04 -0000

On Thursday, January 09, 2014 01:51:03 PM Adrian Farrel 
wrote:

> Hi MPLS working group,
> 
> Stephen and I have been looking at MPLS data plane
> security and wondering whether anything could be done to
> help protect against various types of bulk surveillance
> achieved by tapping entire links without requiring full
> and management-heavy establishment of security
> associations.
> 
> This I-D is very rough! it is a first attempt to show
> what might be achieved. We are confident that there are
> problems with what we have suggested both from a
> security and an MPLS perspective. Your thoughts and
> comments are encouraged.

Thanks for this draft, Farrel twins.

As an operator, my rather high level concerns are:

	- What impact does this have on linear data plane
	  throughput?

	- What impact does this have on data plane
	  operational complexity?

	- What impact does this have on the control plane.

	- How efficient is key management on a global level,
	  and what is the practical impact to day-to-day
	  operations, for situations where MPLS paths cross
	  distinct routing domains?

	- What kind of backward compatibility is there for
	  domains that do not participate, or for nodes
	  within the same domain that do not participate, as
	  this has an impact on overall domain capability
	  (i.e., cost).

Cheers,

Mark.