Subject: [manet] DLEP-15: Security Considerations

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 11:49:48 -0400

All,

While I find the security-related discussion in DLEP-15
to be an improvement, I still really don’t think it is
sufficient for a modern IETF standards-track protocol.
In fact, I think that any IETF Security Area review
(which is required by the IESG) also will say that the
current text is not sufficient.

1) Security implementation needs to be mandatory

The biggest single security issue with DLEP-15 is that 
the DLEP-15 specification “assumes” TLS will be used, 
which simply is not enough.  The IETF Security Area
reviewer is almost certainly going to object to the
current text, so I would like to see it get fixed in
DLEP-16 before the draft even goes to the IETF Security
Area.

Instead, the DLEP-15 specification should have language
requiring all DLEP implementations to support TLS.  I
have put together some draft candidate text for this below
in a specially marked part of this note. 

Note well that requiring DLEP implementations to support
TLS is a separate question from the operational decision
whether to use TLS in a particular deployment.  Traditionally,
the IETF mandates implementation of security, but only
provides advice on whether security is enabled in a
particular operational deployment.  The recommended
language below is consistent with that traditional practice.

In Section 2, page 10, top paragraph, I recommend that
the authors replace the existing text with this:

	“DLEP implementations are required to implement
	Transport Layer Security (TLS) [RFC5246] for 
        TCP sessions and Datagram Transport Layer Security
        (DTLS) [RFC6347] for UDP sessions. 

	Operational use of TLS and DTLS with DLEP is
	RECOMMENDED to reduce security risks."

In Section 11, I recommend replacing the paragraph that begins 
with “The protocol itself” with the following 3 paragraphs
(and adding the various BCP/RFC references to the REFERENCES
section of the DLEP specification):

	“DLEP implementations are required to implement
	Transport Layer Security (TLS) [RFC5246] for 
        TCP sessions and Datagram Transport Layer Security
        (DTLS) [RFC6347] for UDP sessions.  DLEP TLS and DTLS
	implementations MUST also implement and comply with 
	[BCP195], MUST implement and comply with the updates 
	in [RFC5746, RFC6176, RFC7465, RFC7505, RFC7505, 
	and RFC7568], and MUST NOT support cipher-suites 
	with less than 128-bits of effective key length 
	(NB: [BCP195] notes that the nominal key length 
	is not equal to effective key length in all cases.)

	For interoperability with other DLEP implementations
	when TLS and DTLS are in operational use, a mandatory
	to implement cipher suite needs to be specified.
	Accordingly, DLEP implementations of TLS and DTLS MUST
        implement at least the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”
        cipher suite. [BCP195, RFC5116]  This cipher suite is
	available at present in open-source (D)TLS implementations
	(e.g. OpenSSL), so this cipher-suite is readily available
        to implementers.  As of the date this document was written,
	this cipher suite also is reasonably strong, so is
	expected to have a reasonably long useful lifetime.

	Operational use of TLS and DTLS with DLEP is RECOMMENDED
	to reduce operational security risks, such as those 
        described at the beginning of this Section."

2) Citation Recommendation

To reduce the need to update the DLEP specification each
time that TLS specifications are updated, I recommend
specifying the TLS BCP guidance via the BCP reference, 
which is:

  [BCP195] “Recommendations for Secure Use of Transport
            Layer Security (TLS) and Datagram Transport
            Layer Security (DTLS)”, Y. Sheffer et alia.

Yours,

Ran Atkinson

---

From: Rick Taylor <[email-masked]>
Date: Mon, 13 Jul 2015 16:45:32 +0000

Thank you Ran,

That looks like very helpful text that would be easy to include.

The main reason we have not looked hard at the security aspects of DLEP 
is that although it uses multi-hop layer-3 protocols (UDP/TCP) DLEP 
itself is distinctly link-local and most frequently routers and modems 
will be physically adjacent.

However, you are right to point out that this is an assumption on our 
part, and passing IESG review is critical, hence TLS RECOMMENDED seems 
reasonable.

I don't agree that DTLS for UDP should be 'RECOMMENDED', I prefer 'MAY 
use'.  The reason being that UDP is used for multicast discovery (and 
I'm not sure how effective DTLS is for multicast without pre-placed 
keys).  The discovery packets leak no private information and simply 
point to a TCP endpoint that can be sufficiently secured.

Cheers,

Rick

On 13/07/15 16:49, RJ Atkinson wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 13 Jul 2015 19:14:25 +0200

> 1) Security implementation needs to be mandatory

I don't think that makes much sense for DLEP.

DLEP is not designed to be spoken over a large network, it is mostly
used over a short dedicated LAN cable between two boxes.

In some cases it might be even used over loopback, just to connect a
radio part with an integrated routing protocol.

>         RECOMMENDED to reduce security risks."

Does DTLS even work well for link-local multicast?

Henning Rogge

---

From: Frank Fitzek <[email-masked]>
Date: Mon, 13 Jul 2015 19:23:57 +0200

Dear all,

I am following your group for a while and I am often sitting in the back 
of your meetings. I am very much interested in MANETs. Especially 
multipath and coding strategies for MANETs are interesting for me.

I will come to Prague and will have some WIFI enabled Raspberry Pis with 
my that can do network coding. If anybody of you is interested in it, I 
am happy to share some knowledge about it. In case there is a short time 
slot in your agenda I could even introduce our project to the group.

Hope to see you in Prague

FF

-- 
Frank Fitzek
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 13:32:09 -0400

> On 13  Jul 2015, at 13:14 , Henning Rogge <[email-masked]> wrote:
> 

I do — more detail below.

> used over a short dedicated LAN cable between two boxes.

I agree that is the design concept.  However, since DLEP runs
over IP, DLEP can be used across multiple IP subnets.  Just as
importantly, DLEP can be attacked remotely from across multiple
subnets.

If the goal really is only to support link-local use, maybe
DLEP should run directly on top of Ethernet (i.e. not over IP).
ARP runs directly over Ethernet, so there is ample precedent.

If DLEP runs over IP, then it needs mandatory-to-implement
security.  The choice of TLS and a profile that is supported
by OpenSSL is designed to ease the implementer’s life.  TLS
is not perfect as it protects the TCP payload but not the TCP
header, but I think TLS will be sufficient to get past the IETF
Security Area review.

> radio part with an integrated routing protocol.

Sure.

This is one of the reasons that the IETF usually requires *implementation*
of security mechanisms, but does not require *operational use* 
of whatever security mechanisms it specifies.

Yours,

Ran

---

From: Dhafer Ben Arbia <[email-masked]>
Date: Mon, 13 Jul 2015 20:37:33 +0300

Dear Frank,

Thanks for your interesting proposal for sharing your precious knowledge
about MANETs coding and implementation.
Actually, I coded since a month OLSRv2 (RFC7181) on WSNet 3.0 Simulator.
But I'm looking forward to implement it (or enhance the existing
implementation) on Linux kernel (eventually on Raspberry Pi+Linux). Do you
plan to share your works on live conference, or by web streaming ?
Thanks.

*Best Regards*

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

*Dhafer BEN ARBIA, **Research Assistant , PhD student*

*M2M Platforms for Smart Living Technology Team*

<http://www.qmic.com/>

*Qatar Mobility Innovations Center - * *www.qmic.com* <http://www.qmic.com/>

PO Box 210531, Qatar Science and Technology Park *| *Doha, Qatar

<http://www.facebook.com/qmicqatar>[image: Description:
cid:90AC65B8-C5C3-4834-A662-E528D54DEBBE] <http://www.twitter.com/qmicqatar>

On Mon, Jul 13, 2015 at 8:23 PM, Frank Fitzek <[email-masked]>
wrote:

> of your meetings. I am very much interested in MANETs. Especially multipath
> and coding strategies for MANETs are interesting for me.
>
> my that can do network coding. If anybody of you is interested in it, I am
> happy to share some knowledge about it. In case there is a short time slot
> in your agenda I could even introduce our project to the group.
>

-- 

*Best Regards*

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

*Dhafer BEN ARBIA, **Research Assistant , PhD student*

*M2M Platforms for Smart Living Technology Team*

<http://www.qmic.com/>

*Qatar Mobility Innovations Center - * *www.qmic.com* <http://www.qmic.com/>

PO Box 210531, Qatar Science and Technology Park *| *Doha, Qatar

<http://www.facebook.com/qmicqatar>[image: Description:
cid:90AC65B8-C5C3-4834-A662-E528D54DEBBE] <http://www.twitter.com/qmicqatar>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 13 Jul 2015 19:41:53 +0200

> ARP runs directly over Ethernet, so there is ample precedent.

What would be about mandating (D)TLS for DLEP running NOT on linklocal
addresses (both for unicast and multicast)?

This should be a good compromise to keep embedded implementations
clean and small while allowing for secure multihop DLEP connections.

Most OpenWRT installations (which I normally use for the radio side of
DLEP based on embedded routers) don't even have a OpenSSL library
installed.

Henning Rogge

---

From: Shawn Jury <[email-masked]>
Date: Mon, 13 Jul 2015 13:43:52 -0400

Ran,

    I disagree with your assessment.  I’ve been looking into use cases for customers where the DLEP router and Radio are separated by a L3 device and cannot see how this would ever work.  At one point in time, there was an assumption in the DLEP draft that the radio must act like a transparent bridge.  This was because the DLEP router would be sending packets with the MAC address of the remote peer.  The radio would know which peer to forward the packet to by looking at the MAC address.  If you put a L3 device in between the two DLEP devices (router/radio), the MAC address is no longer relevant due to the L3 device rewriting the MAC destination and the radio can no longer use the MAC address to determine the destination.

BTW, the only reason the “transparent bridge” requirement was removed was so that we could have a remote device acting as a L3 device.

Going over anything other than a local subnet will completely break the protocol, so your concern of “because it uses IP, it will cross multiple subnets” is unjustified.  

Shawn

> On Jul 13, 2015, at 1:32 PM, RJ Atkinson <[email-masked]> wrote:
>

---

From: Frank Fitzek <[email-masked]>
Date: Mon, 13 Jul 2015 20:07:50 +0200

Hi,

I will tavel to prague and will have some nodes with me. We are using 
the KODO-Python environment (check github).
Currently we have some nice results showing that coding helps to reduce 
number of packets to send and it reduces the delay. It would greatly 
benefit from multipath though. So looking ofrward for multipath routing 
schemes.

FF

Am 13.07.2015 um 19:37 schrieb Dhafer Ben Arbia:
> Dear Frank,
>
> Thanks for your interesting proposal for sharing your precious 
> knowledge about MANETs coding and implementation.
> Actually, I coded since a month OLSRv2 (RFC7181) on WSNet 3.0 
> Simulator. But I'm looking forward to implement it (or enhance the 
> existing implementation) on Linux kernel (eventually on Raspberry 
> Pi+Linux). Do you plan to share your works on live conference, or by 
> web streaming ?
> Thanks.
>
> /*Best Regards*/**
>
> *Qatar Mobility Innovations Center - **www.qmic.com* 
> <http://www.qmic.com/>
>
> <http://www.facebook.com/qmicqatar>Description: 
> cid:90AC65B8-C5C3-4834-A662-E528D54DEBBE 
> <http://www.twitter.com/qmicqatar>Description: 
> cid:24741D7C-30C5-4E66-BDAE-35BFADE4A9E4
>
>
>
> On Mon, Jul 13, 2015 at 8:23 PM, Frank Fitzek 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     I am following your group for a while and I am often sitting in
>     the back of your meetings. I am very much interested in MANETs.
>     Especially multipath and coding strategies for MANETs are
>     interesting for me.
>
>     I will come to Prague and will have some WIFI enabled Raspberry
>     Pis with my that can do network coding. If anybody of you is
>     interested in it, I am happy to share some knowledge about it. In
>     case there is a short time slot in your agenda I could even
>     introduce our project to the group.
>
>     phone: +49 351 463 33945 <tel:%2B49%20351%20463%2033945>
>     fax: +49 351 463 37163 <tel:%2B49%20351%20463%2037163>
>     mobile: +49 173 548 2947 <tel:%2B49%20173%20548%202947>
>     web: www.fitzek.net <http://www.fitzek.net>
>     skype:  fitzek
>
>     [email-masked] <mailto:[email-masked]>
> /*Best Regards*/**
> *Qatar Mobility Innovations Center - **www.qmic.com* 
> <http://www.qmic.com/>
>
> <http://www.facebook.com/qmicqatar>Description: 
> cid:90AC65B8-C5C3-4834-A662-E528D54DEBBE 
> <http://www.twitter.com/qmicqatar>Description: 
> cid:24741D7C-30C5-4E66-BDAE-35BFADE4A9E4
>

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 14:20:46 -0400

> On 13  Jul 2015, at 13:43 , Shawn Jury <[email-masked]> wrote:
> 
> Ran,
> 

That is a great paragraph.  Quite honestly, some of that text would
be helpful as introductory text in the DLEP specification, but note
well that all the discussion above is about the data path, not about 
the DLEP control path.

> BTW, the only reason the “transparent bridge” requirement was removed
> was so that we could have a remote device acting as a L3 device.

(I know of at least some remote devices that could be
acting as an L3 device, although most devices I can think
of are likely to act as a kind of L2 device. :-)

> Going over anything other than a local subnet will completely
> break the protocol,

Going over anything but link-local might break the data path, 
but going over multiple IP subnets does not break the control path 
(which is a TCP/IP session).  

Also, it is important to realize that in many environments 
a single IP subnet has a very wide area presence.  To support
wide-area VM migration, the IETF has standardized various ways 
of L2 tunneling between and among geographically distant locations.

While many of us believe that the common deployment is likely
to involve a single Ethernet cable connecting port N of an
IP router to some port on a IP/Ethernet-capable radio, the
protocol would work just fine with an IP router in one location
connected via a L2 tunnel to a different location.  Depending
on whether one believes that SDN will be widely deployed, that
remote connection (still single IP subnet) could become a common 
deployment scenario at some future point.

Moreover, even if the intentional TCP/IP session runs over a single 
IP subnet, which is what I think most folks anticipate, that session 
still is subject to attack from any IP connected path (just like any 
other TCP/IP session is subject to remote attack).

> so your concern of “because it uses IP, it will cross multiple subnets”
> is unjustified.  

My concern is about protecting the control path.  Please see the
discussion above about why the L2 data path constraint doesn’t apply
to the control path.

More generally, the IETF is often concerned about authenticating
control protocols (like DLEP/TCP/IP) - even when the actual user data 
being sent (via L2 Ethernet in this case) is not being protected.

My personal preference would be for an authentication-only solution,
because I don’t think that DLEP control traffic needs confidentiality,
but the TLS community seems opposed to authentication-only approaches
and TLS seems simpler to implement than any obvious IETF alternatives.

If no security approach is mandated for implementations, users won’t
be able to obtain and deploy interoperable security in the environments 
that need it.  By not mandating use of security, users in environments
where security is not desired/needed don’t have to use security.

Cheers,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 14:40:42 -0400

> On 13  Jul 2015, at 13:41 , Henning Rogge <[email-masked]> wrote:
> 

I do not fully understand what you are suggesting above.

My own concern, and what I think will be the security community’s
main concern, is with protecting the DLEP control protocol(s).

If users want data confidentiality for user data, then those users
really ought to use some end-to-end security mechanism (e.g. host
to host IPsec, TLS, DTLS) for their user data IP flows.

In any case, the proposed text is clear that users could chose
not to enable (D)TLS in their own deployment(s).  

> Most OpenWRT installations (which I normally use for the radio side
> of DLEP based on embedded routers) don't even have a OpenSSL library
> installed.

OpenSSL already is designed to be used in embedded systems 
with limited memory and limited CPU.  I believe my (now very
old) iPod Touch with a slower ARM CPU and limited RAM uses
OpenSSL, for example.

According to this URL from April 2014, OpenWRT already supports 
a reasonably modern version of OpenSSL, and some people clearly
are using it with their OpenWRT systems, so it should work fine
and you ought not need to do a port of OpenSSL:

"https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/024749.html"

Yours,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Mon, 13 Jul 2015 20:49:41 +0200

> I do not fully understand what you are suggesting above.

I am suggesting that (D)TLS capability is not mandatory for a DLEP
radio/router implementation that directly binds to a linklocal
address.

Which means it cannot be contacted by a far-away IP network.

> and you ought not need to do a port of OpenSSL:

Yes, OpenWRT had openssl packages for ages... but most embedded
routers don't install them because they are quite large. When you have
4 or 8 MB of flash for your operation system you start cutting away
unnecessary things.

SSH is normally done by "dropbear", a very small SSH server with a
statically linked libtomcrypt.

I would prefer to have a standard compliant DLEP implementation that
can work without importing something like libopenssl.

Henning

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 13 Jul 2015 15:26:37 -0400

> On 13  Jul 2015, at 14:49 , Henning Rogge <[email-masked]> wrote:
> 

I can see 2 approaches to that goal.

1) Opt-Out for Implementations that limit themselves to 
   non-routable IP addresses.

If that were what the WG-as-a-whole decided, one could add-in
a sentence like this into the draft candidate “Security 
Considerations” text:

  “DLEP implementations that ONLY are capable of communicating using
   non-routable Link-local IP addresses (e.g. 169.254/16 for IPv4;
   for IPv6), and are NOT capable of ever binding to a routable IP
   address (e.g. 10.0/8) are not required to implement support 
   for TLS or DTLS.”

2) General prohibition on using DLEP with routable IP addresses

However, if the WG-as-a-whole were comfortable with limitation (1), 
above, then maybe the WG-as-a-whole would be comfortable with requiring 
that limitation very broadly in all cases, but that would mean adding 
multiple “MUST ONLY” and “MUST NOT” items to the DLEP-15++ 
specification document.

A proposed new Section 1.3 "IP Addressing with DLEP”
would contain:

	“DLEP is designed and intended only for use within a
	single IP subnetwork.  (** Add more text here — possibly 
        along the lines of the note from Shawn Jury from earlier
        today, noting the data path limitation as well. **)

	“For security reasons, DLEP implementations MUST NOT support 
	or ever use routable IP addresses.  DLEP implementations 
	MUST ONLY support and use non-routable link-local unicast 
	IP addresses (e.g. 169.254/16 for IPv4; FE80::/10) for all 
	DLEP/TCP/IP sessions.  DLEP implementations MUST ONLY support 
        and use non-routable link-local unicast IP addresses or 
        non-routable link-local multicast IP addresses for all
        DLEP/UDP/IP sessions.”

Then, for consistency with the above, at least Sections 9.8 and 9.9 
also would need to be updated with “MUST NOT SEND” and “MUST IGNORE
IF RECEIVED” language for the case where an IP Address Data Item 
for a (real or would-be) DLEP Peer contained a routable IP address.
(It is possible that some other sections also would need to have 
these new IP address constraints documented; I’m not sure.)

I believe that if all of the above were accepted by the WG-as-a-whole,
then it would be reasonable to change the proposed requirement for 
(D)TLS from “MUST” to “SHOULD”.  

If approach (2) were adopted by the WG-as-a-whole, then the "Security
Considerations" should document the constraint against routable
IP addresses as being created in part to reduce operational security
risks.  

(In general, a complete and clearly written "Security Considerations”
section has the best chance of getting past the IETF Security Area
review with the least delay.)

Yours,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Mon, 13 Jul 2015 21:38:10 +0200

>    address (e.g. 10.0/8) are not required to implement support

I could work with this...

the reason I want to push for "no tls" is that I like the idea of a
DLEP radio that does not need to be configured.

Just use stateless IPv6 autoconfiguration and bind all local services
(including DLEP) to the IPv6 linklocal IP. Then use the DLEP discovery
mechanism to make the router aware of the radio... at this point the
router pushes a configuration to the radio and starts using it. This
makes maintenance of multi-radio MANET nodes much easier.

>         or ever use routable IP addresses.

there is a "for the DLEP control traffic".

>  DLEP implementations

I think you are mixing up the "IPv4/IPv6 Connection Point" TLV and the
"IP Address/Subnet" TLV.

The first delivers the DLEP control socket, so it would be restricted.
The second one is about announcing router IPs (routable) to the radio,
so the radio can send them (via some part of its wireless protocol) to
the other side and then via DLEP to the other router.

Henning Rogge

---

From: Jiazi YI <[email-masked]>
Date: Wed, 15 Jul 2015 15:44:46 +0200

Hi Frank,

As I said before, I'm very interested in the multipath routing with the
network coding strategy.
Unfortunately, I won't be able to be at Prague. If you are going to make a
presentation in MANET WG, I would surely join remotely.

regards

Jiazi

---

From: Frank Fitzek <[email-masked]>
Date: Wed, 15 Jul 2015 16:02:22 +0200

Cool! Did not hear back from the other people in the group whether thy 
are interested in the topic. If so I can do a short introduction to the 
topic.
FF

Am 15.07.2015 um 15:44 schrieb Jiazi YI:
> Hi Frank,
>
> As I said before, I'm very interested in the multipath routing with 
> the network coding strategy.
> Unfortunately, I won't be able to be at Prague. If you are going to 
> make a presentation in MANET WG, I would surely join remotely.
>
> regards
>
> Jiazi
>
> On Mon, Jul 13, 2015 at 7:23 PM, Frank Fitzek 

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

---

From: John Dowdell <[email-masked]>
Date: Wed, 15 Jul 2015 16:14:48 +0100

Frank

I'd be interested. If there is no time in the WG meeting we can always 
have a huddle wherever the lounge is this time.

Regards
John

On 15/07/15 15:02, Frank Fitzek wrote:
> are interested in the topic. If so I can do a short introduction to 
> the topic.
> FF
>
>
> web:www.fitzek.net