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

[peter van der Stok <[e-mail]>]

Hi Richard,

Thanks for the joinrouter document. It has certainly contributed to my 
understanding.

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 will use the term managed network throughout, 
principally mapped from the building control network that I know best.

A managed network has at least two interested parties for its 
management: (1) the network administrator as described in 
anima-reference-model, and (2) the provider of the managed network 
functions. These two co-exist to-day, but with the progressive movement 
from special purpose “proprietary” network standards (like BACnet) 
connected via gateways to Internet towards flat full IP networks, their 
relation changes. Both have a responsibility for the correct functioning 
of these networks, where managed network functions may (should) rely on 
the IP infra-structure managed by the administrator.

Contrary to the view expressed in anima-reference-model, the devices 
which constitute a managed network share a standardized IP stack. This 
stack standardizes the routing protocol, the discovery protocol, use of 
DNS. Also contrary to the view of anima-reference-model, the 
installation of the services running on the managed network may be 
facilitated by a human installer which specifies the names of services 
and devices, and establishes the secure relation between clients and 
servers.

In my opinion, it is beneficial when there is a common automated 
bootstrapping standard that is acceptable to the network administrator 
and the provider of the managed network. The advantage for the provider 
of the managed network is that there is a shared understanding of a 
correctly functioning network on top of which the managed network 
services can be installed. The advantage for the administrator is that 
he exerts some minimal control over the network.

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.

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?

Hope this helps,

Peter



Michael Richardson schreef op 2016-01-17 05:36:
> I finished writing:
>   
> https://tools.ietf.org/html/draft-richardson-anima-state-for-joinrouter-00
> 
> (I had another draft name, but it turns outs there is a 50 character 
> limit on
> draft names)
> 
> Abstract:
>    This document explores a number of issues affecting the decision to
>    use a stateful or stateless forwarding mechanism by the join router
>    (aka join assistant) during the bootstrap process for ANIMA.
> 
> 
> I have 6 possible technologies that the joining router could use.
> They fall into three categories from the point of view of the new node:
> 1) HTTPS
> 2) HTTPS via http-proxy
> 3) CoAP/DTLS.
> 
> 1&2 could be unified if the registar is willing to accept an HTTP 
> CONNECT
> command via HTTP (and always connect to itself), and then do HTTPS.
> 
> I realize that I did not describe a method 7, which is a circuit/NAT
> method for CoAP.
> 
> The Joining Router/Registrar interface is possibly agnostic about HTTPS 
> vs
> CoAPS for the IPIP methods.
> 
> From the new node point of view, if we were to make CoAPS mandator to 
> implement
> on the joining router, and HTTP optional that would make the IoT space 
> work
> best.
> 
> On the registrar<->Joining Router point of view, one could make either 
> IPIP
> or circuit proxy MTI.  The IPIP method is more difficult to implement 
> on the
> registrar, so some might argue for making it optional; but really it's 
> about
> simplifying the Joining Router.
> The IPIP mechanisms are already required in the RPL space, and Pascal 
> and 6lo
> are working at ways to compress the IPIP header already.
> 
> It's possible to seperate the IPIP decapsulation from the registrar, 
> but a
> bit messy. If one terminates the DTLS/TLS on the IPIP decapsulator, 
> it's much
> easier, and that would be something one would do if one had to scale 
> the
> registrar beyond a single machine.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap