Re: [6tisch] Fwd: New Version Notification for draft-tiloca-6tisch-robust-scheduling-01.txt
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: internet-dra...@ietf.org To: Marco Tiloca , Gianluca Dini , Simon Duquennoy 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
Hi Yatch, Thanks for the following-up comments! I replied inline below. On Thu, Mar 21, 2019 at 4:25 PM Yasuyuki Tanaka wrote: > Thank you, Tengfei. > > Additional and following-up comments: > > > [Section 5.1, what to do after timeout of a 6P transaction] > https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5 > > The draft does not say anything about how to handle timeout of a 6P > transaction. I know, the initiator of the timed out transaction will > resend a 6P request to the same peer ;-) But, it's better to mention > that as well as the maximum number of retries if we have. > > Comment accepted! > > [Section 9, 6P Timeout Value] > https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9 > > A couple of questions: > > - "C" includes the autonomous cell to the neighbor or it is the number >of the managed cells? > - How can the timeout value be calculated while PDR is not available? > > I agree that those questions are not clear for the current version. As the current version allows 6P to send on the autonomous SHARED cell mentioned in the draft (MAY send on the Managed Cell as well, as mentioned in the draft.), the PDR value is not realistic. The calculation of TIMEOUT in the draft MAY not apply anymore. Instead of a complex calculation, I propose to use a fixed value. The value is the worst case to have a 6P response received on the autonomous SAHRED cell after maxmium re-tries. The worse case means each time when 6P response is failed to send out, it back-off with the largest number of cells (autonomous SHARED cell). Since there is only one autonomous SHARED cell each node, the node will wait for the same number of slotframes. The calculation is like: for maxmium 3 retries: backoff exponent start from 2 and increase each re-transmission 6P Timeout = slotframeDuration * (1 + (2^2-1)+(2^3-1)+(2^4-1) ) > [Section 4.5, Step 4 of the bootstrap process] > https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5 > > tengfei> I don't know whether there is a specification for how the > tengfei> neighbor table should be managed. If no, I think PERSONALLY > tengfei> it's better not keeping the address from pledge in neighbor > tengfei> table. > > Although the actual way to manage neighbor information is > implementation-dependent, the minimal security framework draft > suggests to have separate memory for joined nodes and for pledges > respectively: > > > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6 I see. I am not sure using a neighbor cache is able to avoid the DoS attack. My intuitive thinking is the neighbor cache still has a fixed size. If an attacker sends multiple join requests with fake eui64 address in the packet, it can still fill up the neighbor cache, which blocks other pledges to join. This maybe need to discuss with minimal security scope as well. > > Again, my comment on Section 4.5 is just that, I think we need some > text in "Security Considerations" section for this operation described > in Step 4. And, it seems the term of "the neighbor table" in the Step > 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may > think L2 neighbor table. > I agree! > > > [Appendix-B, SAX configuration] > > tengfei> This is a pre-configured (offline) for interoperability > tengfei> purpose only. > > It's better to mention how a pledge gets the SAX parameters used in > the network where it is trying to join. There are always two options: > > - pre-configured > - advertised in EBs > Agreed. > > Best, > Yatch > -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
Thank you, Tengfei. Additional and following-up comments: [Section 5.1, what to do after timeout of a 6P transaction] https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5 The draft does not say anything about how to handle timeout of a 6P transaction. I know, the initiator of the timed out transaction will resend a 6P request to the same peer ;-) But, it's better to mention that as well as the maximum number of retries if we have. [Section 9, 6P Timeout Value] https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9 A couple of questions: - "C" includes the autonomous cell to the neighbor or it is the number of the managed cells? - How can the timeout value be calculated while PDR is not available? [Section 4.5, Step 4 of the bootstrap process] https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5 tengfei> I don't know whether there is a specification for how the tengfei> neighbor table should be managed. If no, I think PERSONALLY tengfei> it's better not keeping the address from pledge in neighbor tengfei> table. Although the actual way to manage neighbor information is implementation-dependent, the minimal security framework draft suggests to have separate memory for joined nodes and for pledges respectively: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6 Again, my comment on Section 4.5 is just that, I think we need some text in "Security Considerations" section for this operation described in Step 4. And, it seems the term of "the neighbor table" in the Step 4 is ambiguous. Some may think it's IPv6 neighbor cache, some may think L2 neighbor table. [Appendix-B, SAX configuration] tengfei> This is a pre-configured (offline) for interoperability tengfei> purpose only. It's better to mention how a pledge gets the SAX parameters used in the network where it is trying to join. There are always two options: - pre-configured - advertised in EBs Best, Yatch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
