Owen Friel (ofriel) <ofriel@xxxxxxxxx> wrote:
> Late feedback, but its ambiguous in the draft how vendor default Cloud
> Registrar
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-2.7
> and redirects as described in
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.6
> should interact.
> Should the cloud registrar redirect immediately in response to the
> voucher request, so that the pledge then sends the voucher request via
> a local domain RA?
The cloud registrar concept is not intended to be a normative part of BRSKI.
We went through a bunch of text to try to make that clear, but maybe we have
still failed.
We are simply saying that a pledge MAY do something else, such as direct EST
back to the manufacturer, and you are astute to realize that the manufacturer
might redirect to the customer's Internet visible Registrar.
Please feel free to start a document that explains this, as I have this as
part of a back of the envelope design as well. We think it's a large ocean,
and we think that NETMOD ZERO TOUCH has some really good ideas here too.
We are also trying to keep the door open to completely autonomous networks,
where even the Registrar bootstraps itself:
draft> In such a future situation, the device might use this
draft> management interface to learn that it should configure itself to
draft> become the local registrar.
As such, I think that your questions and feedback are "future work"
5.6 has the text:
draft> In order to avoid infinite redirect loops, which a malicious
draft> registrar might do in order to keep the pledge from discovering the
draft> correct registrar, the pledge MUST NOT follow more than one
draft> redirection (3xx code) to another web origins. EST supports
draft> redirection but requires user input; this change allows the pledge to
draft> follow a single redirection without a user interaction.
We had to say something about redirection, because EST supports it.
We decided that we would permit a single redirection, but we did not
have a definite operational reason for this, we just felt it was important.
In most cases, the pledge connects to the Registrar using a proxy,
so the pledge actually cannot decide to connect elsewhere. It always
connects through the proxy, and the proxy does not interpret the URL.
So, the only useful redirection that makes sense is to a different
URL and/or virtual Host: on the same end point. This might be done
for reasons of load balancing, or to leverage the EST domain concept.
We did not want to predict or proscribe something here, just to make
the pledge did not get into an infinite redirect loop, yet still permit 3xx
codes to be useful in the future.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature
