Subject: [manet] DLEP-17: Section 5.1, security concern

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 11:24:07 -0500

In Section 5.1, top of page 13, this sentence exists:
	The modem MUST accept a TCP connection on only one (1)
        address/port combination per session.

A quick reading of this yields confusion.  

On the surface, it appears to say that the modem can ONLY have 
1 peer at a time.  If correct, then an off-link attacker could 
deny service to a legitimate router by opening a DLEP session
with the modem (while pretending to be a legitimate router).

If the paragraph above is a correct description, then this
security vulnerability needs to be clearly disclosed in the
Security Considerations section of this I-D.  One imagines
that using TLS with both client-certificate and server-certificate
for endpoint identity authentication would be a RECOMMENDATION
for situations where the threat environment included either
off-link or on-link attackers.

Maybe the quoted text means something else ?
If that is the case, please rephrase it for clarity.

Thanks,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 17:39:53 +0100

>         address/port combination per session.

"per session"...

so its more a matter if "multiple sessions on the same radio" makes
sense. If the radio only implements "pushing metrics to the router" it
could easily handle multiple sessions. If you want to do "request link
characteristics or even flow control", only a single session makes
sense.

> with the modem (while pretending to be a legitimate router).

off-link would mean TLS... because linklocal IP traffic is not
forwarded between the off-link attacker and the DLEP instance.

> off-link or on-link attackers.

If you have an on-link attacker you have lost anyways... because the
attacker already controls the data-plane.

Unless you use something like 802.1x, which would keep the link safe
(both data and control plane).

I still stand with my suggesting making linklocal IPs mandatory for
DLEP and drop all the TLS stuff... if someone wants to deploy a
layer-2 VPN, he/she can also deal with the necessary security for the
VPN.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 24 Nov 2015 11:44:37 -0500

> characteristics or even flow control", only a single session makes

The intent of the text is to say "one session per radio, per interface." If
the radio wants to establish 3 sessions, each on a separate VLAN for
example, that's fine. But not multiple sessions on the same interface.

We'll make an attempt to clarify.

Regards,
Stan

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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:29:10 -0500

> On 24  Nov 2015, at 11:39 , Henning Rogge <[email-masked]> wrote:
> 

If that is the consensus, then please edit the draft to capture
the thought above.

> forwarded between the off-link attacker and the DLEP instance.

TLS doesn’t prevent a DOS attack such as this.  Also, TLS *use*
for off-link sessions is an operational decision by the network
operator (at least at present).  If folks want to require that
TLS be *used* for any off-link DLEP session, I’m ok with that,
but that isn’t what the current draft seems to say.

> attacker already controls the data-plane.

Maybe, but maybe not.  It depends on what “on-link” really means.

In a big yellow coaxial cable Ethernet, an on-link attacker could
jam all traffic.  Where the on-link attacker is connected to the
victim via an Ethernet switch, then there are various limitations
in what such an attacker could do.  Some of those limitations
vary with 802.1x, MACsec, and switch implementation-specific 
features (e.g. MAC address filtering/lockdown).

> (both data and control plane).

I’d suggest also using MACsec or similar link encryption.
RFCs can suggest using 802.1x as a mitigation, by the way.

> layer-2 VPN, he/she can also deal with the necessary security for the

I’m ok with that, but its a change from the current specification,
and there still would need to be discussion of the new threats
that using an L2 VPN would bring.  It is possible that the IETF
Security Area would consider that sufficient, but I’m not certain.

IPv4 unicast link-local addressing does exist already, by the way.

Yours,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 19:38:16 +0100

> RFCs can suggest using 802.1x as a mitigation, by the way.

either ways the problem to secure a single link has already been
worked on in a generic way.

if your deployment is a dedicated ethernet card on the Router
connected with a cable direct to the router you could skip all
security.

if you do it with a manageable switch, you can deploy VLAN, 802.1x
and/or MACsec... depending on your switch and security needs.

> Security Area would consider that sufficient, but I’m not certain.

Again, the advantage would be that a lot of security issues of a L2
VPN have already been talked about in other WGs... it would make it
unnecessary to re-invent the wheel for DLEP.

Henning Rogge

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 24 Nov 2015 13:55:56 -0500

> On 24  Nov 2015, at 13:38 , Henning Rogge <[email-masked]> wrote:
> 

Yes.

> connected with a cable direct to the router you could skip all

Yes.

> and/or MACsec... depending on your switch and security needs.

Yes, although the candidate mitigations would need to be documented
in DLEP’s Security Considerations, probably including informative
references to the appropriate IEEE 802 standards.

> unnecessary to re-invent the wheel for DLEP.

Yes

I believe that the Layer-2/on-link security issues need to be documented.
I think most of the relevant security standards for layer-2 were done
in IEEE, which one could simply cite as mitigations for the operator
to consider using.  

Cheers,

Ran

---

From: Henning Rogge <[email-masked]>
Date: Tue, 24 Nov 2015 20:00:19 +0100

> references to the appropriate IEEE 802 standards.

Yes...

> in IEEE, which one could simply cite as mitigations for the operator

Yes... but that sounds like a lot LESS complexity than all the things
we have to consider by moving to TLS...

I am worried about things like "Certificate livetimes" or "Certificate
revocation" too... and interesting problems when DLEP implementations
only provide a limited set of cyphers/hashes.

Henning Rogge