Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 00:22:13 +0300

Pascal Thubert (pthubert) writes:
> My own Q&A
> 
> How is the bad ASN identified? -> I guess it can be picked from the
> frame counter in the Auxillary Security Header.

No, the auxillary security header does not contain ASN ever. The Frame
counter field is for frame counters, not for ASNs, and it is only 4
octets long, and you cannot fit ASN in there. ASN will be delivered in
the beacon frame inside the TSCH Syncronization IE. 

> But then does the spec require that the receiver checks the frame
> counter that the sender used ?

For frame counters yes, but frame counters are not used in TSCH mode.
In TSCH each device keeps track of ASN by its own clock, and as
everybody knows what ASN is, there is no need to transmit it between
nodes already in the network. ASN is only sent inside the IE for new
nodes.

And ASN will get implictly verified as if you do get out of sync with
ASN, then you will be using wrong ASN for nonce generation and all
your inbound security processing will fail. 

> Is that implemented? What is the reaction of the receiver in case of
> a bad ASN?

If it is secured frame, it will get SECURITY_ERROR for each frame
having wrong ASN, and it will drop the frames. For non secured frames,
it will not even notice the issue if it actually managed to be on
correct channel to hear the transmission. 

> -> It could send a beacon with a correct ASN I guess. But
> then how can we determine who of the 2 has the correct ASN? -> I
> guess a node should not have the right to act as coordinator until
> it confirmed his sense of ASN.

When PAN coordinator forms a TSCH network it will decide what ASN will
be used, and everybody else must sync with him when joining the
network, and must keep themselves in sync. If they loose track of ASN,
they must rejoin the network and regain the syncronization. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 01:08:23 +0300

Mališa Vučinić writes:
> Pascal,
> 
> Before the pledge selects a JP, the text from RFC8180 that is relevant seems to be (Section
> 6.2):
> 
> When a node joins a network, it may hear EBs sent by different nodes
>    already in the network.  The decision of which neighbor to
>    synchronize to (e.g., which neighbor becomes the node's initial time-
>    source neighbor) is implementation specific.  For example, after
>    having received the first EB, a node MAY listen for at most
>    MAX_EB_DELAY seconds until it has received EBs from
>    NUM_NEIGHBOURS_TO_WAIT distinct neighbors.  Recommended values for
>    MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5.
>    When receiving EBs from distinct neighbors, the node MAY use the Join
>    Metric field in each EB to select the initial time-source neighbor,
>    as described in Section 6.3.6 of IEEE Std 802.15.4 [IEEE.802.15.4].
> 
> To me, this text is ambiguous on whether the pledge should duty
> cycle its radio according to the schedule found in the first
> received EB.

When I asked this from 802.15.4 experts they said that normally nodes
start listening on channel 1 and stays there for some time, and then
move to channel 2 and so on, but usually only limits themselfs to
first n channels, as going through all channels to find beacons takes
very long time.

Normal parameters means that 10 ms * 100 slots = shared slot every
second on some channel, with EB_PERIOD of 3 or so, means there will be
beacon every 3 seconds, and with 16 channels there will be beacon on
channel 1 every 48 seconds.

If we would want the system to work even if we miss two beacons then
we would need to stay on channel 1 for 144 seconds to be sure that
there is no beacons there. Then we would move to channel 2, and
repeat. To repeat this process for 16 channels takes 38 minutes...

The reason we might not hear anything from channel 1 is because it
might be omitted from the hopping sequence as there might be
interference on it. Thats why you need to try more than one channel,
but there is no need to listen all 16 channels, as if most of the
channels have too much interference to cause them not be used, then
that network is no longer functional...

> In case the pledge does not duty cycle its radio upon receiving the
> first EB that happens to be a replay, the attacker cannot really
> desync the pledge due to its radio being on 100% of the time waiting
> for additional beacons.

I think pledge should never do that. It should always stay for same
few channels when finding beacons as otherwise attacker sending beacon
to pledge can throw it completely out of sync, and single packet can
cause join to fail. 

> Eventually, as Michael noted, one fresh EB will arrive from a
> legitimate node with a higher ASN, at which point it becomes
> critical for the pledge to select the JP with the largest available
> ASN for a given advertised PAN ID. I believe this text deserves
> expanded discussion in the Security Considerations of
> minimal-security but I am not convinced on the need for a special
> mechanism to exchange/sign the ASN.

This only works if pedge stays on the same channel while listening
beacons, otherwise it will never hear any other beacons after it
received attackers beacon (which attacker can send all the time,
making sure this is the beacon pledge will hear, and attacker can send
it on first channel always, as that is most likely where the pledge
starts listening first. 

But yes, listening on the same channel for multiple beacons, after you
hear first one should be ok, with EB_PERIOD of 3 you should get
another beacon 48 seconds later, so if you stay for that channel for
180 seconds you should 3-4 beacons. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 00:29:13 +0300

Michael Richardson writes:
> hmm.   Or, it sees a new beacon, which it can integrity check, and then sees
> the ASN jump forward.  This would be the same as if it had slept for awhile.
>
> Unless the attacker can continuously *block* the node from seeing
> the latest beacons, and continuously feeds it old beacons, the
> problem should go away.

Note, that if attacker forces joining node to be offsetted from real
network, then node will never see real beacon, and attacker has easy
task of replaying old beacons forever.

I.e., real network sends beacon with ASN 12345 on channel 1 at time t.
Then on time t+20 attacker replies that beacon on channel 1 with ASN
12345 for attacked node. Then real network sends its next beacon with
ASN 12445 on channel=8 at time t+100. Attacker replays that at time
t+120 on channnel 8 for the attacked node. The real network would use
channel 11 at time t+120, so those two networks will never hear from
each other.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Jul 2019 17:13:59 -0400

Tero Kivinen <[email-masked]> wrote:
    >> hmm.  Or, it sees a new beacon, which it can integrity check, and then
    >> sees the ASN jump forward.  This would be the same as if it had slept
    >> for awhile.
    >> 
    >> Unless the attacker can continuously *block* the node from seeing the
    >> latest beacons, and continuously feeds it old beacons, the problem
    >> should go away.

    > task of replaying old beacons forever.

Agreed.

{If the attacker is this good at finding non-overlapping bandwidth, then
attacker could instead make $$$$ fast offer network optimization services :-)}

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