Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09

From: "Black, David" <[email-masked]>
Date: Thu, 2 Dec 2021 03:55:14 +0000

Henning,

> I disagree with the security concerns...

To be more precise, I think the disagreement is not with the concerns, but is rather with how to address them, as your note suggests countermeasures.

These drafts create a resource (credits) which can be attacked (e.g., via message injection) where successful attacks can cause harm (e.g., reduction or denial of service).  That is a security concern that needs to be addressed.

Your discussion of what to do to prevent these attacks, e.g., " if the physical link between router and radio is not secure (e.g. a single ethernet cable), the DLEP connection should be secured," would be fine Security Considerations text to add in order to address this concern.  In contrast, the current Security Considerations text asserts the non-existence and impossibility of these attacks (even in the absence of countermeasures such as securing the DLEP connection) - that is not correct, so that text needs attention.

Thanks, --David

-----Original Message-----
From: Henning Rogge <[email-masked]> 
Sent: Thursday, November 25, 2021 2:21 AM
To: Black, David
Cc: [email-masked]; [email-masked]; MANET IETF
Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09

[EXTERNAL EMAIL] 

On Fri, Nov 19, 2021 at 6:02 PM David Black via Datatracker
<[email-masked]> wrote:
> -- [6] -- Security Considerations
>
> Although this is a Transport review, I found a security issue that would be
> better dealt with now before the security directorate points it out ;-) - the
> security considerations sections in each of the 3 drafts claims that adding
> credit window control and flow functionality to DLEP does not introduce any new
> security considerations (vulnerabilities). That's a nice try, but it's
> incorrect.
>
> These drafts specify a new resource (credits in a credit window) that is
> subject to resource exhaustion attacks that could cause denial-of-service.  For
> example, suppose an attacker injects a Credit Window Initialization data item
> that contains almost no credits and/or specifies a ridiculously tiny Window
> (Max) Size.  I expect that the protocol contains mechanisms to counter this and
> related attacks on credit resources (e.g., if something looks wrong, the modem
> reinitializes the Credit Window), but the current text incorrectly asserts the
> non-existence of such attacks.  These sorts of attacks definitely exist - I am
> aware of a (subsequently fixed) resource exhaustion problem in another
> credit-based flow control mechanism caused by an unanticipated environmental
> "attack" on signal integrity of credit exchange messages, resulting in message
> discard and credit loss.

I disagree with the security concerns... if the physical link between
router and radio is not secure (e.g. a single ethernet cable), the
DLEP connection should be secured... either by securing the link (e.g.
802.1x or MacSec) or by TLS (which would leave the DATA unprotected!).

If the router itself is not secure, exhausting the radio resources
should be a non-issue... you could just block the radio with more
traffic.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 2 Dec 2021 07:38:57 +0100

> These drafts create a resource (credits) which can be attacked (e.g., via message injection) where successful attacks can cause harm (e.g., reduction or denial of service).  That is a security conc…

We already have these kinds of problems (exhaustion of resources) for
Attached Subnets and Announced Destinations.

But in all of these cases the attack is only possible if you CAN
inject messages.

> Your discussion of what to do to prevent these attacks, e.g., " if the physical link between router and radio is not secure (e.g. a single ethernet cable), the DLEP connection should be secured," w…

I think we already have a discussion about this in RFC 8175 Section
7.1 and 14. In fact this WG had a lengthy discussion among each other
and the Security Area Director about security.

I would like to know what kind of attacker you imagine that has not either
a) full control about the router end of DLEP
or
b) exploits a DLEP connection that is not following the security
advice of RFC 8175 (either using TLS or securing the layer 2 link).

The RFC 8175 already strongly recommends the use of TLS for DLEP,
unless the installation can guarantee a secure link (e.g. a direct
ethernet cable without a switch).

In my opinion discussions about how to secure the DLEP link doesn't
belong in a specific extension document, but maybe an informal "DLEP
security best practice" one. This could discuss the pros and cons
about "direct link", TLS, 802.1x, MACSEC or VPN to connect DLEP radio
and router. All these things are common to all applications of DLEP.

Henning Rogge

---

From: "Black, David" <[email-masked]>
Date: Thu, 2 Dec 2021 16:43:25 +0000

> and the Security Area Director about security.

That's fine - adding Security Considerations text that refers to those techniques and indicates that they suffice to protect the credit resource ought to suffice.  I'm not looking for new functionality - I'm objecting to wording that ignores the security implications of credits.

> I would like to know what kind of attacker you imagine

This is not about a new kind of attacker - it's about text in the draft that asserts that credits cannot possibly be attacked, even if nothing is done about securing DLEP:

   These mechanisms do not inherently introduce any additional
   vulnerabilities above those documented in [RFC8175].

That sentence is incorrect because I've already described a vulnerability introduced by credits, but RFC 8175 does not discuss credits, and hence RFC 8175 has not "documented" that vulnerability.

Rewriting that sentence and related text to indicate that the security functionality and considerations in RFC 8175 apply to the new mechanisms is likely to suffice.  

Thanks, --David

-----Original Message-----
From: Henning Rogge <[email-masked]> 
Sent: Thursday, December 2, 2021 1:39 AM
To: Black, David
Cc: [email-masked]; [email-masked]; MANET IETF
Subject: Re: [manet] Tsvart early review of draft-ietf-manet-dlep-credit-flow-control-09

[EXTERNAL EMAIL] 

Henning Rogge