Re: [manet] Ben Campbell's No Objection on draft-ietf-manet-dlep-26: (with COMMENT)

[Henning Rogge <[e-mail]>]

On Thu, Dec 15, 2016 at 3:53 PM, Ben Campbell <[e-mail]> wrote:
> On 15 Dec 2016, at 2:45, Henning Rogge wrote:
>
>> On Wed, Dec 14, 2016 at 5:31 PM, Ben Campbell <[e-mail]> wrote:
>>>>
>>>> We (the co-authors) have received feedback from some radio vendors
>>>> stating
>>>> that a "MUST use TLS" in all cases would be a show-stopper. We see
>>>> deployments where a small number of devices co-exist on the LAN segment
>>>> -
>>>> for example, a router, a line-of-sight radio, a satellite terminal, and
>>>> a
>>>> small number of other devices. We're open to the construction you
>>>> suggest,
>>>> and will discuss it.
>>>
>>>
>>> Understood. That suggests there are reasons to not _use_ TLS other than
>>> the
>>> listed one, so "MUST unless" may not be what you want.  Any thoughts on
>>> why
>>> TLS should not be mandatory to _implement_?
>>
>>
>> I might exaggerate it a little bit but I think using TLS for DLEP is
>> at best a waste of time to implement. I have yet to hear about an
>> attacker model for a single hop DLEP connection (which is necessary
>> because otherwise the bridged datapath is broken!) which is not easily
>> dealt with MAC-layer security.
>>
>> At worst TLS will kill one of the most important aspects of DLEP, easy
>> integration and autodiscovery of radios by different vendors to any
>> kind of router.
>>
>> TLS also opens  can of worms (additional questions). How is the DLEP
>> certificates be handled? Are there mandatory types of certificate
>> algorithms (if not, you break interoperability)? How do you secure the
>> UDP part of DLEP for discovery (DTLS?) ? How do you make sure that the
>> DTLS connection is to the same endpoint as the TLS connection?
>>
>> There is a LOT of work in this direction without any gain.
>
>
> IIRC, you are arguing against even the existing "SHOULD implement"
> requirement?

I am trying to provide a "strong agree" with Stan Ratliff's opinion
that any move towards "MUST unless X" or similar is counterproductive.

> When you talk about a single-hop connection, are you assuming a direct
> connection from the router to the modem, or that the router and modem are on
> the same LAN segment?

I have seen two (and thought about a third) different kind of
deployments for DLEP... we also had (at Fraunhofer FKIE) discussions
with a few military radio vendors how they could use DLEP and they
also fit into these three scenarios.

1.) a direct ethernet (point to point) cable between the radio and the router.
2.) a router connected with a switch using VLAN to configure a direct
(point to point) connection to the radio connected to the switch.
3.) a layer2 tunnel between router and radio, allowing to span some
intermediate network between radio and router

the third point was discussed in a scenario with a "multi-router
emulator" based on VM technology connected to real radios, but never
really deployed.

DLEP provides a router with knowledge about an interface and the
neighbors behind it. If you provide a three-way layer-2 connection
between a radio, a router and some third device you instantly break
the view DLEP will deliver because the "whole interface metrics" DLEP
deliver don't apply anymore to the whole interface. Things get even
worse when you want to do flow control in the router and suddenly have
neighbors DLEP does not tell you about, most likely your routing
functionality will break in a creative way.

You cannot even switch two DLEP radios together on the same layer-2
segment, connect them to a router and expect the whole thing to work.
Now you have two radio interfaces and a router who cannot
differentiate between them, because you can only sent your
(linklocal-) Multicast to either both of them or don't send at all.

so yes... "single hop" is most likely a dedicated point-2-point cable
or a VLAN simulation of the same.

> Am I hearing that this is one of those proverbial "SHOULD BUT WE KNOW YOU
> WON'T" requirements :-)

I would expect making it "RECOMMENDED" or "MUST unless" would result
in a lot of semi-tested bitrotting code nobody is using. Or maybe a
"does not support TLS" note in the manual.

Henning Rogge