[6tisch] 6tisch join requirements for 6top

[Michael Richardson <[e-mail]>]

These are the things that we need to have for the 6top interface for joining.
While some craters have shown up in the architecture, some of the details are
still very solid. I am interested in making the terminology clearer and I
imagine that we have to have some IANA Considerations.
I hope to learn to write these things down in YANG.

joining node interface:
1) an enum (registry) saying what kind of network security is to be used.
   a) NO_SECURITY = 0 
   b) network-wide MIC/key, to be used directly.
   c) a network-wide "PSK", to be used with 802.15.9 mode DTLS (DHE_PSK),
      unclear to me how broadcast/multicasts are keyed,I hope to read
      the 15.9 documents.
   d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
       (Shared key message integrity code. ditto about broadcast)
   f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA),
   g) a PK method: to be used with 802.15.9 mode IKEv2 (ECDSA)
      I thought that 7296 would have rolled in the signature-auth work.
      I want to specify the ECDSA authentication methods.
   h) ditto above, s/IKEv2/HIP/
   i) perhaps a code for using draft-piro-6tisch-security-issues-02 
   -- I'm unclear how MLE works at this point.

2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this is
   around 300 opaque bytes.  We should be transfering DER, not base64 encoded
   certificates!
3) a way to indicate if (2) replaces the devices' IDevID, or if it is in fact
   the LDevID.   From a RESTful point of view, it would be best if a POST
   to (2) returned the URI of the new certificate. It could be a FIFO
   (so the oldest certificate gets silently dropped), or it could be an error
   if the device is full.
   That same RESTful view would then want to get a list of certificates, 
   with the IDevID one being listed, and one could delete it explicitely.

4) for the PSK methods, a place to put the PSK. An opaque space of around 
   128 ytes. Again, we should return a URI, and be able to list them.
   we might not want to support GET on this resource.

5) the PANID of the production network
6) "GO" flag.
   A way to tell the device that provisioning is over, and it should 
   probably restart and join the real network with the real credentials.
   
======= Join Assistant

7) a toggle which enables a node to become a join assistant.
   This might return an error if the node is incapable or unwilling to do
   that.

8) a ULA to use to announce in the RA for joining nodes.  So
   128bits+prefixlen.  A device with multiple interfaces should configure
   different 64-bit prefixes.  

9) some details about the enhanced beacon the join ssistant should transmit, 
   which I am not qualified to specify.
10) the well-known beacon key to use for the join network. (Defaulting to
   "6TISCHJOIN") 
11) the address of the JCE, for the ACL about who can contact joining nodes.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [