Re: [Anima-bootstrap] joiner router stateful/stateless considerations

[Michael Richardson <[e-mail]>]

peter van der Stok <[e-mail]> wrote:
    > Hi Richard,

{Michael :-)}

    > To clarify how far we are aligned, I like to describe my view on the managed
    > (and “constrained”) network. After that I do have a suggestion and a
    > question.

I think that I missed the suggestion, maybe it's in here:

    > Once this view is accepted, there are some complicating aspects for the anima
    > bootstrapping process. There is the “managed network” part with the
    > standardized stack without ASAs - possibly using DTLS with CoAP-,
    > and there is the more complex Internet with ASAs - probably using http with
    > TLS-. If it is reasonable to include the “managed network” devices into the
    > anima bootstrapping process, I **SUGGEST** that the anima bootstrapping services
    > both types of networks. That may mean that 2 solutions from the ones proposed
    > in joinrouter document are chosen.

Which two solutions would you pick?

From the new node to joining router, we have three options:
     A) CoAP/DTLS, B) HTTPS, C) HTTPS over HTTP proxy.

I prefer (A) as MTI, with (C) as MAY.
From the joining router to the registrar, I prefer method 6, CoAP/DTLS with
IPIP tunnel.  I think that this works the best in a constrained network,
where I do not expect to see an ACP.

At the edge of the contrained network, the 6LBR might have an ACP, and would
further route the join the traffic that way.  The IPIP header might be
addressed to the 6LBR, and re-encapsulated by the 6LBR as well, but that
would involve some state (methods 1 or 2) on the 6LBR: That may be acceptable.

I'm trying also to build a system that could also be initiated from the
registrar to new node direction, as I've proposed in 6tisch.

    > Having written that, my question concerns figure 1 of keyinfra draft. Two
    > arrows are shown between new entity and Proxy with L2 and L3. I understand
    > that this means that payloads are encoded at L2 or at L3. I am not sure that
    > I understand how this works, because L2 security provisioning between for
    > example 802.11 and 802.15.4 devices is different. Maintaining both the L2 and
    > L3 option means that the security levels need to be aligned between the
    > different link technologies and layer 3 technologies. That looks like an
    > addition to the IP over foo documents. Is that correct?

I think that the point is that we don't know (in this document, at this
stage) precisely if the new node and proxy communicate at layer 2 (e.g. 802.1x)
or layer 3 (PANA, CoAP/HTTP, etc.).  That's why it says "or"

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-