Re: [6tisch] 6tisch join requirements for 6top

[Xavier Vilajosana <[e-mail]>]

Hi Michael,

I think part of these should go to the 6top interface expressed in YANG
model. Here some comments inline.

thanks!
X

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.

That's easy, a placeholder for that option can be added to the YANG model.
Is this an option that can be set and read right?

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!

Is this read only or read/write, write-once? .. Should be exposed so it is
queried/modified or is something static that will never change (except for
the first time)?

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.

ok this can be done too.

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.

idem as before. in YANG we define the placeholder and the access method.

5) the PANID of the production network

the PANID is part of the 15.4 PIB. It should be exposed by 6top.

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.

This is the joining/security state. We may think on a state machine (only
Go and Configuring options?)

======= 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.

Ok, this seems a capability indicator. Could this be a bitmap so we can
flag multiple capabilites?

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.

How this ULA is build? could it be build/defined using 6top information? or
it is a completely new element?

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")

Ok this requires space in the yang model to store the well-known key.

11) the address of the JCE, for the ACL about who can contact joining nodes.

Ok this is a L3 "important" address dictionary that a node should keep. Is
this the only address we need to know? PCE? other services in the network?

2014-11-17 20:42 GMT+01:00 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    [
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>