[6tisch] on the need for neighbor discovery functionality with the 6TiSCH join process

Rene Struik <rstruik.ext@gmail.com> Thu, 11 September 2014 21:12 UTC

Message-ID: <54121023.9000108@gmail.com>
Date: Thu, 11 Sep 2014 17:12:03 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tisch-security <6tisch-security@ietf.org>
Content-Type: multipart/alternative; boundary="------------000201080008000806010508"
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/2eUElJ_M6FYBF4GVQYfV-ebS8JE
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: [6tisch] on the need for neighbor discovery functionality with the 6TiSCH join process
Precedence: list

Dear colleagues:

I had a look at the neighbor discovery protocol and cousins (including 
RFC 2490, 3756, 3971, 3972, 4861, 6775), in the context of the 6TiSCH 
join protocol, and also considered functionality provided by 802.15.4e 
TSCH that assists here.

_In this context_, it seems that most if not all neighbor discovery 
functionality is not necessary:

Communications between joining node and joining router are single-hop 
communications, where the initial join protocol message is triggered by 
the receipt of an enhanced beacon from the neighbor (a router). Based on 
the summary overview in RFC 3971 (Section 3).
- Router Discovery is not necessary, since this functionality is already 
provided via the active and passive scan and parsing enhanced beacons;
- Redirect functions are not necessary, since one could find "better" 
routers also via 802.15.4e mechanisms;
- Address Auto-Configuration is not really necessary, since either the 
Network Manager can hand these out once it admits a joining node (and 
can be implemented as part of the configuration process);
- Duplicate Address Detection can be automatically enforced if the 
Network Manager does not hand out duplicates to the admitted new kids on 
the block.
- Address Resolution may not be required, at least not between joining 
node and its neighbor router (provided the MAC does not provide privacy 
features, via, e.g., MAC address randomization; even if privacy measures 
are taken at the MAC level, the join protocol payload itself could 
potentially absorb this functionality).
- Neighbor Unreachability Detection is also not required, since the join 
protocol would ultimately be subject to built-in communication/latency 
time-outs.

This seems to suggest we can keep the join protocol really simple, since 
almost independent of a plethora of RFC drafts dealing with neighbor 
discovery.

The above triage assessment does not take into account communications 
between the neighbor router and the network manager (multi-hop 
behavior). I assumed the device topology as in Fig. 1 of 
draft-struik-6tisch-security-architecture-elements-00.

One caveat: this assessment does assume (for now) that the 802.15.4e 
functionality does its job correctly. I will revisit this as a separate 
topic (and already expressed some hurdles w.r.t. the current 802.15.4e 
spec in the past an in the IETF-90 slides (see, e.g., Slide 63 of 
000-6tisch_ietf90_toronto) presented in Toronto.

Best regards, Rene


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

[6tisch] on the need for neighbor discovery funct… Rene Struik