[6tisch] Updates to minimal-security-06

All, We had a couple of side discussions during IETF 101 on the updates to the minimal security draft. We need to (1) support extensibility to allow future specs to add additional parameters to the join response structure, and it seems that (2) we can cover link-layer rekeying easily through the

[6tisch] v1.0.0 Release of the 6TiSCH Simulator

All, We've just released v1.0.0 of the 6TiSCH simulator, a tool to answer what-if questions through quick performance estimation. This is a high-level Python-based simulator implementing: - protocols - IEEE802.15.4e-2012 TSCH (

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-05.txt

All, I have just submitted a new version of the minimal-security draft. We will be asking for WGLC on this version in London. Changelog: - Introduced tagging of join traffic. This resolution mitigates the vulnerability where the attacker could inject join requests in the network and

[6tisch] Fwd: New Version Notification for draft-chang-6tisch-msf-01.txt

All, We submitted a new version of the Minimal Scheduling Function, resolving the issues raised during the two reviews received since IETF 100. Changelog: - When neighbor is unreachable, sending a CLEAR command was a MUST, now a MAY. - Fixing 6P Timeout calculation. - Clearer text for

Re: [6tisch] Tagging join traffic

So should we stick to AF4x or switch to a lower value? Mališa > On 5 Dec 2017, at 02:05, Michael Richardson wrote: > >> >> - Any particular reason why you chose class 100 i.e. (AF43 and AF42) >> and not any other class from RFC2597? > > I believed at the time that AF1x

Re: [6tisch] Tagging join traffic

> On 1 Dec 2017, at 16:10, Pascal Thubert (pthubert) wrote: > > [Pascal] I'm not sure that the join and the response should have the same > precedence. In a forming network there may be a bunch of both and the > responses should win in case of a collision in a node's

Re: [6tisch] Tagging join traffic

Pascal, See inline. Mališa > On 1 Dec 2017, at 14:32, Pascal Thubert (pthubert) wrote: > > Certainly Mališa. The reason for a different TC is to treat them differently. > The join response represents an investment of resources in the network and an > acceptance by the

Re: [6tisch] Tagging join traffic

Pascal, Yes, it also makes sense from the point of view of an SF, as join is one-shot traffic and we don’t want to allocate cells in response to that, even though the response in the particular case of minimal-security can be trusted. I am arguing that for this particular behavior to be

Re: [6tisch] Tagging join traffic

Pascal, Michael, Since data traffic in the network is treated as DSCP class 000, i.e. best effort, it will necessarily have lower priority over all other classes, including class 100 that we decided to use for join with specific AF43 and AF42 codepoints. This means that both AF43 (join

Re: [6tisch] nbr cache recommendation

Hi Rahul, Thanks for the pointer. I skimmed through the draft but couldn’t find how relay (JP) or new joinee (pledge) should handle each other before the authentication procedure completes. You state: > Relay element does not hold any state information on behalf of the new joinee > node

Re: [6tisch] pending with 6tisch-minimal-security

Michael, I am missing the benefit of a 5.03 or Pending response for network congestion case when join completes in a single round trip. Why not return a join response that fits into a single frame rather than a signal to attempt later? If there is an error at JRC, we stay silent anyways. I

Re: [6tisch] Tagging join traffic

gt; 6tisch.arpa Uri-Host option? I assume that's encrypted end-to-end? > Trying to see whether there is anything, in the current spec, which allows a > forwarding node to identify join traffic... > Thanks, > Thomas > > On Mon, Nov 6, 2017 at 5:46 PM, Michael Richardson <mcr+i.

[6tisch] Tagging join traffic

At the interim today, we discussed the need of tagging join traffic at the Join Proxy (JP). The problem is that JP forwards into the network traffic that originates from untrusted pledges, which can cause the exchange of 6P commands at intermediate nodes on the path from JP to 6LBR. A

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-04.txt

Dear all, We have just submitted a new version of the minimal-security draft that incorporates the changes discussed since the IETF-99 Prague meeting. Namely, the one-touch solution specified in the document now completely relies on PSKs. The new version tracks the changes in the OSCORE-06

Re: [6tisch] draft-richardson-6tisch-roll-join-priority-00 --- RPL DIO message

According to RFC8180, Join Priority/Metric is already calculated as a function of the RPL rank. See Section 6.1. My suggestion was to use that as-is *if* the join is allowed by the binary option in this new IE. > On 21 Jul 2017, at 12:44, Michael Richardson wrote: >

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

with the layer 3 > address of the JRC. > > That makes clearer what goes on. In a first pass of the text, I wondered how > the routing was done. > > Greetings, > > Peter > > Mališa Vučinić schreef op 2017-06-19 15:12: >> Hi Peter, >> I’m missing context on ho

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

pens when more than 1 proxy forwards the > message to the JRC. > > Peter > > Mališa Vučinić schreef op 2017-06-15 11:05: >> All, >> We have just submitted a new version of the minimal-security draft in >> preparation for the plugtest that will be held in Prague. T

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-03.txt

All, We have just submitted a new version of the minimal-security draft in preparation for the plugtest that will be held in Prague. This version (-03) will be referenced by the official test description of the plugtest. The most notable changes are: - pledge-initiated EDHOC handshake with

Re: [6tisch] Terminology for minimal security

Hi Mohit, Thanks a bunch for going over the draft and the presentation. The “Key” is literally a text string differentiating between a key being derived or an IV. For more details please see Section 3.2.1 of OSCOAP draft or for instance section 7.3 of TLS 1.3 draft. I agree with you that key

Re: [6tisch] EDHOC and EALS use in 6tisch (minimal) bootstrap

+1 on adopting the EDHOC work in ACE. To add to Michael’s summary, I would also like to stress that in draft-ietf-6tisch-minimal-security the one-hop neighbor of a pledge (joining node) plays the role of an untrusted CoAP proxy in order to facilitate pledge’s communication with the Registrar.

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-02.txt

All, We have submitted a new version of the minimal security draft reflecting latest work within the security design team. I would like to request a slot to present this version (remotely) during the Chicago meeting. Regards, Mališa > On 12 Mar 2017, at 21:11, internet-dra...@ietf.org wrote:

Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-01.txt

Hello Pascal, Yes, I noted that yesterday and created a ticket at internet-dra...@ietf.org . I have no idea how the tool picked up my former email address, especially because during submission metadata was in order. Hopefully, they will be able to help. Mališa

Re: [6tisch] xxx-bootstrap

Hi Peter, See inline. Mališa > On 16 Dec 2016, at 09:17, peter van der Stok wrote: > > Hi Malisa, > > Just one point to understand the temporary secure link between JN and JA. > >>> Consequently, that means during the whole bootstrap process the link >>> between JA and

Re: [6tisch] xxx-bootstrap

hat JA knows JCE’s global address for the communication to take place. > What about securing a heterogeneous network of which the 6tisch network > happens to be part? The link-layer keys will not be adequate in that case. I don’t understand the use case, could you provide some more details?

Re: [6tisch] xxx-bootstrap

how the bootstrap can be composed of different > standardized parts and where the future evolution is. > Identifying and describing those parts will be a nice step forward. > > Peter > > > Mališa Vučinić schreef op 2016-11-30 10:22: >> Hello Peter, >> My

Re: [6tisch] xxx-bootstrap

Hello Peter, My understanding of the IETF 97 meeting outcome is that Phase 1 solution will be anima-compatible i.e., it will provide zero-touch bootstrapping with manufacturer-installed certificate as the start state and locally relevant credential as the end state. At the moment, I believe

Re: [6tisch] Adding CCA to the terminology draft

Hi Maria Rita, The term Joining Node (JN) or Pledge is missing. I would also remove the reference to PCE in the definition of JCE at this point. In the definition of JA, I would also stress that JA emits EBs, used for JN to synchronize to the network. My 5c. Mališa > On 22 Nov 2016, at

Re: [6tisch] questions about draft-richardson-security-6top

On 12 May 2015, at 12:52, Michael Richardson mcr+i...@sandelman.ca wrote: A power and compute-saving thing for the JCE to do would be to have the JN provide the JCE with a session-resumption ticket... and for the JCE to pass that onto the PCE. This seems like a great idea for nodes that

Re: [6tisch] security section in minimal

The text seems to capture the compromise. +1 Mališa On 10 May 2015, at 21:24, Xavier Vilajosana xvilajos...@eecs.berkeley.edu wrote: Dear all, after the last call we would like to close the security section in minimal. We wrapped up all comments from the previous days and from the

<    1   2