[6tisch-security] DRAFT minutes for 2016-09-27 and 2016-10-11 meetings

[Michael Richardson <[e-mail]>]

Reminder next meeting is October 25.

These minutes cover the meetings:
      2016-09-27
      2016-10-11

Note we started trying to use JITSI, but changed to Webex on the 27th.
For meeting reservation information, see:
    https://www.ietf.org/mail-archive/web/6tisch-security/current/msg00603.html

Summary of attendance by meeting.
    2016-09-13: mcr, Pascal, Goran, Malisa, Nancy, Thomas, Tero.
    2016-09-27: mcr, Thomas, Mališa, Pascal, Nancy, Tero
    2016-10-11: mcr, Tero, Pascal, Mališa.


To recall, the 2016-09-13 meeting consisted of recap of many activities over
the summer.  I will reply to this email with a summary of activities.

The 2016-09-27 meeting had as agenda:

Agenda for this week:
0) note well.
1) approval of agenda
2) minutes from last week.
   Approved.
3) work to do during meeting:
   time sequence diagram for document
      draft-richardson-6tisch-dtsecurity-secure-join
4) possibility to use GRASP from Join Assistant to JCE, since DAR/DAC is off
   the table.


Our discussion started with how the Pledge gets synchronized to the network,
and whether it needs a Router Advertisement, or if the L2 and L3 address
of the nearest router/join-assistant can be inferrred from the beacon itself.


PLEDGE(JN)                     JOIN ASSISTANT(JA)                JCE
           <-------- BEACON-L2-----
    hears beacon,
    determines slot offset
    of ALOHA time, get ASN
    uses "K1" key for "encryption"


     ---------"HELLO"----------> YYY
     --------- NS w/ARO +??---->  (for Link-Local address)
     <-------- NA answer-------  ZZZ
                                  -------QUERY-------->  does this node belong?
                                    DAR/DAC?  GRASP?
                                 <-------acceptable node-----

(device stays more awake to listen to answer, which may be some time)
(device already knows when the answer will arrive, so can sleep according to
schedule)

     <--------PLEASE JOIN-----   QQQ
                    NA answer positive/negative
                    new status code, 6775 update.

    Y<--------------------JOIN PROCESS------------------------>X
    <-- DTLS/EDHOC KMP packets--<PROXY<-----------------------

    <-----/6p over CoAP -------PROXY<---IPIP-/6top-over-CoAP---
    ------------_REPLY_--------------------------------------->


Q: can JN infer link-local address of JA from beacon?  avoiding multicast of
   RS... the NA(line YYY) is there for the JN to announce itself.

Pascal: normally the device multicasts RS, and JA will reply with RA
        (unicast), which establishes LL address of router.

        The beacon is broadcast,  but other options could be included....  in
        802.11 there is a task group to expose services in the beacon.

what would we put into the beacon:

    mcr: do we need to have an RA?
    Could the beacon say, "I support IPv6, here is my IPv6 LL address and my
              L2 address", can not be implicit in beacon?  But, some kind of
              RA needs to exist.

    do we have room in the beacon?   How big is a compressed RA?

   Could we put data in the beacon in addition to the IE?

   In a beacon, there is some space for data, but what is in it is not
   defined.

   Yes, can we do it? Does anyone process it, pass it to upper layers?
   Better to add IE?  Could we use the new IETF IE type to put a compressed
   beacon into this IE?
   Tero: it would make perfect sense to put some stuff there.


The 2016-10-11 meeting continued to the topic of RA in IE.

Agenda for this week:
     0) note well
     1) minutes from last time not yet posted; sorry.
     2) recap of time sequence diagram.


    PLEDGE(JN)       JOIN ASSISTANT(JA)        JCE
        <--------------- BEACON-L2                   (1)
        <-------RA ------                            (1B)
        ---- LL NS w/ARO --->                        (2)
                               ------- QUERY---->    (3)
                               <------ REPLY-----    (4)
        <--- LL NA answer----                        (5)
                    some time later
        <-----coaps--------<=======IPIP-COAPS====    (6)
                    multiple trips
        ------------------->====================>    (7)


We noted if RA is contained in Beacon, then it will be visible to all hosts,
both those joined, and those attempting to join, so we must be conservative
and privacy limiting in what we chose to multicast.

Slots in which one can multicast do not occur that often, so sending more
data during this important slot is valuable.

We would send as little as possible in the Beacon-RA, because it needs to
remain as small as possible.

PLAN: Create new IE with minimal RA-equivalent (compressed RA).
      Compressed RA would announce that it is a JA.
      Do not include PIO in RA, but suggest hosts send unicast RS to
      get that information, and unicast are easier to secure.

Could also have hint about network identity (this also helps hosts rejoin
   after a interuption in connectivity).
   [network identity could be DODAGID, or EUI-64 of MESH ROOT?]

We discussed the question as to whether or not all routers were also
Join Assistants, with some dispute as to the cost of that function.
We did however conclude that:

a) Every JA must be a router.
b) A JA may do things a router does not.
c) Every router must be a (802.15.4)  coordinator, and sends beacons.
d) Every beacon must contain a compressed RA in an IE, for the benefit of
   leaf-nodes (hosts!): hosts need to know L3 address of router to send NS, RS,
   etc.

Does this get rid of need for step (1B) in time sequence diagram?

**** Do we ever need broadcast RA in 6tisch? ****

Calculation recorded:
            broadcast slots are rare:  10ms slots, slot-frame length=100, so
            1 slot/s for beacon (rare).
            But, some people might have slot-frame length=5, so not so rare.

Conclusion: "we want to define a minimal-RA that would be contained in an IE"

We discussed how long a pledge would have to listen (and on how many
channels) in order to hear a beacon.... 802.15.4 defines a Beacon Request.

Could Pledge send a Beacon Request?  Yes, in normal 15.4, but in TSCH mode,
this is more difficult.

i.e:
        <--------------- BEACON-L2                   (1)
        --- EBR asking RA or RS ->
        <-------RA ------                            (1B)

(and this is three uses of the shared slot!)

Are we creating an IE to encapsulate an IPv6 packet, or an
    compressed(JA-src.IID)+6loRH(ICMPv6 header+options)?

How big is minimal Beacon anyway?  about 50 bytes (used).

Malisa has complementary draft: which is... XXXX?






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