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

From: Yaron Sheffer <[email-masked]>
Date: Fri, 10 Jan 2014 23:14:35 +0200

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].

- 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? Sorry to be such a spoilsport.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Jan 2014 22:00:03 +0000

Hiya,

> 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.

> 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.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jan 2014 18:48:21 -0500 (EST)

> sure if this use-case is being considered in that work.

Any non host-host case is very hard, as there is no way to verify any
claims for random subnets of the internet. AFAIK, no good methods exist
that any OE IPsec could use for auto-configuration. There is quite a
difference between "here is plaintext from you to Bob, encrypt it" and
"here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory".

> nor layer 2 crypto are used in many or possibly most cases.

I was probably naively hoping that people would consider MPLS as much
"outside" their network as the rest of the internet, and already have
deployed static IPsec between those networks. But I guess not....

Paul

---

From: Leif Johansson <[email-masked]>
Date: Sat, 11 Jan 2014 01:32:17 +0100

On 2014-01-10 22:14, Yaron Sheffer wrote:
> IPsec. If we had a good opportunistic 
I don't think that’s true at all in real-world deployments.
> 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].
>
> - 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? Sorry to be such a spoilsport.
>
> Thanks,
> Yaron
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 11 Jan 2014 20:18:41 +0200

> "here is plaintext from you to Bob at 8.8.8.0/24, encrypt to Mallory".
This is different from the normal IPsec OE scenario, and as a result may 
be easier to solve:
- The MPLS peer is already willing to send any traffic from the private 
network to the other peer, which it sincerely hopes is not a MITM.
- Each peer is typically running on an edge router (I believe) and so 
has much more awareness of the network than your typical IPsec OE peer. 
They will actually have the BGP information.

Thanks,
	Yaron

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jan 2014 10:58:14 -0500

Stephen,

> I think opportunistic IPsec could certainly help yes. I'm not sure if 
> this use-case is being considered in that work. 
I think it out to be. Experience has shown that getting all of the 
details right for a
layer 3 security protocol is hard. BTW, MPLS is (lower) layer 3, not 
layer 2.
> and other folks who hate the idea as well, we'll see.
I suspect you're right that IPsec is not used often in this context.
The use of MPLS would be qualitatively different, because it would
be offered by an ISP, not by a subscriber. Maybe that would result
in more encrypted traffic because ISPs would offer it as a low
cost service.
> works better for our "customers" as in the proposal here.
L2 stuff won't work across AS boundaries, unless the MPLS
tunnel crosses those boundaries.

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 13 Jan 2014 11:13:49 -0500

> in more encrypted traffic because ISPs would offer it as a low

It helps against some attacks, but it doesn't help for others, right?
After all, if you are a US national, you might not trust that the
Chinese Telecom won't pass your traffic to the MSS.  (Or if you are a
German national, that AT&T won't decrypto your traffic and then pass
it off to the NSA...)

					- Ted

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jan 2014 11:53:26 -0500

Ted,
> German national, that AT&T won't decrypto your traffic and then pass
yep. IPsec, under the control of a subscriber, offers more protection,
in princple.

Steve

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 13 Jan 2014 13:53:50 -0500

> yep. IPsec, under the control of a subscriber, offers more protection,

Or put another way, MPLS-mediated encryption violates the end-to-end
principle.  It also allows ISP's to violate net neutrality principles
as well (i.e., by allowing them to do deep packet inspection and then
prioritizing some traffic over others).

							- Ted

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jan 2014 19:18:57 -0500

Folks,
> This is different from the normal IPsec OE scenario, and as a result 
> may be easier to solve:
because it is different, I suggest that we not call it OE, which is 
clearly defined in RFC 4322.
I suggest opportunistic keying (OK).
> - The MPLS peer is already willing to send any traffic from the 
> private network to the other peer, which it sincerely hopes is not a 
> MITM.
> has much more awareness of the network than your typical IPsec OE 
> peer. They will actually have the BGP information.
I believe that the MPLS peers, as edge routers, are not under the 
control of the end users,
as would more likely be the case for IPsec gateways operating at about 
the same point in
the path. So, an important part of this discussion is that the 
administrative entities managing
the encryption are ISPs, not subscribers. Thus the confidentiality 
afforded here is more of
an ISP service than a subscriber-controlled service. Also, unless the 
MPLS path crosses AS
boundaries (not yet common, I believe) this offers less protection than 
IPsec could.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jan 2014 00:31:42 +0000

> I suggest opportunistic keying (OK).

I agree that we need to discuss terminology here and would be
fine with OK instead of OE if that's where land. (We mentioned
that terminology may change in the draft for this reason.)

> boundaries (not yet common, I believe) this offers less protection than

There are apparently some kinds of MPLS deployments where nodes are
under the customer's control. But yes, I agree that this potential
mechanism would be of most benefit where >1 administrative entity
is involved and might be of little benefit if that remains very
rare. I am told however that such deployments exist. I think there
may also be cases where MPLS is not carrying IP and where a
(non-collaborative) fibre tap might be a concern.

I think that the meta-point is that we should be chatting with the
MPLS folk to see what they want and are interested in deploying.
Then we can probably figure if some flavour of IPsec will be just
fine or if more (like our draft) is needed.

S.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Jan 2014 15:24:03 -0500

Stephen Kent <[email-masked]> wrote:
    > 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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Alex Elsayed <[email-masked]>
Date: Tue, 14 Jan 2014 01:18:38 -0800

> prioritizing some traffic over others).

On the other hand, encryption occurring at the MPLS layer in the ISP in no 
way prevents someone from using IPsec for traffic that ISP carries - in 
fact, there are cases (ISP wishes to prevent parties from eavedropping 
without the ISP's signoff while customer wishes to prevent eavesdropping 
period; possibly others) where the incentives would naturally support the 
deployment of both.