[6tisch] emails on 802.15.4 specs

[Rene Struik <[e-mail]>]

Dear colleagues:

Most emails about speculated behavior of the 802.15.4 specification 
could have been avoided by actually reading the spec. So, what about we 
simply do this? What remains after this could then be bait for emails...

Relevant specs: 802.15.4e-2012 and 802.15.4-2011.

Best regards, Rene

On 12/1/2014 11:35 AM, Michael Richardson wrote:
> 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.
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]