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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 10 January 2014 22:00 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 CD8861AE20D for <perpass@ietfa.amsl.com>; Fri, 10 Jan 2014 14:00:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 iC89R7TML2kP for <perpass@ietfa.amsl.com>; Fri, 10 Jan 2014 14:00:15 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 95D3E1AE20B for <perpass@ietf.org>; Fri, 10 Jan 2014 14:00:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9E6E0BE47; Fri, 10 Jan 2014 22:00:04 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 jJkawGsfdzAl; Fri, 10 Jan 2014 22:00:03 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.44.74.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 331F1BE3F; Fri, 10 Jan 2014 22:00:03 +0000 (GMT)
Message-ID: <52D06D63.7070900@cs.tcd.ie>
Date: Fri, 10 Jan 2014 22:00:03 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>, perpass@ietf.org
References: <mailman.42.1389384009.839.perpass@ietf.org> <52D062BB.1030906@gmail.com>
In-Reply-To: <52D062BB.1030906@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [perpass] Fwd: 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: Fri, 10 Jan 2014 22:00:17 -0000

Hiya,

On 01/10/2014 09:14 PM, Yaron Sheffer wrote:
> Hi Stephen,
> 
> I haven't read the protocol yet (although I must say Sec. 4.3 worries
> me, it reminds me of the renegotiation vulnerability), but:
> 
> - I understand MPLS traffic is often protected at a higher layer by
> IPsec. If we had a good opportunistic solution for IKE/IPsec, it could
> also cover this use case. And we know people are working on such
> solutions. [Here, that's me and my little turf war].

I think opportunistic IPsec could certainly help yes. I'm not
sure if this use-case is being considered in that work.

> - But even at layer 2, there are existing solutions like WPA or MacSec.
> Can none of them be used (or extended) for this use case and do we
> really have to develop both the bulk encryption and key exchange from
> scratch? 

And that too.

However, my understanding of MPLS is that basically neither IPsec
nor layer 2 crypto are used in many or possibly most cases. My hope,
(and I'd not put it stronger than that for now), is that this might
be a another useful tool in the tool-box that could have a better
chance of being deployed if we develop it with together with MPLS
folks who'd like such a tool. Though I'm sure there'll be MPLS
and other folks who hate the idea as well, we'll see.

Overall, my goal is to get some crypto that's deployable for
protecting MPLS traffic and I'm not fussed whether that means
re-using a flavour of IPsec nor some L2 stuff from elsewhere, nor
whether it turns out that we need to re-do some things in a way that
works better for our "customers" as in the proposal here.

Separately, if we (being the IETF as a whole), are going to end
up adding opportunistic crypto to various protocols then I think
we could do with some practice, and I'm happy to get beaten up
offering up the 1st instance of text like that. But each time
someone does that the questions you ask should also be asked.

> Sorry to be such a spoilsport.

You're not. Those are good questions and it'd not be the first
time I'd barked up the wrong tree, if that's the case here which
is quite possible.

Cheers,
S.



> 
> Thanks,
>     Yaron
>