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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    >> [PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN")
    >> has been debated for a while. The lack of an ethertype has already
    >> lead in the field to frame from protocol A being understood -wrong-
    >> by protocol B. 

    > So when someone is running the protocol A and B both over the same
    > default well-known key then you still have the problem...

The point is that protocol A says, "join key is FOO",
and protocol B says "join key is BAR".  They never conflict that way.

    >> Even if that looks anecdotic, we are now facing the need to reuse
    >> some messaging footprint in 6LoWPAN, and if that happens, we need to
    >> make sure that the overlapping protocol elements never mix in a same
    >> network. 

    > Didn't 6LoWPAN add some multiplexer in the beginning of data, or do I
    > remember wrong? 

Yes-ish, but it's only a few bits.

    > Hmmm..actually even Key Identifier Modes 2 or 3 cannot be used, as
    > they also require the MAC to fill the KeyDescriptor beforehand, and
    > there they will need to now the extended address of the coordinator.

    > Of course the 15.4 does not tell how the KeyDescritors are created, I
    > have always assumed that upper layer creates them when the inbound
    > security processing fails with UNAVAILABLE_KEY. I.e. this error would
    > somehow be passed to the upper layer along with the KeyIdMode,
    > KeySource, KeyIndex, device addressing mode, device PANID and device
    > address. The upper layer would then see if it can create KeyDescriptor
    > entry for the key and if so, it would do so and for the next packet
    > from the same peer the entry would be there. All of this is of course
    > NOT specified in the 15.4, so there is no way to say what
    > implementations do.

I'm hoping that Jonathan and Chris will chime in here and explain how they
implemented the well known join key in WirelessHART.

    > So if this kind of joining key for beacon is wanted, I think the best
    > way would be to use Key Identifier Mode 3, as then the beacon actually
    > has all the information needed to create the KeyDescriptor. This will
    > then mean that beacons will have 14 bytes of auxiliary security
    > header, and 4 to 16 bytes of MIC. Adding for example 10-byte SSID
    > Header IE would make packets smaller...

    > Note, that receiving peer needs to know the extended address of the
    > sender in the 15.4 to be able to decrypt the packet, as the nonce
    > generation depends on that. There is no way around that. 

When you say "extended address", do you mean 64-bit EUI?

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