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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 13 Dec 2016 16:02:09 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-manet-dlep-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alexey's discuss point about the security considerations.

-5.1: Is discovery support optional?
Can you offer any guidance on a reasonable maximum interval for peer
discovery signals?

- 5.2: It's probably worth mentioning that the messages from here onward
go over the TCP connection established as a result of discovery.
Can you offer any guidance on how long a modem should wait for the
Session Initiation Message before abandoning a connection?

-7, paragraph 2: "they will need to
   be standardized either as an update to this document, or as an
   additional stand-alone specification."
I'm not sure what the distinction is between an update vs a stand-alone
specification in this context. But in any case, it's unusual to require
that a spec update an RFC to exercise  defined extension points.

- 8, first paragraph: "At large scale, implementations SHOULD
   consider employing techniques to prevent flooding its peer with a
   large number of Messages in a short time."

The SHOULD consider is an odd use of a 2119 SHOULD. If the intent is to
tell implentors to think about this, then the SHOULD is probably not
appropriate. Or does this mean "implementations SHOULD employ techniques"
(which would be perfectly reasonable)?

-10.3: This seems to forbid the configuration of non-standard ports. Is
that the intent?

- 10.5, 2nd to last paragraph: Can you offer any sort of guidance at all
for Session Initiation timeout values?

-11.5: Do heartbeat messages occur in parallel to other active traffic,
or only when things are quiet? Or in other words, do messages other than
heartbeats reset the heartbeat interval timer?

Can you offer any guidance on reasonable heartbeat interval values, or
guidance on how to choose a value? It seems like there could be a lot of
heartbeat messages if people choose low values.

-12 Is eavesdropping a concern? Could inserted messages be used to direct
user traffic over a compromised link?
What is the reasoning to not at least require implementation of TLS?
Do you imagine situations where it might make sense not to use TLS, other
than the mentioned? ("deployments where the DLEP router and modem are the
only devices on a physical Layer 2"). Would a "MUST use TLS unless..."
construction make sense here?

Editorial Comments:

- General: Neither the abstract or the first few paragraphs of the
introduction mention that this draft creates a protocol. That sort of
buries the lede. Please consider mentioning that both in the abstract and
near the top of section 1.

- 10.5, 2nd to last paragraph: "DLEP Heartbeats are not fully established
"

I'm not sure what it means to fully establish heartbeats. Would it be
reasonable to say "... not started"?

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 13 Dec 2016 20:25:54 -0500

Ben,

Thank you for the review. We will put these action items on the list for
the next revision. Some additional responses inline.

> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

Discovery support is optional for routers (the sender of the MCAST
discovery message); it is mandatory for modems. Routers may rely on
a-priori configuration to reach the modem.

That said, we will provide some guidance on a maximum interval for peer
discovery signals. My initial take (without consensus from my fellow
authors) would be some small number of minutes (perhaps 5) at maximum.

> Session Initiation Message before abandoning a connection?

Will do, on both points.

> that a spec update an RFC to exercise  defined extension points.

We will change that text. We'll drop the reference to a spec update.

> (which would be perfectly reasonable)?

Yes, that was the intent - that "implementations SHOULD employ techniques".
We'll make that change.

> -10.3: This seems to forbid the configuration of non-standard ports. Is

The Peer Discovery signal itself doesn't have the ability to flow on a
non-standard port. Otherwise, the modem wouldn't receive the Peer
Discovery.

However, the TCP session can be established on a non-standard port, via
either a-priori config in the router, or use of the non-standard port in
the "Connection Point" TLVs.

> for Session Initiation timeout values?

Yes, we will provide that guidance.  Again, without consensus from my
co-authors, this should be a small number of seconds (10, for example).

> heartbeats reset the heartbeat interval timer?

Our intent was for other messages to "count" as heartbeats - Section 5.3.1
(Heartbeats), says in part:

"Receipt of any valid DLEP Message MUST reset the heartbeat interval timer
(i.e., valid DLEP Messages take the place of, and obviate the need for,
additional Heartbeat Messages)."

> heartbeat messages if people choose low values.

Yes, we will offer some guidance. In the end, the Heartbeat interval would
need to take into consideration the frequency of "normal" DLEP messages,
and the "pain level" of potential black-holing of traffic. Without
co-author consensus, I'd expect the timer set at around 15-30 seconds.

> construction make sense here?

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.

> near the top of section 1.

Will do.

> reasonable to say "... not started"?

Yes. We'll make that change.

Regards,
Stan

>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 14 Dec 2016 10:31:52 -0600

Thanks for the response. I've removed sections that don't seem to need 
further discussion.

On 13 Dec 2016, at 19:25, Stan Ratliff wrote:

[...]

> a-priori configuration to reach the modem.

Did I miss language that said that in the draft? If not, an explicit 
mention would be helpful.

> authors) would be some small number of minutes (perhaps 5) at maximum.

[...]

> non-standard port. Otherwise, the modem wouldn't receive the Peer

I understand that this makes it technically impossible for a router and 
modem to "agree" (via config) to use a different port for discovery, 
correct? Off the cuff, I can imagine some use cases for that, e.g. in 
testing, or to partition clusters of modems. But if the working group 
intentionally chose to forbid that, I'm okay with it.

> the "Connection Point" TLVs.

Do I understand correctly that the "standard" TCP port only matters if 
the router is configured to skip discovery and directly connect?

[...]

> additional Heartbeat Messages)."

Got it; missed that. It might be helpful to mention that fact in the 
language about the heartbeat interval.

[...]

> small number of other devices. We're open to the construction you 

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_?

[...]

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Dec 2016 09:45:34 +0100

On Wed, Dec 14, 2016 at 5:31 PM, Ben Campbell <[email-masked]> wrote:
> 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.

Henning Rogge

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 15 Dec 2016 08:53:58 -0600

> There is a LOT of work in this direction without any gain.

IIRC, you are arguing against even the existing "SHOULD implement" 
requirement?

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?

Thanks!

Ben.

---

From: Rick Taylor <[email-masked]>
Date: Thu, 15 Dec 2016 14:58:27 +0000

On Thu, 2016-12-15 at 08:53 -0600, Ben Campbell wrote:
> > > > We (the co-authors) have received feedback from some radio
> > > > vendors 
> > > > stating
> > > > 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

Most of the discussed use-cases where TLS is viewed as unnecessary are
direct connections, but some are single-hop with an 'externally secured
perimeter'.

The authors are happy with 'SHOULD' if it removes any blocks from the
IESG, and the WG consensus is that 'MUST' will not work for
implementers.

Rick

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 15 Dec 2016 09:07:54 -0600

> IESG, and the WG consensus is that 'MUST' will not work for

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

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Dec 2016 16:14:34 +0100

On Thu, Dec 15, 2016 at 3:53 PM, Ben Campbell <[email-masked]> wrote:
>>> the

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

> 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