Re: [Spud] SPUD's open/close are unconvincing

[Toerless Eckert <[e-mail]>]

If all IoT devices could hace a touchscreen and personal operator
bringing them to places for failed upgrade help and 70% of them
would be 48 monthly throwaways that never get upgraded anyhow,
i would certainly want to clone the smartphone operational model
to those IoT devices. 

Just look at the uproar generated recently for security attacks
against BIOSs. You need clear security perimeters, and the
question is why a reliable transport stack for an app would
need to be in a more secure perimeter than the app itself.


On Thu, Apr 09, 2015 at 11:40:20AM -0700, Tom Herbert wrote:
> On Thu, Apr 9, 2015 at 10:46 AM, Toerless Eckert <[e-mail]> wrote:
> > Glad you didn't ask how SPUD can solve world peace, because i am
> > still researching that aspect.
> >
> > There is a lot of work going on wit security models of device deployment,
> > you may want to look at 6LO, 6TISCH, ACE, DICE, ANIMA and there is a
> > lot more outside the IETF. I would see that work as prerequisites
> > to move forward.
> >
> > IN general, i think there is one good and sane device operations method,
> > in IoT which is to NOT upgrade the OS after initial device deployment,
> > but just upgrade/modify applications. And with SPUD, that means you
> > now can upgrade/fix/improve transport layer.
> >
> Well, there's already over a billion smartphones in the world which
> are already regularly updating their OS and this hasn't yet led to
> mass anarchy. You can certainly make avoiding OS updates and avoiding
> OS in general a design point for your products, but this is not a
> relevant design point or requirement for a networking protocol. As I
> said, it's a red herring wrt SPUD.
> 
> > Just think of the problem of network based self-upgrade of OS SW in a
> > reliable fashion with limited Flash/NAND storage or the operational
> > issues in IoT for a PXE/AMT Sw upgrade workflow. Lots of challenges with that.
> >
> > Just strip down the OS to the bare minimum for operations with a strong
> > security perimeter, do the rest at the app-level.
> >
> > Cheers
> >     Toerless
> >
> > On Thu, Apr 09, 2015 at 10:22:59AM -0700, Tom Herbert wrote:
> >> On Thu, Apr 9, 2015 at 6:09 AM, Phillip Hallam-Baker
> >> <[e-mail]> wrote:
> >> > On Thu, Apr 9, 2015 at 12:15 AM, Toerless Eckert <[e-mail]> wrote:
> >> >> On Wed, Apr 08, 2015 at 08:46:24PM -0700, Tom Herbert wrote:
> >> >>> I think the kernel/user-land argument is a red herring.
> >> >>
> >> >> Elaborate please. To me its probably the biggest motivator for
> >> >> SPUD. Otherwise we could design all we need into IP and TCP.
> >> >
> >> > TCP should probably not happen in the kernel either. Nor should
> >> > printer drivers be in the kernel or anything that does not require the
> >> > intermediation of the security monitor.
> >> >
> >> > Looking at the shoot-yourself-in-the-foot opportunities in the IPv6
> >> > encoding, I am not exactly anxious to put all those untrusted code
> >> > paths in a position where they can root the machine.
> >> >
> >> > One of the main reasons the current generation of O/S are chronically
> >> > insecure is that 90% of the stuff that is inside the security
> >> > perimeter has no business being there.
> >> >
> >> The major Internet security problem now is in embedded systems which
> >> are not maintained (which notably includes middleboxes  like home
> >> routers) (https://www.schneier.com/essays/archives/2014/01/the_internet_of_thin.html).
> >> This is not a OS, userspace, or firmware issue, or even protocol a
> >> issue-- but this is an issue with the software deployment model of a
> >> wide array of products. I don't know how SPUD will be able to help
> >> solve this, but it should at least not make things less secure.
> >>
> >> >
> >> > At this point TCP is water under the bridge. But that does not mean we
> >> > are obliged to remake the mistake.
> >> >
> >> > When TCP was designed, the mantra was 'everything is a stream'. That
> >> > was the right abstraction for Telnet and FTP and Mail. It is probably
> >> > not the right abstraction for real time web where an unreliable
> >> > sequence of chunks seems a better fit.

-- 
---
Toerless Eckert, [e-mail]