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

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Jan 2016 23:36:38 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: peter van der Stok <[email-masked]>
Date: Tue, 19 Jan 2016 12:13:22 +0100

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:
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 11:04:01 -0500

> 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"

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jan 2016 08:09:55 +1300

Hi Peter,

On 20/01/2016 00:13, peter van der Stok wrote:
...
> There is the “managed network” part with the standardized stack without ASAs - possibly using DTLS with CoAP-, 

Then it's not part of Anima. But I don't understand why you make the assumption "without ASAs".
Or do you just mean "without needing an ASA and GRASP during bootstrap"?

...
> and there is the more complex Internet with ASAs - probably using http with TLS-

I assume you mean using https for bootstrap, since ASAs use GRASP over
the ACP (or possibly GRASP over TLS) for normal operation.

Even so I don't understand why https would be the probable choice for bootstrap.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 15:40:07 -0500

> Even so I don't understand why https would be the probable choice for bootstrap.

EST (RFC7030) runs over HTTPS.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jan 2016 10:26:50 +1300

> EST (RFC7030) runs over HTTPS.

Yes. Which means that low end devices will end up carrying a load of software
they don't really need, IMHO. Sigh.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jan 2016 16:37:02 -0500

> they don't really need, IMHO. Sigh.

which is why I'd like for the MTI to be over CoAP/DTLS.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 20 Jan 2016 09:15:06 +0100

Brian E Carpenter schreef op 2016-01-19 20:09:
>> There is the “managed network” part with the standardized stack 
>> without ASAs - possibly using DTLS with CoAP-,
> 

Actually, without the need to install or choose the ASAs, because all 
required services are already there with only one version per service 
(routing, discovery,..)

Peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 20 Jan 2016 09:29:36 +0100

>  I **SUGGEST** that the anima
> bootstrapping services

Below are the options for the managed constrained network, right? Thus 
one of the 2 solutions.

> I prefer (A) as MTI, with (C) as MAY.

I tend to prefer (A) as I don't understand all consequences of (C)

> where I do not expect to see an ACP.

Sounds reasonable, will try to think of alternatives.

> registrar to new node direction, as I've proposed in 6tisch.

I have no preferences on initiaion location for the moment.

> or layer 3 (PANA, CoAP/HTTP, etc.).  That's why it says "or"

OK, I got it, a specification "xor" and not an operation "or"

peter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2016 07:47:26 +1300

On 20/01/2016 21:15, peter van der Stok wrote:
> Actually, without the need to install or choose the ASAs, because all required services are already there with only one version
> per service (routing, discovery,..)

That may be a valid scenario, indeed, but then it really isn't autonomic; it's just automatic.

   Brian