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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    >> Tero Kivinen <[e-mail]> wrote:
    >> >> d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
    >> >> (Shared key message integrity code. ditto about broadcast)
    >> 
    >> > How the broadcast/multicast keys are keyed is not really defined in
    >> > the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are
    >> > identified with the two attributes, Key Source and Key Index. The
    >> > format of the Key Source depends on the Key Identifier Mode value.
    >> > There are 4 different values for the Key Identifier Mode:
    >> 
    >> So, it's not enough to say "use 15.9" for key derivation, having provided
    >> locally significant certificates.  

    > Not really, as it would about the same as say use IPsec for protecting
    > the IP packets. 

{for others, one of the failure cases for IETF, circa-y2000, as that
protocols had Security Considerations that said "Use IPsec", without
explaining *how* to use it}

    > It does not yet specify how the policy is set up and
    > which kind of configuration should be used in either ends. In 802.15.4
    > the problems are just bit lower than in IPsec, i.e. you need to define
    > what kind of keys you want to create, and how to identify those keys. 

So I am assuming that some of these details would go into the YANG model as
additional fields.  Some, such as what ciphers to use, we might initially
"default" to AES-CCM, assuming that if there an option, it's an upgrade, and
a new YANG model would include the bit to turn it on.

    >> We also need a way to define a key for multicast operations, and I don't see
    >> a way to do this other than having the join process provision one.  

    > Who will own that multicast key, i.e. who decides when it is going to
    > be rekeyed? Who will give that key out to others? Do everybody have
    > direct connection to the owner of the key? Are there going to be
    > multiple senders for that key or just one?

1) There are multiple senders.
2) There is a mesh, and not all nodes have a direct connection to the root.
3) I imagine that the root (6LBR) has to own the key.

    > What Key Identifier Mode you are planning to identify the key, what
    > KeySource and KeyIndex values etc?

    > You could for example specify that the pan coordinator "owns" the
    > multicast key, so he will take care of rekying etc, and the Key Source
    > field of the auxiliary security header specifies him.

I don't think we have a specific pan coordinator in 6tisch.

    > For example using Key Identifier Mode 1 (everybody set their
    > macDefaultKeySource to match the extended address of the pan
    > coordinator) and specifying that Key Index 0x10-0x1f is used for this
    > multicast group (this would allow 16 groups so pan coordinator can
    > create new key, and every time he sees someone using old key, he can
    > send them new key, and ask them to delete old one).

I'm confused by why we would have to set the macDefaultKeySource to match the
pan coordinator.  Probably, I don't know what that field controls.

It would be nice if the pan coordinator could see all the transmissions, but
that won't be the case; the join coordinator will have to refresh the keys.

    > Then on the actual frames the senders most likely would use full
    > extended address when sending packet to multicast group as source
    > address (so even those who do not know the senders short address can
    > get the packet), and use Key Identifier Mode 1 and the Key Source and
    > Key Index matching the pan coordinator to indicate they are using
    > multicast group key owned by pan coordinator.

    > Or something like that. There are other options available too, and you
    > need to think which one of those is best suited for your needs.

I think that this is the right scenario.

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