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

On Mon, 14 Sep 2020 at 04:30, Martin Thomson <mt@lowentropy.net> wrote:

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

Growing number of home routers today support easy update of config and
software, for example routers run RDK software (https://rdkcentral.com/) to
ease config/software update, support LxC container environment to run
network security services.  They can update configs & software on devices
with fine-grained control (controlled release, A/B test, roll fwd/back,
etc.) and with whatever frequency of update is necessary. In short, both
types of router exist in the field.

-Tiru

>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>