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

[Henning Rogge <[e-mail]>]

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