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

["Black, David" <[e-mail]>]

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 <[e-mail]> 
Sent: Thursday, November 25, 2021 2:21 AM
To: Black, David
Cc: [e-mail]; [e-mail]; 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
<[e-mail]> 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