Re: [Add] [EXTERNAL] My single use case

[Martin Thomson <[e-mail]>]

On Sat, Sep 12, 2020, at 06:34, Tommy Jensen wrote:
> My concern is 2) encompasses more use cases than 1). 1) is limited to 
> the use case of joining a network and needing a recommendation. 2) 
> includes other channels of address acquisition such as offline endpoint 
> configuration. I can accept feature parity for 1) which is no 
> authentication. I can possibly accept lower security for 2) when the 
> address came from network advertisement such as DHCP which isn't secure 
> today, but not when it came from endpoint configuration which may be 
> secured. 

This is a good summary of this situation.  I share those reservations also, but would add that even in cases where the discovery is not cryptographically authenticated, that doesn't mean it isn't protected somehow, so the second case (talk to the resolver or something akin to that) increases exposure to attacks even when configuration isn't authenticated sometimes.  So you have:

2a) unsecured discovery/configuration
2b) discovery/configuration secured by means that is not apparent (e.g., at layers 1 or 2)
2c) discovery/configuration secured cryptographically (and thus known to the endpoint)

The former two are indistinguishable to the client; the latter two are cases you might want a different policy for.

In the end, this is a subjective decision that might be made in client policy, so our responsibility is to identity the scenario and document the consequences, not necessarily decide it.  The reason I think that this remains in scope is the forwarder case.  This is so common a deployment topology.  And, as those devices are a mix of hard to upgrade or unmaintained, finding some way to route around them seems to be important.