Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> So there are several separate questions here.
> 1. I understood Toerless to be arguing that the registrar may need to be
> contacted again some considerable time after the bootstrap (i.e. join)
> action, specifically for what he called EST-renew.
> Is that agreed?
Yes, but once on the ACP, a node has many different ways to find a renewal
Registrar. Where that system is could be found via a number of other ways.
> 2. If yes, would that need a new discovery action?
> I assume the answer is yes, since we want to be reasonably
> stateless and not assume that we can cache the registrar's address
> and port indefinitely.
Yes.
> 3. If so, do we want to re-use the same objective (AN_join_registrar
> for the sake of argument)?
No, because:
a) The join registrar might not support renewal or other complex
EST methods. This might be to avoid providing unnecessary attack surfaces.
b) The join registrar may be provisioned for the join process.
It might be turned off (or scaled down) when there are no nodes expected
to join.
> 4. In any case, do we want to make this objective or objectives
> highly extensible (which basically means using CBOR maps instead
> of simple CBOR arrays)? This has the usual pros and cons:
> highly extensible = more complex parsing.
I don't want to do that.
> Although we currently require that GRASP
> runs over an ACP, there is nothing magic about that. I don't see that
> BRSKI actually depends on the ACP either; both would surely run over
> bare metal if we told them to (and the Security ADs weren't watching).
Agreed.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
