Re: [6tisch] Fwd: New Version Notification for draft-tiloca-6tisch-robust-scheduling-01.txt

[Marco Tiloca <[e-mail]>]

Hi Yatch,

Thanks for your comments!

The attack as such abstracts away from the specific approach that the
adversary adopts to previously acquire node addresses. This can possibly
rely, for example, on traffic analysis to correlate with physical
position and observable events/outcomes triggered by (legitimate)
traffic. In the context of the Minimal Security Framework, the usage of
short addresses described at [1] can surely complicate this task, by
stripping away information useful to build such correlation (e.g.
vendor-related).

Given the ability to track a victim through its address in use, the
attack enables the adversary to always discover the full victim's
schedule and to severely jam all its communications, in a stealthy and
(energy-)efficient way.

Best,
/Marco

[1]
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-10

On 3/21/19 5:29 PM, Yasuyuki Tanaka wrote:
> Hi Marco,
>
> I'd like to ask you to help me understand the attack (>_<)
>
> https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01#section-3.2
>
> > 3.2.  Attack Example
> >
> > (snip)
> >
> >    2.  The adversary picks a channel 'f*' at random, and monitors it
> for
> >        N_C consecutive slotframes to determine the timeslots in which
> >        the victim node communicates on that channel.  Due to the usage
> >        property, the number of such timeslots is equal to the number of
> >        cells assigned to the victim node.
>
> How does the adversary identify communication of the victim? It
> assumes the adversary knows the EUI-64 address of the victim in
> advance, or the adversary randomly picks out a victim node?
>
> If the adversary attacks based on a target EUI-64 address, it seems
> using EUI-16 (short) address which can be assigned through the join
> process could mitigate the attack.
>
>
> https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-10
>
>
> I'm wondering how severe the attack is...
>
> Best,
> Yatch
>
> On 12/17/2018 12:38 PM, Marco Tiloca wrote:
>> Hi all,
>>
>> We have just submitted a new version of our draft describing how to
>> alter the communication pattern of network nodes to counteract
>> selective jamming.
>>
>> https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01
>>
>> This update especially addresses the comments from IETF 103, by
>> clarifying the attack importance and the adversary model. Also, the
>> draft is now aligned with the CoJP Join Response from the latest
>> minimal security framework.
>>
>> Comments are welcome!
>>
>> Thanks,
>> /Marco
>>
>>
>> -------- Forwarded Message --------
>> Subject:     New Version Notification for
>> draft-tiloca-6tisch-robust-scheduling-01.txt
>> Date:     Mon, 17 Dec 2018 03:27:31 -0800
>> From:     [e-mail]
>> To:     Marco Tiloca <[e-mail]>, Gianluca Dini
>> <[e-mail]>, Simon Duquennoy
>> <[e-mail]>
>>
>>
>>
>>
>> A new version of I-D, draft-tiloca-6tisch-robust-scheduling-01.txt
>> has been successfully submitted by Marco Tiloca and posted to the
>> IETF repository.
>>
>> Name: draft-tiloca-6tisch-robust-scheduling
>> Revision: 01
>> Title: Robust Scheduling against Selective Jamming in 6TiSCH Networks
>> Document date: 2018-12-17
>> Group: Individual Submission
>> Pages: 15
>> URL:
>> https://www.ietf.org/internet-drafts/draft-tiloca-6tisch-robust-scheduling-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-tiloca-6tisch-robust-scheduling/
>> Htmlized:
>> https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-tiloca-6tisch-robust-scheduling
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-tiloca-6tisch-robust-scheduling-01
>>
>> Abstract:
>> This document defines a method to generate robust TSCH schedules in a
>> 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4-2015) network, so as
>> to protect network nodes against selective jamming attack. Network
>> nodes independently compute the new schedule at each slotframe, by
>> altering the one originally available from 6top or alternative
>> protocols, while preserving a consistent and collision-free
>> communication pattern. This method can be added on top of the
>> minimal security framework for 6TiSCH.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se