Subject: [manet] Linklocal DLEP

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 18:37:35 +0100

Hi,

I talked with Rick about it and we agree to open a thread for this.

I am seeing a security feature creep coming, and there is not much we can do.

we already added the option for TLS. But even in Prague I said that
TLS would not help if we don't secure the UDP beacon (downgrade
attack!) and somehow connect both security sessions (otherwise the
attacker can fool a secure UDP beacon which says "please no TLS").

Now we are talking about in-link Man in the Middle attackers. And
about "semi-mandatory" client AND server certificate. And we are still
not done with a "good" security solution. We are talking about
securing a DLEP connection with multiple IP hops without even
considering how the hell the bridged user space traffic would get over
this distance.

We don't even know what a sane "attacker model" for DLEP would look like.

>From my point of view we are killing a really good part of DLEP, the
zero configuration autodiscovery. Plug your DSL-Modem/Radio into your
Router and it will work!

"Oh, plug your DSL-Modem into your router, copy your router
certificate to your USB, go to the website of the Modem and upload it,
grab the client certificate and download it, upload it to the
Router... oh, and validate the Hashes please!" doesn't sound nice.

-----------------------

So I would like to propose something different. Lets talk about
Linklocal-only DLEP.

Make sure (with both IP addresses AND TTL field) that we only
communicate a single hop with DLEP, both UDP and TCP.

And lets throw out ALL TLS out of the DLEP draft.

There is already a way to secure a link against an attacker, its
called 802.1x. If someone wants to establish a "multihop DLEP
connection", just setup a secure layer-2 VPN. We can put both into a
security consideration section.

Lets REDUCE the complexity of the draft and keep the good parts.

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Tue, 24 Nov 2015 17:48:37 +0000

All,

I'm a +1 on this one.

We keep discussing this concept of multi-hop DLEP that we are trying to 
secure, but given the layer-2 connectivity assumption in DLEP, I'm not 
sure if it's actually possible to have multi-hop DLEP!

If someone can describe how multi-hop DLEP works (I'm too tired to try 
it now) then we can worry about TLS.

Rick

P.S. I love ASCII art, give me a network diagram or I'm going to ask 
dumb questions.

On 24/11/15 17:38, Henning Rogge wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 25 Nov 2015 10:41:02 +0100

> zero configuration autodiscovery. Plug your DSL-Modem/Radio into your

[...]

> Linklocal-only DLEP.

[...]

> And lets throw out ALL TLS out of the [base] DLEP draft.

Please listen to this man.  More experience is needed before we converge
on a sane security model for DLEP, and the base DLEP work should not be
held up by this.

-- Juliusz

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 25 Nov 2015 10:22:01 +0000

Unfortunately or fortunately, depending on your point of view, that's not how it works. "Base spec now, security later" isn't accepted. (One argument is about whether later ever arrives.) Separate documents, perhaps. But that will still hold up the base spec.

--  
Christopher Dearlove
[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Wed, 25 Nov 2015 13:40:13 +0100

> Unfortunately or fortunately, depending on your point of view, that's not how it works. "Base spec now, security later" isn't accepted. (One argument is about whether later ever arrives.) Separate…

Yes it does work... in a certain way.

A "linklocal DLEP" can just point to the existing ways to secure a
link instead of modifying the protocol itself.

something like:

> Security Considerations (quick and dirty version):
> a) at best, use a dedicated plug on the router and a direct cable connection
> b) otherwise use a VLAN separation to keep the other traffic away from the user/control data to the radio
>
> you can also add 802.1x to control the devices connected to your interfaces and/or MACsec to provide an encrypted link for both user and control traffic

the advantage of this is that NONE of these things make DLEP more
complex, they can be deployed independently.

I would also suggest to add something like
"by default, the DLEP radio should use linklocal addresses for both
UDP and TCP socket. If an administrator changes this, the link MUST be
secured with one or multiple of the options mentioned in the Security
Considerations."

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 Nov 2015 13:17:20 +0000

>> b) otherwise use a VLAN separation to keep the other traffic away from the user/control data to the radio

The VLAN separation is actually required for the data plane anyway.

> secured with one or multiple of the options mentioned in the Security

+1, The hard part as I see it is crafting the words.

Does anyone have any issue with what I see as emerging consensus around:

1) STRONGLY RECOMMENDING Link-local addresses and/or direct connection.

2) Referencing the various layer-2 security solutions for >1 hop 
deployments.

3) Removing the TLS requirement.

Rick

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Wed, 25 Nov 2015 13:23:56 +0000

>3) Removing the TLS requirement.

I like this general direction.  The ongoing hassle of certificate
management with TLS was starting to concern me.

David

---

From: Henning Rogge <[email-masked]>
Date: Wed, 25 Nov 2015 14:37:55 +0100

> The VLAN separation is actually required for the data plane anyway.

Yes... unless you have a dedicated ethernet card to connect to the radio.
> 2) Referencing the various layer-2 security solutions for >1 hop

These are even useful for single-hop solutions if the deployment calls
for more security.

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Wed, 25 Nov 2015 13:44:56 +0000

> Yes... unless you have a dedicated ethernet card to connect to the radio.

Of course.

> These are even useful for single-hop solutions if the deployment calls

Okay, agreed, so we could reference layer-2 security measures (802.1x 
etc) for all link types.

Rick