Subject: [Coma] If all you had was an LED ...

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jun 2012 11:40:12 -0700

Imagine an sensor devices that is very cheap and connects to the network. Lets say the only UI the device has a single LED, or perhaps a red and green LED. 

How would you use these 1 or two LEDs to help manage the device? 

Lots of existing stuff blinks them in various ways to indicate different states of the network (no carrier, connected but no IP, etc). Would it make sense to have some standardized recommendation about this? 

It would be possible to send a small message as a burst of rapidly changing light patterns that was detectable by the video camera on a smart phone. Would it make sense to use this for something like POST codes on PCs? 

What are the various states that an operator would want to be able to see? I'm assuming this is mostly states that are important when one can't get networked base management. 

Thoughts? Pointers to what existing systems do ?

Thanks, Cullen

---

From: Johannes Gilger <[email-masked]>
Date: Fri, 8 Jun 2012 09:26:25 +0200

Hi list,

On 07/06/12 11:40, Cullen Jennings wrote:
> It would be possible to send a small message as a burst of rapidly
> changing light patterns that was detectable by the video camera on a
> smart phone. Would it make sense to use this for something like POST
> codes on PCs? 
> 
> What are the various states that an operator would want to be able to
> see? I'm assuming this is mostly states that are important when one
> can't get networked base management. 
> 

I'm also interested about this (or very similar) out-of-band channels in
real-world applications. Using the LED OOB-channel could prove to be a
reliable way to manage the devices, and maybe even to exchange security
parameters. If there was a protocol, it would help in exchanging
different kinds of information (short POST-like codes vs. whole
shared/asymmetric keys) over the air.

This also brings me to the question of how much this list
will touch into management of security, i.e. bootstrapping of security
associations, setting of access control rights, etc.

Regards,
Johannes

-- 
Dipl.-Inform. Johannes Gilger
Research Group IT-Security
UMIC Research Centre
RWTH Aachen University
Mies-van-der-Rohe-Straße 15
52074 Aachen

Office: 211
Phone: +49 241 80 20781
Fax:   +49 241 80 22731

http://itsec.rwth-aachen.de

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jun 2012 20:20:34 +0200

Hi Cullen, Johannes,

> > Lots of existing stuff blinks them in various ways to indicate different states of the
> > network (no carrier, connected but no IP, etc). Would it make sense to have some
> > standardized recommendation about this?

Based on the manifold sensor devices and the needed interoperability for data exchange, it would be useful to have a common interpretation for the different states (standard model?) relevant to the management of these devices. 

> associations, setting of access control rights, etc.

I think the management of security should be in our focus. Though what management of security covers is open for discussion.

Cheers,
Mehmet

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 13 Jun 2012 15:56:40 -0700

Hi,

On Jun 13, 2012, at 11:20, "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]> wrote:

> [...]

Right. What I wonder is if the network topology and the kind of link layer have an influence, e.g., if keys for certain L2 are to be exchanged (or should we focus on layer 3+ only? But sometimes, they same keys could be used at multiple layers...). The topology may matter, e.g., in case of MANETs, since at the time of bootstrapping security credentials, routing may not be established (chicken/egg problem).

But in essence, managing security bootstrapping is interesting, and I believe in focus for this discussion.

Best
Ulrich

> 
> Cheers,
> Mehmet
> 
> 
> 
> _______________________________________________
> Coma mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/coma