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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 14 January 2014 20:24 UTC

Return-Path: <mcr@sandelman.ca>
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 3E1581AE0D5 for <perpass@ietfa.amsl.com>; Tue, 14 Jan 2014 12:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.019
X-Spam-Level: *
X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] 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 OWvfKxRCDxkW for <perpass@ietfa.amsl.com>; Tue, 14 Jan 2014 12:24:16 -0800 (PST)
Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id BB8641ADF83 for <perpass@ietf.org>; Tue, 14 Jan 2014 12:24:15 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E1BE2002C; Tue, 14 Jan 2014 16:39:46 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 76CC364647; Tue, 14 Jan 2014 15:24:03 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6212963B88; Tue, 14 Jan 2014 15:24:03 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: perpass@ietf.org
In-Reply-To: <52D48271.8060007@bbn.com>
References: <mailman.42.1389384009.839.perpass@ietf.org> <52D062BB.1030906@gmail.com> <52D06D63.7070900@cs.tcd.ie> <alpine.LFD.2.10.1401101843020.18879@bofh.nohats.ca> <52D18B01.4040903@gmail.com> <52D48271.8060007@bbn.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 14 Jan 2014 15:24:03 -0500
Message-ID: <24169.1389731043@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: Stephen Kent <kent@bbn.com>
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: Tue, 14 Jan 2014 20:24:17 -0000

Stephen Kent <kent@bbn.com> wrote:
    > because it is different, I suggest that we not call it OE, which is
    > clearly defined in RFC 4322.  I suggest opportunistic keying (OK).

I just want to say that rfc4322 (an *Informational*) rfc, defines:
   Opportunistic Encryption using the Internet Key Exchange

which might be best called "OEIKEv1"

key thing about OEIKEv1 is that it binds end points to IP addresses using
reverse DNS, with some weakening where a node may speak for itself (only).
It does *not* mandate that the phase2/CHILDSA be IPsec ESP.

So, if you want to call it OEMPLS or something like that, I'd say it's just
fine.

Further if someone wants to write a mechanism for IKE(v2) that lets you key
MPLS flows, and there is some way to bind MPLS flows to an IPv4 or IPv6 end
point, then I think that one could leverage much of the work.

I think that one could quite easily insert something in at the MPLS layer
that would provide some token that could be cryptographically bound by IKE
to prove that the two MPLS end points are connected to each other below the
IP layer.  What, exactly, I don't know.... I never built MPLS pusher/popper
hardware, just parsing/switching ASIC. (14 years ago)

I personally see no value in doing MPLS hop-by-hop encryption.
Where MPLS is used within a single AS, whether one does hop-by-hop or
label-push/label-pop encryption, it's all within the AS, and what is
protecting against bent fiber attacks.  Since it's all subject to national
order to the ISP, so, in my opinion, what's the point.

Where it would have value is to the end enterprise customer who is linking
multiple sites together in a layer-2 fashion.  In my experience, MPLS CPE
equipment is not under the control (i.e. not trusted) by the end customer, so
even doing entry/exit this way is suspect, since it's the ISP again.
Further, many of the MPLS deployments to "enterprises" have often not even
been about layer-2 connectivity --- they see layer-3 routers at each site,
(usually two or three of them, with different VLAN tags).
The MPLS part is pretty much just up-sale marketing...

All of this effort would be better spent pushing IKEv1 and L2TP off the map,
and making IPv6 + IPsec easier to setup.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works