Re: [Lwip] [OPSAWG] [Suit] next steps in clarifying scoping terminology for SUIT, CoSWID, MUD and SBOM

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    > Hi Michael,

    >> On 2020-06-09, at 18:13, Michael Richardson <[e-mail]>
    >> wrote:
    >>
    >> […] smartphones do not fit into RFC7228, and yet they are not
    >> "unconstrained"
    >>
    >> We constrast SUIT to devices where the is potentially many packages
    >> that can be updated, up to and including the Linux/Windows
    >> desktop/server environment where there are potentially thousands of
    >> packages.
    >>
    >> In RFC7228, we described a series of useful terms and classes, and we
    >> have repeatedly come back wishing to have some notions of "class 3+"
    >> to describe classes of more capable devices, up to and including
    >> "classic" desktop and server OS installations.
    >>
    >> I think that as we move towards dealing with SBOM concepts (whether
    >> via CoSWID, or in liason to IoTSF and/or NTIA) that it would be useful
    >> if we worked on an rfc7228bis (or a companion document: nothing wrong
    >> with 7228 really), that allowed us to speak more intelligently about
    >> different classes of devices.

    > There is activity on a 7228 bis.

    > Would

    > https://tools.ietf.org/html/draft-bormann-lwig-7228bis-06#table-1

    > have helped you?

https://tools.ietf.org/rfcdiff?url1=rfc7228&url2=draft-bormann-lwig-7228bis-06.txt

    > This has a number of experimental classes above 2; both in the M Group
    > (microcontrollers) and the J Group (general purpose computers — pun
    > only accessible to people who know how Jeeps got their name).

    > Note that Sections 3.1..3.3 have more experimental categories; not sure
    > these are useful for what you are trying to do.

I appreciate the direction you are going.
Is LWIG going to adopt it?  I thought I was on the list, but I might have
fallen off.

I believe that there are some important intervals between class 10 and class 15.
I know of quite a number of class 10ish SoCs that run OpenWRT in less than
4Mb of flash, and have essentially only GPIO pins, like the M-class.
It is in this category that I think we have the most public cybersecurity
risk, as they are deployed to interface some legacy (RS232) sensor to the Internet.

Smartphones have particularly obtuse constraints: while ram sizes are
increasing, so are code sizes.  But, they have no swap.

You can't run a modern browser on a five year old phone, yet even five years
ago, the device would have been considered "luxury".  There are quite a
number of devices that seem luxurious, but once the "OS" is running there
actually isn't much left for anything.  Lots of "ROM" very little write
storage.  Also the use of compressed read-only file systems makes a lot of
things difficult.  The result is that big M-class systems can accomodate
more complexity than low-end A/J class systems.

This leads to open telnet ports with no authentication, but also winds up
begging the question: if it did authenticate, how would they set the
per-device unique password, since there isn't anywhere useful to put it?

You get into MMU vs no MMU, but many of the M-class devices *do* include
memory management units, just not *virtual* memory management units.
The presence of TEEs of various kinds is a form of MMU, and that should be a
first class as well.  Section 3.2 should include TEE.
I know you are trying to say this in 3.3, but that section could be about
hardware TPMs as well secure enclaves for instance.

I really like section 3.1.

Between F1 and F2 are devices which can download new firmware and install it
while operating, and then can reboot fast enough that nobody notices, but
would not be described as "hit-less".

F2 means you notice the reboot

I know that term from big-ass switching equipment that can upgrade their OS
(restarting), but leave the switch fabric and RIB and FIB around intact.
I think that this is more than "app-level".
And kpatch'able servers.

section 4.4 would have been very useful in BRSKI.
           Even devices that have a battery lasting for
 	   their lifetime may not be set to wall-clock time at manufacture time,
 	   possibly because the battery is only activated at installation time
 	   where time sources may be questionable or because setting the clock
 	   during manufacture is deemed too much effort.

I think that this is actually the most difficult situation.
A device might *think* it has an accurate wall-clock, but in fact, be wrong.
This is sometimes worse than having no time.
(Or: a stopped clock is right two times a day...)

For uncertainty in time, 1e-4 is 1/10000, or 8s per day or 1min/week
Can we express this in both ways?

I believe that 5.2/Internet integration has a number of things
below I0, and between I0 and I1.   We need to position native SMS,NFC,BTLE and
maybe the non-IP capable "LoRA" stuff in.  Why? because CoAP.
We also need to position IPv6-LL restricted devices which are just unable
to talk off the wire.
I have talked about "Connected Things" (BTLE,NFC,etc.), "Web Connected
Things" (I1) and "Internet of Things" (I9).  I think that between I1 and I9
are a plethora of solutions that we care about that involve CoAP, but not HTTPS.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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