Dear all, Here is an attempt to summarize the recent discussions regarding the problem of 6tisch join and provisioning of K2 to JN. See bellow. Implementation components that can be reused are enclosed in the parentheses. Traffic load is expressed as the number of messages, rather than number of exchanges, as this better reflects the nature of the link we will be using: a single shared communication slot carrying ~100 bytes of data (cf. draft-ietf-6tisch-minimal).
It seems there are three main directions the WG can take: 1) EAP over foo; 2) DTLS; 3) 6tisch-specific solution. Option 1 seems the most extensible and generic but I dislike the fact that there would be a lot of join-specific code. We are already having difficulties fitting the stack into certain IoT MCUs due to the flash constraints and having 2-3 protocol implementations that are used only once certainly does not help. Cases 1.C and 1.D that seem to require less join-specific code have either prohibitively large traffic load (1.C) or rely on session security that is not standardized, in which case a 6tisch-specific solution with 4x improvement factor in traffic would IMO be a better option. Option 2 leverages the DTLS implementation that is in any case mandated by CoAP so it does not necessitate much additional implementation effort, other than the JA relay application. Another advantage here is that one can pass from PSK to certificate-based authentication transparently. The traffic load remains a significant concern. See http://arxiv.org/pdf/1507.05810 <http://arxiv.org/pdf/1507.05810> for some figures on duration of DTLS PSK handshake with *dedicated* cells (e.g. ~5 seconds per hop per JN with 101-long slotframe, and this is in the *best* case tripled with many nodes joining and slotted Aloha behavior). Option 3 would imply designing a minimal 6tisch solution to provision K2, compatible with the existing 6tisch architecture and mechanisms (6top, CoAPie). In short, we discussed a simple protocol where JCE keeps track of JN-specific join counter used for replay detection, that JN advertizes in the hello message including information like its EUI-64, random challenge for JCE, all protected with PSK. The JCE sends K2 encrypted with PSK and transfers that over the network to JN. Advantage of this direction would be minimized traffic load (3 messages vs 11+) and possibly implementation requirements as we can do this extending 6top and re-using CBOR implementation. A disadvantage would be the fact that we are not using a standardized solution. It would be useful if we could discuss some of these aspects tomorrow during the call. Also, it would be great if people with benchmarks on join duration without any security would post these to the list. Regards, Mališa Option 1: EAP-based ——————————— Case 1.A: IKEv2 over 802.15.9 + EAP (e.g. -AKA) (http://mailarchive.ietf.org/arch/msg/6tisch/fPmwtSOL-v0FDNcU3sWwHAdeyTs) - Traffic load: 6 messages between JN-JA, 4 messages between JA-JCE - Implementation requirements: minimal IKEv2, 802.15.9, EAP-AKA - Notes: JA takes active role during join, could be useful for DoS protection with certificate-based authentication Case 1.B: EAP over PANA - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ messages for EAP-TLS ] + 1 packet to provision K2 - Implementation requirements: PANA, EAP method - Notes: JA is a passive relay Case 1.C. EAP-PSK over CoAP + DTLS (e.g. draft-marin-ace-wg-coap-eap-02) - Traffic load: 10 messages between JN-JCE to establish a unique session key + 11 messages for DTLS to establish a session with the established key + 1 packet to provision K2 - Implementation requirements: EAP-PSK, (DTLS) - Notes: JA is a passive relay Case 1.D. EAP-PSK over CoAP + custom protection of CoAP header/payload with the generated key - Traffic load: 10 messages between JN-JCE to establish a unique session key + 1 packet to provision K2 - Implementation requirements: EAP-PSK, custom CoAP security extension - Notes: JA is a passive relay Option 2: DTLS-based ——————————— Case 2.A: JN is a DTLS client - Traffic load: 11 messages between JN-JCE + 1 packet to communicate K2 over the established session - Implementation requirements: (DTLS), relay application - Notes: JA is a passive relay Option 3: 6TiSCH-specific ——————————— Case 3.A: Explicit provisioning of K2 using 6top+CoAP, protected with JN’s PSK (e.g. http://mailarchive.ietf.org/arch/msg/6tisch/Obm-_ehdAeGXKXOEwzpdeB5diq8) - Traffic load: 3 messages between JN - JCE - Implementation requirements: (CBOR) + COSE - Notes: JA is a passive relay
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
