On 02-Sep-20 15:22, Michael Richardson wrote:
>
> Fries, Steffen <[email protected]> wrote:
> >> -----Original Message-----
> >> From: Michael Richardson <[email protected]>
> >> Sent: Freitag, 28. August 2020 20:32
> >> > Maybe I phrased it wrong. The intention is not to make the pledge
> more
> >> > complex. The goal should be to keep the pledge simple and enhance the
> >> > registrar to handle also other situations like unavailability of
> >> > certain connections. The registrar should be the more capable
> >> > component. The discovery was intended in situations, in which the
> >> > registrar supports multipole options, but not all may be mandatory
> >> > supported. In this case the discovery would help. Otherwise the
> pledge
> >> > may do trial and error.
> >>
> >> While I appreciate the idea of having the pledge fail faster, and go
> onto to
> >> the next possible registrar, I think that the pledge should support
> one and
> >> only one mechanism, and it's up to the registrars to keep up.
>
> > Yes, this keeps the pledge simple, but would require the registrar to
> > implement the other options mandatorily.
>
> *A* Registrar has to implement the right options.
> There could be more than one system with the same CA behind them.
> I way prefer to just let the pledge implement one thing.
>
> Maybe that will cause significant bifurcation in the BRSKI-capable thing
> market, but I suspect that most registrars will implement it all.
>
> >> If we are doing proper ACP ANIMA, then we can include the enrollment
> >> options for the Registrar into the GRASP DULL announcement, and this
> can
> >> inform the pledge's decision as to which Registrar to pick.
>
> > This would also be an option for a discovery, but I have to dig deeper
> into GRASP.
>
> okay.
Let me know if you want to try to specify that. At the moment the only defined
value for the "AN_join_registrar" objective is the string "EST-TLS", but we
could trivially extend it to define another method, or a set of methods.
Also the syntax already allows for multiple announcements in one M_FLOOD
message, so I'd be surprised if we can't do whatever you want. (I had demo
code for announcing a set of methods a long time ago, but I actually
simplified it to only announce "EST-TLS" as BRSKI converged.)
Brian
>
> >> I don't yet understand how the voucher-request is done in async BRSKI.
>
> > I realize more an more that a pure "request-object" without considering
> > the transport is probably too abstract. Implementing requires also the
> > transport.
>
> Yes, okay, I thought that this was in scope for this document.
> Or, when I agreed to adopt, I thought that.
>
> I have quite a few ideas on how to do this: we really ran through them all
> during BRSKI/6tisch-zero-touch/SZTP and we settled on a compromise.
>
> >> I thought that was what we were doing.. I have many ideas about this.
>
> > Yes, voucher-request and also certification-request would be collected
> > by the pledge-agent. Good to hear you have ideas here, as we need to
> > define the approach more precisely.
>
> >> > Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge
> would
> >> > be queried by the pledge-agent for certain objects. It was intended
> to
> >>
> >> But, how is it queried?
>
> > The pledge essentially must be able to listen for the request. In
> > industrial environments the embedded device is most often in a server
> > role waiting for requests. This would have to be leveraged also for the
> > PUSH interaction.
>
> Cool.
> I can also see BT and NFC being used for the push.
>
> >> Well, I thought that the furnace in the basement where there is no
> >> connectivity was a really good use case.
> >> The furnace installer has a smartphone or dedicated comissioning
> >device.
>
> > This was one of the point I concluded form the last meeting. The trust
> > assumptions about the pledge and pledge-agent interaction is one of the
> > points to be discussed further.
>
> Good.
>
> >> As for HTTP: I would tend to suggest that we should use CoAP.
> >> This works over WIFI as well as other technologies, and convergence
> here
> >> would be good.
>
> > Which may bring it closer to the constraint voucher than BRSKI. I was
> > looking for the latter, hence HTTP as proposal. But this is open for
> > discussion.
>
> :-)
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
