Subject: [Spud] OS updates on embedded devices

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Apr 2015 17:09:08 -0400

We are quite a way afield here. But there are very good reasons for
NOT wanting automatic updates.

Security for me means that the device does what I want it to and
nothing else. Having the system change behavior because some code
monkey decided to add some Kewl features is a security vulnerability
as far as I am concerned.

I have Sonos devices in some of the rooms. They are practically
unusable because the idiots who make the app insist on making changes
that require the already sluggish iPhone app to be updated regularly.

When I want to turn the radio on I want it to take less than a second.
Sonos is already slow. But when it asks for an update of the app,
someone has to bring the phone to me and have me enter the password to
update it. Then the device will often fail to find the app store. If
it does find it then it is another five minutes to load the new app.

If a network device did the same thing it would undoubtedly break my network.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Apr 2015 14:38:40 -0700

> If a network device did the same thing it would undoubtedly break my network.

This discussion is probably more relevant in the IoT and security
lists. But anyway, as we start attaching more and more devices to the
the Internet they eventually become targets. One known problem we face
is that security vulnerabilities, unlike simple bugs, are usually not
caught in initial development. It's only after significant deployment
that would-be attackers get interest in this. So our choices are:
don't connect devices, update software (wherever it is) on running
devices, live with security vulnerabilities, buy new HW, have devices
live behind other devices that provide security, etc. Given that these
devices are targeted to end users and that some serve life critical
functions (like you smoke detector), a transparent solution seems
essential.

Tom

---

From: Brian Trammell <[email-masked]>
Date: Thu, 9 Apr 2015 23:44:48 +0200

What I take away from this tangent: avoiding certain types of badness is probably a necessary function of any minimal common transport such as SPUD. Which types of badness those are is a point for detailed discussion, but it probably includes avoiding anything that looks like reflection or amplification, and anything that looks like trivial state exhaustion, which we need to consider very carefully in a protocol designed to make state establishment on path explicit.

Thanks, cheers,

Brian

> On 09 Apr 2015, at 23:38, Tom Herbert <[email-masked]> wrote:
> 
> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Apr 2015 21:52:59 +0000

On Thursday, April 9, 2015, at 2:45 PM, Brian Trammell wrote
> 
> What I take away from this tangent: avoiding certain types of badness is
> probably a necessary function of any minimal common transport such as SPUD.
> Which types of badness those are is a point for detailed discussion, but it
> probably includes avoiding anything that looks like reflection or amplification,
> and anything that looks like trivial state exhaustion, which we need to consider
> very carefully in a protocol designed to make state establishment on path
> explicit.
> 

Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks.

As for IoT, did we not have a couple of IoT talks during the last IAB plenary? Most of what I read on this thread was presented here: http://www.ietf.org/proceedings/92/slides/slides-92-iab-techplenary-2.pdf. The discussion should probably move to an IoT specific list.

-- Christian Huitema

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 09 Apr 2015 15:20:28 -0700

> Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks.
We should make SPUD as good as possible. But we should not *reject* a 
solution merely because
it does not achieve some ideal as long as it is "no worse than TCP" and 
provides *some* benefit.

If there are clear areas where we are "worse than TCP" then we probably 
don't want to proceed
to even an experimental standard, because as you note - TCP is a low bar 
to compare against.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Apr 2015 17:06:50 -0700

> Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks.
That is a good requirement which is directed more at the transport
layer itself rather than the middleboxes-DPI interaction. I don't see
that requirements like this are listed in the SPUD drafts, have they
been enumerated somewhere?

Thanks,
Tom

---

From: Christian Huitema <[email-masked]>
Date: Fri, 10 Apr 2015 01:30:41 +0000

On Thursday, April 9, 2015, at 5:07 PM, Tom Herbert wrote:
> ...
> That is a good requirement which is directed more at the transport layer itself
> rather than the middleboxes-DPI interaction. 

Actually, it is also a requirement on the middleboxes. Take the example of the spoofed reset attack. End to end transport can protect themselves easily against that by running on top of DTLS. The spoofed packets will just be dropped because they don't pass authentication. But what if the middleboxes just naively closes the port because it saw the "stop" bit in a spoofed packet? The end systems cannot do anything about that.

> ... I don't see that requirements like
> this are listed in the SPUD drafts, have they been enumerated somewhere?

We could use a security analysis for SPUD. Just collecting the messages exchanged recently would be a start.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Apr 2015 09:17:20 +0200

> Agreed. In particular, "no worse than TCP" is a bit of a low bar. We need to be robust against packet injection attacks.

Everyone wants a pony.  The whole point of that tangent is that there
are many tradeoffs to be considered.  Ruling things out without
considering those tradeoffs would be as inappropriate as demanding them.

Eliot