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

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

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

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 <[e-mail]> 
Sent: Thursday, December 2, 2021 1:39 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 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