Subject: [6lowpan] Agenda for next meeting

From: Geoff Mulligan <[email-masked]>
Date: Sun, 04 Mar 2007 16:57:01 -0700

We need to settle on an agenda for the upcoming meeting.  I think that
everything is progressing with our two drafts - Thanks to Gabriel for
making the last minute editorial fixes.

As I've mentioned on the list a number of times, we are finished with
the items in our charter - but certainly not finished with the work to
be done.  If we are going to take on some new tasks we need to recharter
for those.

Here is the complete list of topics that have been suggested on this
list (in no particular order):

Neighbor Discovery and Secure Neighbor Discovery (proposed standard)
Stateful header compression (informational)
6lowpan applications (informational)
mesh routing (proposed standard)
Security analysis (informational)
bootstrapping
mobility
MIB definition
service discovery
scalable routing
commissioning
power saving schemes (beacons)
Architecture document

I see at least 2 very important topics that we need to finish -
  * Neighbor Discovery for 6lowpan
  * 6lowpan architecture document

Additionally, we need to reach some consensus on:
  * Routing (scalable, mesh under, route over)
  * Security
  * bootstrapping/commissioning

Since we already have a draft (expired) for ND we should seriously
consider finishing this work.  We are have a number of drafts (also
expired) and one not expired on routing alternatives.

I think that the main topic for the meeting is the rechartering, but I
think that it is extremely important that we talk with the Manet group
and understand if their work can apply to 6lowpans.

This understanding though may be based on the network architecture that
we are trying to build.  This is why I think that we should start with
defining the 6lowpan arch.

Please provide input on this.

	geoff

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 4 Mar 2007 16:27:29 -0800

Hi Geoff,

> making the last minute editorial fixes.

Great!

> consider finishing this work.  >

Agree.
I am submitting the updated version of ND draft before the cut-off date.

Also submitting the updated version of lowpan-mobility requirement draft
for a reference point of discussion.

> defining the 6lowpan arch.

6lowpan architecture document is needed. Currently ND draft has some
assumption about the topology and architecture of 6lowpan. We can start
from there.

Thanks,
-Samita

---

From: Daniel Park <[email-masked]>
Date: Mon, 05 Mar 2007 10:09:44 +0900

inline...
 
> Here is the complete list of topics that have been suggested 
> on this list (in no particular order):
> 
> Neighbor Discovery and Secure Neighbor Discovery (proposed 
> standard) Stateful header compression (informational) 6lowpan 
> applications (informational) mesh routing (proposed standard) 
> Security analysis (informational) bootstrapping mobility MIB 
> definition service discovery scalable routing commissioning 
> power saving schemes (beacons) Architecture document

For group's information here:
* Routing
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-hilow-hierarchical-
routing-01.txt
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-load-adhoc-routing-
01.txt
http://daniel.vsix.net/ietf/6lowpan/draft-montenegro-6lowpan-dymo-low-routin
g-02.txt

*Security
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-security-analysis-0
2.txt

* Service Discovery
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-sslp-01.txt

* MIB
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-lowpan-mib-00.txt

> Since we already have a draft (expired) for ND we should 
> seriously consider finishing this work.  We are have a number 
> of drafts (also
> I think that the main topic for the meeting is the 
> rechartering, but I think that it is extremely important that 
> we talk with the Manet group and understand if their work can 
> apply to 6lowpans.
> 
> This understanding though may be based on the network 
> architecture that we are trying to build.  This is why I 
> think that we should start with defining the 6lowpan arch.

sounds like ZB network architecture ?

Daniel

---

From: Myung-Ki Shin <[email-masked]>
Date: Mon, 05 Mar 2007 14:19:13 +0900

Geoff, thanks for your efforts,

I think this is a very good idea.
First of all, architecture work is most important here,
since there 6lowpan architecture is not yet defined precisely enough
(e.g, how dynamic, how mobile, how secure, how many nodes and what at
density ?, etc. ) to take on new tasks below.

Most new tasks seem to be dependent on how to define the 6lowpan
architecture, I guess.

So, I'd like to suggest we need to define 6lowpan architecture first,
including design goals and requrements for each new task.

I also think it is important that we talk with the MANET WG and know if
their work can apply to 6lowpans and what can't be done with MANET
protocols.

Regards,
Myung-Ki,

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 5 Mar 2007 23:20:19 +0200 (EET)

Hi,

I'd like to point out the ongoing work on securing neighbor discovery
(draft-haddad-mipshop-optisend-02). We're planning to submit an updated
version to the 6lowpan WG once the new charter is approved.

Comments appreciated.

Regards,

Wassim H.

---

From: Daniel Park <[email-masked]>
Date: Tue, 06 Mar 2007 08:56:35 +0900

Wassim, 

Glad to see your activities in this space...:-)

I am digging SeND relevant text from the security-analysis draft:
http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-security-analysis-0
2.txt

   if NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND
   (Secure Neighbor Discovery) should be considered to provide security
   in conjunction with neighbor discovery protocol.  So far, CGA
   (Cryptographically Generated Addresses) [RFC3972] and SeND options
   [RFC3971] are newly designed by IETF and it works well over existing
   IP networks.  However, CGA seems very complex to be applied to
   6lowpan networks.  Furthermore, SeND options requires huge additional
   options (i.e., CGA option, RSA Signature option, Timestamp and Nonce
   option and etc.)  which increase the packet size accordingly.  Thus
   it is doubtful if Secure Neighbor Discovery protocol could be
   directly applicable to 6lowpan networks without any  optimization. 

We need further in-depth discussion here. Are you thinking
SeND can be applied for 6lowpan networks ? How much fatting
down SeND itself ? It seems interesting issue but also really
difficult aspect at the same time from the security point of view. 

Anyhow, I will go through your draft and get back to you with
more details soon. Also your comments are highly welcome.

Daniel

> -----Original Message-----
> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 6:20 AM
> To: 6lowpan
> Cc: Carsten Bormann
> Subject: Re: [6lowpan] Agenda for next meeting
> 
> Hi,
> 
> I'd like to point out the ongoing work on securing neighbor 
> discovery (draft-haddad-mipshop-optisend-02). We're planning 
> to submit an updated version to the 6lowpan WG once the new 
> charter is approved.
> 
> Comments appreciated.
> 
> 
> Regards,
> 
> Wassim H.
> 
> 
> 
> > > We need to settle on an agenda for the upcoming meeting.  I think 
> > > that everything is progressing with our two drafts - Thanks to 
> > > Gabriel for making the last minute editorial fixes.
> > >
> >
> > Great!
> >
> seriously 
> > Also submitting the updated version of lowpan-mobility requirement 
> > draft for a reference point of discussion.
> >
> rechartering, but 
> > > I think that it is extremely important that we talk with 
> the Manet 
> > > group and understand if their work can apply to 6lowpans.
> > >
> architecture 
> > > that we are trying to build.  This is why I think that we should 
> > > start with defining the 6lowpan arch.
> >
> > assumption about the topology and architecture of 6lowpan. We can 
> > start from there.
> >
> > Thanks,
> > -Samita
> >

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 6 Mar 2007 23:53:22 +0200 (EET)

Hi Daniel,

On Tue, 6 Mar 2007, Daniel Park wrote:

>    6lowpan networks.

=> Agree. That's why it needs to be replaced with a lighter but at least
equally (if not better!) efficient mechanism and that's what OptiSEND
aims to provide.

>     Furthermore, SeND options requires huge additional

=> Agree.

> down SeND itself? It seems interesting issue but also really

=> In few words (but more work is of course still needed), OptiSEND
consists on using CGA *only* at the beginning (i.e., attachment). The
CGA enables to derive a shared secret between the node and the AR,
which will be used to authenticate all ND messages (i.e., which also
means that all ND messages will go via the AR). One-way hash chain
are suggested to authenticate multicast Router Advertisement messages...

> more details soon.

=> Thanks a lot! Comments highly appreciated.

Regards,

Wassim H.