Subject: Re: [Anima-bootstrap] CoAP mandatory?

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Mar 2017 09:51:11 +0100

On 1 Mar 2017, at 04:46, Liubing (Leo) <[email-masked]> wrote:
> 
> [Bing] I didn't quite followed the relative discussion. Is this because that CoAP is seldom supported by Non-IoT devices (e.g. telecom boxes)? 

Well, ANIMA is rarely supported by Non-IoT devices either.
So you implement it.
(The afternoon you spend on implementing CoAP during that time is pretty much inconsequential in the big picture.)

Grüße, Carsten

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 1 Mar 2017 08:55:23 +0000

Hi Carsten,

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, March 01, 2017 4:51 PM
> To: Liubing (Leo)
> Cc: Michael Richardson; [email-masked]; peter van der Stok;
> Panos Kampanakis (pkampana); Kumar, Sandeep
> Subject: Re: [Anima-bootstrap] CoAP mandatory?
> 
> > [Bing] I didn't quite followed the relative discussion. Is this because that
> CoAP is seldom supported by Non-IoT devices (e.g. telecom boxes)?
> 
> (The afternoon you spend on implementing CoAP during that time is pretty
> much inconsequential in the big picture.)
[Bing] Sure:) 
I was just curious about why there might not be consensus as Michael mentioned.

Best regards,
Bing

---

From: peter van der Stok <[email-masked]>
Date: Wed, 01 Mar 2017 10:07:35 +0100

From my point of view it will be more than nice, because bootstrap of 
IoT devices needing MASAs will be supported by the standards and the 
boxes using the standard.

I am already happy that at this stage CoAP is considered being part of 
the anima bootstrapping architecture.

Peter

Michael Richardson schreef op 2017-02-28 19:53:
> Liubing (Leo) <[email-masked]> wrote:
>     > So I guess once the new draft is adopted, BRSKI will choose the 
> CoAP
>     > as mandatory, right?
> 
> To followup an old email thread.
> 
> It would be nice (from my point of view), to do that, but I don't think 
> that
> we have consensus to do that.
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Mar 2017 09:11:46 -0500

Carsten Bormann <[email-masked]> wrote:
    >> [Bing] I didn't quite followed the relative discussion. Is this
    >> because that CoAP is seldom supported by Non-IoT devices (e.g. telecom
    >> boxes)?

    > Well, ANIMA is rarely supported by Non-IoT devices either.

Agreed. I don't expect IETF-notion IoT devices to support an ACP.
(By this, I mean RFC7228 class 2 devices)

One reason I'd like to have rfc7228bis define class 3 and 4 devices is because
that's what the technical journalism think are IoT devices.  If baby monitors
(I'll call this class 3 for now) and home routers (I'll call this class 4)
are "IoT", then yes, I *DO* expect IoT to support some of ANIMA.

{I'd say that class 3 can speak client HTTP and TLS without simplification,
and class 4 devices support a (web?) UI, and could participate as a leaf in
an ACP. That would be *my* definitions without caring about ram/CPU/Mhz...}

Even within the IETF, it seems that we have many categories of class 2
device: the power and network constraints between electric meter sensors (AMI
has 802.15.4g PHYs and batteries that get charged regularly) and industrial
sensors and light bulbs is pretty wide.

The working environment that the ARM/TEEP people seem to be coming from seems
like it's pretty rich compared to class 2: I think we are rapidly moving
towards a place where code space and scratch ram are no longer significant
limits, while wakefulness and network bandwidth continue to be limits.

(I am recently involved in a project where a RPI/OrangePI 0 with mains
and/or weekly battery changes may need to uplink via LoRAN. Makes me think of
Marvin the Robot)

I think that we can have a number of things in common.
Frankly, I'm feeling a lot of pushback at this point, so please tell if you
support these goals.

    1) I'd like to have an ownership voucher format that is in common
       between IoT (class 2) devices and higher class devices.

    2) I'd like JRCs to be able to enroll IoT devices as well as class 3+
       devices.  I don't mind if the JRC has to have totally different
       interfaces (HTTPS/EST vs CoAP/DTLS vs CoAP/OSCOAP/CoMI) for these
       differing envionments.

    3) I think that the MASA/JRC interaction can be one protocol.

In order for the ownership voucher to be easily processed by class 2 devices,
there has to be a minimum of ASN.1 crud.  If some is necessary, it should be
easily faked with predefined const char crud[]={} constructs.

OSCOAP/EDHOC seems to moving towords Curve25519, and perhaps EdDSA.
I'm unclear if ACE will move from ECDSA to EdDSA. I'd like them to.
Meanwhile, I'm unclear if hardware accel of asymmetric operations will apply
to EdDSA as well as it does to ECDSA. I think that some devices, particularly
TPM ones, are locked to ECDSA, and often the single p256 curve.  This may
lock us down for some time.  This is an onwership voucher issue.

[ASN.1 is bad for code space issues, but also because the code will be used
once, and it's not gonna get a lot of attention]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Mar 2017 09:37:46 -0500

> I was just curious about why there might not be consensus as Michael mentioned.

I think that there are three points of view:

1) ANIMA won't run on class 2 devices anyway, and bigger devices can just do
   HTTPS/EST.  Why complicate my life?

2) The CoAP mechanism is not well enough defined as yet, so we don't know
   what it even means.
        Options are:  CoAP/DTLS, CoAP/OSCOAP, CoAP/OSCOMP/CoMI (device is passive)
        IPIP proxy mechanism not well enough defined, so what does that even mean.
   Best to stick with things we know.

3) MyCompany wants to do mechanism X rather than CoAP, so if we can't have X,
   then let's specify a method too big for small devices, and in market
   confusion for small devices, MyCompany will dominate.
   (where X is various mixes of 1x, EAP, PANA, Thread, ZigbeeIP, etc.)