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

[Michael Richardson <[e-mail]>]

Xavier Vilajosana <[e-mail]> wrote:
    > I think part of these should go to the 6top interface expressed in YANG
    > model. Here some comments inline.

Yes, that was my intention.

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

Yes, R/W.

  mcr> 2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this
  mcr> is
  mcr> around 300 opaque bytes.  We should be transfering DER, not base64
  mcr> encoded
  mcr> 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)?

It could be read for diagnostics and management, but it's mostly write.  


  mcr> 3) a way to indicate if (2) replaces the devices' IDevID, or if it is in
  mcr> fact
  mcr> the LDevID.   From a RESTful point of view, it would be best if a POST
  mcr> to (2) returned the URI of the new certificate. It could be a FIFO
  mcr> (so the oldest certificate gets silently dropped), or it could be an
  mcr> error
  mcr> if the device is full.
  mcr> That same RESTful view would then want to get a list of certificates,
  mcr> with the IDevID one being listed, and one could delete it explicitely.

    > ok this can be done too.

Good.


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

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

  mcr> 5) the PANID of the production network

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

Good, no need to duplicate.


  mcr> 6) "GO" flag.
  mcr> A way to tell the device that provisioning is over, and it should
  mcr> 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?)

Yes, we likely need to define a state machine; I'm suggesting that this is
just an input to that.

  mcr> ======= Join Assistant

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

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

Are you suggesting that the ability to be a Join Assistant is in a separate
capabilities resource?

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

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

I think that the JCE determines it.  Pascal has the notion that it needs to
be unique per Join Assistant, I'm not yet convinced one way or another, but I
suggest that the JCE assign it.

  mcr> 9) some details about the enhanced beacon the join ssistant should transmit,
  mcr> which I am not qualified to specify.
  mcr> 10) the well-known beacon key to use for the join network. (Defaulting to
  mcr> "6TISCHJOIN")

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

Yes.


  mcr> 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?

It's all that is necessary as part of becoming a Join Assistant.

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-