Subject: Re: [Roll] Polling the Roll WG for Adoption of the Terminology

From: <[email-masked]>
Date: Fri, 3 Oct 2008 11:01:50 +0200

Hello all,

Great job!
I have two comments remaining.
A) do you insist that a "channel" be an interval along the frequency
axis, as opposed to any partitionning of the medium ?
Although traditional narrow-band radios did partition the medium along
the frequency spectrum, IEEE 802.15.4 2007 includes UWB PHY where
"channel" is not equivalent to "frequency band". I'd suggest we stay
PHY-agnostic.
B) Controller : do you really mean "facility"? "Facility" is reminiscent
of "industrial" to me. Doesn't the defintion of a controller hold in
other environments?

Best regards

Dominique 

>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 30 Sep 2008 16:03:04 -0700
>From: "David E. Culler" <[email-masked]>
>Subject: [Roll] Polling the Roll WG for Adoption of the Terminology
>	Draft
>To: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>I would like to poll the membership on adoption of the Terminology ID.
Link to the draft is below.
>
>http://www.ietf.org/internet-drafts/draft-vasseur-roll-terminology-02.t
xt
>
>
>
>-----------------------------
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 3 Oct 2008 15:29:40 +0200

Gentlemen,

This was discussed in previous meetings, but still awaits a conclusion:

The ability of a ROLL node to address a number of nodes with one single
unacknowledged IP packet,
a.k.a. Groupcast, is a significant feature in home control networks.

It is agreed that since Groupcast is intended only for nodes in the same
"subnet" and within direct range,
it does not present a routing requirement as such.

The question is if a separate application-level ID should be created for
ensuring compatibility between
home control devices using ROLL routing?
Initially, the document would only contain the definition of broadcasted
IP packets carrying a groupcast
header extension in the payload of the packet.
Other requirements related to the application-level might also belong
here.

Alternatively, a small section could be maintained in the home-routing
ID, defining the header extension,
and at the same time emphasizing that this requirement is not for
routers but for the interoperability of
host applications.

What is Your opinion?

Thanks,
  Anders

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 3 Oct 2008 15:48:09 +0200

Gentlemen,

Originally, the security section of the home-routing ID contained a
number of requirements which did not relate to routing after all.
Thus, most was removed.

This is what was left in draft-ietf-roll-home-routing-reqs-03.txt:

------------------------------------------------
6. Security Considerations 

   Implementing security mechanisms in ROLL network devices may 
   degrade energy efficiency and increase cost. 

   The routing protocol chosen for ROLL MUST allow for low-power, 
   low-cost network devices with limited security needs. 

   Protection against unintentional inclusion in neighboring networks 
   MUST be provided. 
------------------------------------------------

As we hope to have a stable version ready for Minneapolis, we would like
to
probe the WG for a proper level in the security section.

Note that this document does only deals with routing requirements
particularly
relating to home control networks.

Yes, remote control of door locks requires security, but that is on the
application
level, i.e. not routing.

Yes, somebody may jam my network, but that does only require a radio
jammer.
Security cannot protect me against that anyway.

So, the question is:

Did we reduce the section too much?
Is there a routing-related concern we missed to identify?

Thanks,
  Anders

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 3 Oct 2008 17:27:52 +0200

Hi Anders,

An "evil" node joining the network might cause energy to be wasted.

Preventing such a node to join the network might mean some sort of
authentication and/or encryption scheme. We all are painfully aware
(WEP) of what happens when security is left as something to consider
in the very last moment.

Unfortunately I do not have a magic bullet for this:

* A pre-shared key enables a common encryption among non-evil nodes
but this approach does not scale well.

* Having an authentication server on the WSN might be the answer to
scalability issues, but this leaves the way open for attackers to
force multiple authentication attempts that may waste some nodes
energy.

Maybe I would add something like "Some form of node authentication
will be in place to prevent that." after the last sentence section 6.

Again what worries me, as you mentioned, is that the security
implementation might need more energy and add more delay.

Cheers,

Miguel Sánchez

---

From: Zach Shelby <[email-masked]>
Date: Mon, 06 Oct 2008 14:36:08 +0300

Hi Anders,

I was one of the critics of the groupcast issue in your draft. My 
opinion is (still) that the discussion of an application payload header 
definition to achieve groupcast, definitely does not belong in this 
working group.

Where it does belong I don't know. Are there any existing IETF 
application protocols, which could be used to achieve groupcast? Or is 
there an existing WG where such a contribution could be made? Are there 
specifications from other standardization bodies (BACnet?) which could 
be used over IP to achieve this and in general application interop?

- Zach

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Thu, 09 Oct 2008 08:49:48 -0700

Dear all,

Please look at this email, and let the author know if you have concerns. The
idea is to Last Call the document fairly soon.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 09 Oct 2008 08:51:41 -0700

Hi Anders,

> routers but for the interoperability of

I would suggest not to have a normative section on header extension in this
document, this is a routing requirement document. You may want to keep some
informative text at most. I will try to find you a room for the document
that you are referring to.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 09 Oct 2008 08:54:34 -0700

Hi,

> will be in place to prevent that." after the last sentence section 6.

Thanks for the suggestion. For sure, additional security will not come at no
cost. You may then want to articulate that additional security SHOULD be
added at reasonable cost. It is difficult to be more explicit without being
implementation specific.

Thanks.

JP.