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

[Henning Rogge <[e-mail]>]

On Thu, Dec 2, 2021 at 4:55 AM Black, David <[e-mail]> wrote:
>
> 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.

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," 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.

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