Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

Hi Christian, > On 10 Sep 2022, at 12:30, Christian Amsüss wrote: > > * Do RFCs 9030/9031 allow that a device uses an explicit frame counter, > which it increments in its own pace? As mentioned, we’ve made every attempt to make RFC 9031 applicable to non-TSCH use cases, as well. Construction

Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

> On 20 Sep 2021, at 12:54, Christian Amsüss wrote: > I originally thought I'd just take a K1 and K2 and the existing key > usage table, but these are actually 6TiSCH specific. It'd be quite a > waste to repeat the 14 modes to say the same about any other MAC > (especially as using the K1/K2

Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

challenge I foresee at this point is the notion of time. The use cases you mention are bound to 15.4 radios. Do you see this effort potentially useful for other low-power radio technologies? Mališa -- Mališa Vučinić Research Scientist, Inria Co-chair, IETF LAKE > On 20 Sep 2021, at 11:13, Christ

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

Hi Ben, There has been an extensive discussion on this issue in the WG. As Tengfei stated, since MSF operates exclusively at L2, reading DSCP values from the IPv6 header would constitute a layer violation. It was decided that MSF would implement the recommendation from

Re: [6tisch] hepherd write up for draft-ietf-6tisch-msf: IPR statement

I’m not aware of any IPR that applies to this draft. Mališa > On 12 Dec 2019, at 18:32, Prof. Diego Dujovne > wrote: > > “I’m not aware of any IPR that applies to this draft” > > Le jeu. 12 déc. 2019 à 14:31, Pascal Thubert (pthubert) > a écrit : > Dear all > >

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

Dear all, We’ve just published the -15 revision of the minimal-security document that resolves the remaining points from the IESG review. Mališa > On 10 Dec 2019, at 10:40, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts >

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

min Kaduk wrote: > > Whoops, this got lost in my inbox; thanks for the (out-of-band) reminder. > Luckily, basically all of it is include in the -14 and looks good, so I > have very little left to say :) > > On Thu, Nov 07, 2019 at 05:23:37PM +0100, Mališa Vučinić wrot

Re: [6tisch] MSF adapts to traffic only for secured packets

The “join rate” parameter takes care that any single JP at the edge of the network does not inject too much traffic. But this traffic is forwarded along multiple hops towards the root, and therefore gets aggregated with (join) traffic from other JPs in the network. The purpose of the traffic

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

This text should end up in the next version of the MSF draft, as it is the scheduling function that triggers 6P to add/delete cells. We added some text on it already for the security considerations, what remains to be done is to align the MSF algorithm with the requirement of not adapting to

Re: [6tisch] Adam Roach's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Dear Adam, Please note that we have just published a new version of the minimal-security document addressing, we believe, all the issues raised in your review. Could you take a look? Thanks. Mališa > On 2 Nov 2019, at 22:40, Michael Richardson wrote: > > > Adam Roach wrote: >>> How/where

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Dear Ben, We have just published a new version of the minimal-security document addressing, we believe, all your remarks. Would you mind checking it out, please? Mališa > On 19 Nov 2019, at 09:06, Michael Richardson wrote: > > On 2019-10-31 2:24 a.m., Benjamin Kaduk via Datatracker wrote:

Re: [6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-minimal-security-14: (with COMMENT)

Dear Mirja, Thank you for the prompt reaction! The Parameter Update Response message has been removed in the latest version as it was indeed redundant given that the Parameter Update Message is a CoAP CON. Thank you for that remark! Regards, Mališa > On 5 Dec 2019, at 15:30, Mirja Kühlewind

Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Just a quick note on this as I am going through the mails in preparation for the WG meeting: The intended text was to state that the provisioning of the network identifier is RECOMMENDED for the pledge, while it is a MUST for the *6LBR* pledge. The distinction between 6LBR pledge and pledge is

Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

Dear Ben, Many thanks for the in-depth review. In this email I am responding inline to most of the COMMENT points, in order to converge on those first. For the rest, I created bitbucket issues that we will discuss as part of the WG meeting in Singapore and get back to you. The resulting

Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

Dear Éric, Many thanks for your review. You can find the responses to your comments inline and the overall diff following your review at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8e04a2e442cca81c18809b5d6e88ed0d01d012ea?at=minimal-security-14

Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

Dear Alvaro, Many thanks for your review. I responded to your comments inline and you can find the proposed changes in the working version of the document at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/408b01c51282aa2cf04407de2bf6fcf0a4628a95

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

Dear all, The version -13 of the minimal-security draft addresses the received OPSDIR and SECDIR reviews, and fixes a couple of nits that were found in the previous version related to outdated references and the stateless token draft. Mališa > On 28 Oct 2019, at 18:44,

[6tisch] Security review of draft-ietf-6tisch-minimal-security-12

Dear Hilarie, Thank you for going over the document. Please see the responses inline. Proposed changes to the working version of the document following your review can be found at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/8d77145e63531b604a7d4df4197515ffebde0927

Re: [6tisch] Genart last call review of draft-ietf-6tisch-minimal-security-12

Dear Vijay, I just wanted to thank you for going over the document, it is much appreciated! Mališa > On 18 Oct 2019, at 18:18, Vijay Gurbani via Datatracker > wrote: > > Reviewer: Vijay Gurbani > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area >

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

Maybe add a note stating "this ASN is completely > different from the BGP's ASN". > > Linda > > -Original Message- > From: Mališa Vučinić <mailto:malisa.vuci...@inria.fr>> > Sent: Monday, October 07, 2019 10:39 AM > To: Linda Dunbar <mailto:lind

Re: [6tisch] Opsdir last call review of draft-ietf-6tisch-minimal-security-12

Dear Linda, Many thanks for your review. Please find the responses inline. Kind regards, Mališa > On 5 Oct 2019, at 01:54, Linda Dunbar via Datatracker > wrote: > > Reviewer: Linda Dunbar > Review result: Has Nits > > Reviewer: Linda Dunbar > Review result: Has Nits & with comment > > I

Re: [6tisch] Intelligent JP / validating the MASA

Hello Pascal, The issue that Ben outlines was solved through two separate mechanisms that are detailed in draft-ietf-6tisch-minimal-security: 1) The traffic that JP redirects into the network on behalf of unauthenticated pledges is tagged using IPv6 DSCP such that it can be distinguished from

Re: [6tisch] ASN replay attack -- proposed text

ation? > > All the best, > > Pascal > >> -Original Message- >> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Thomas Watteyne >> Sent: vendredi 26 juillet 2019 17:08 >> To: Mališa Vučinić >> Cc: 6tisch <6tisch@ietf.org> >&

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

Dear all, This is a version of the minimal-security draft that incorporates the resolutions to the two issues discussed during the Montreal meeting: ASN replay attack and the usage of different authentication tag lengths with the same CCM key. Mališa > On 29 Jul 2019, at 17:59,

[6tisch] ASN replay attack -- proposed text

Dear all, I worked on the initial version of the text describing the ASN replay attack and its resolution discussed during the Montreal meeting. The text can be found at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31 Please

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

the JRC must ensure that it never assigns short addresses that were > already > given to this or other nodes with the same keys. In other words, the > network > must be rekeyed before the JRC runs out of short addresses. > > > These issues is are discussed

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

; >> -Original Message- >> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson >> Sent: mercredi 26 juin 2019 17:49 >> To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= >> Cc: Pascal Thubert (pthubert) ; 6tisch@ietf.org; Tero >> Kivi

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

> On 25 Jun 2019, at 17:36, Michael Richardson wrote: > > > Mališa Vučinić wrote: >> Instead, as with traditional TSCH, the joined node can obtain its time >> information from its time source neighbor, i.e. RPL preferred parent, >> by triggering an exchang

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

>> From: David Mandelberg >> Sent: mardi 25 juin 2019 02:31 >> To: Tero Kivinen ; Pascal Thubert (pthubert) >> >> Cc: sec...@ietf.org; i...@ietf.org; >> draft-ietf-6tisch-architecture@ietf.org; >> Thomas Watteyne ; Michael Richardson >> ; Mališa Vuč

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

Dear all, The version -11 of minimal-security resolves comments raised in the shepherd’s review, thanks Pascal. Mališa > On 13 Jun 2019, at 17:42, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work

Re: [6tisch] shepherd review of draft-ietf-6tisch-minimal-security

Hello Pascal, Thanks for the review. See resolutions and some comments inline. Mališa > On 12 Jun 2019, at 11:54, Pascal Thubert (pthubert) > wrote: > > Dear authors; > > As part of shepherding the draft for publication, please find review comments > below: > > Very well written draft

Re: [6tisch] shepherd write up for draft-ietf-6tisch-minimal-security: IPR statement

I’m not aware of any IPR that applies to this draft. Mališa > On 12 Jun 2019, at 10:39, Pascal Thubert (pthubert) > wrote: > > Dear all > > It is time to publish draft-ietf-6tisch-minimal-security, and use part of the > process I need to confirm whether there is IPR on this specification.

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

Dear all, We have submitted the new version of the minimal-security draft fixing the remaining issues that were brought during the 2nd WGLC and the Prague meeting. In particular, this version: - Resolves the JRC failure issue by relying on the mechanism specified in OSCORE Appendix B.2 -

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

> On 5 Apr 2019, at 20:15, Michael Richardson wrote: > > If we could delay the switch to the new schedule until *after* > COJP_REKEYING_GUARD_TIME has elapsed, then that might work. > Alternatively, if we could number the rekeys then a EB could signal the > switch to the new schedule some time

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

On 5 Apr 2019, at 20:22, Michael Richardson wrote: > > Also so that the many unicast conversations needed to do the rekey can be > spread > across a large amount of time, letting the JRC reach out to even very sleepy > nodes. Good point indeed, sleepy nodes may miss the reception slots and

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

The original intent was to allow the pledge to signal “I can act on this parameter but not on that value that you gave me”, cherry-picking specific keys from the key set or just copying the whole thing if nothing works. The previous text optimized for that by mandating the value or its

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

to avoid having to know the network notion of time at the JRC. Mališa > On 4 Apr 2019, at 19:33, Mališa Vučinić wrote: > > My understanding is that the problem in the permuted schedule arises during > COJP_REKEYING_GUARD_TIME after nodes in the network started using the new >

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

My understanding is that the problem in the permuted schedule arises during COJP_REKEYING_GUARD_TIME after nodes in the network started using the new keys, but have still kept the old key in case someone has not yet switched. When coupled with a rekeyed permutation key to calculate the

Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

Should be covered in https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 Mališa > On 4 Apr 2019, at 16:04, Michael Richardson wrote: > > I was looking for some text from

Re: [6tisch] Progress zero-touch document

How about we form a focused design team to start working out the details and we can do the editorial work and publish once the EDHOC decision is out? Mališa > On 2 Apr 2019, at 17:04, Michael Richardson wrote: > >> >> What are your thoughts on this? > > If you want to start now, please go

Re: [6tisch] Progress zero-touch document

Hello Pascal, Are you suggesting that we should start working out the details on using EDHOC but keep an alternative as an appendix in the document? Since we have stalled on this work for some time for reasons outside of the working group control, I think it would make sense to catch up.. Let

[6tisch] Progress zero-touch document

Michael, all, With the EDHOC specification finally seeing progress (see [1]), it seems like a good time to restart the work on zero touch and progress the adopted working group document. Reading the current version of draft-ietf-6tisch-dtsecurity-zerotouch-join-03, it seems that there are

Re: [6tisch] [Secdispatch] EDHOC Summary

+1 We are happy to contribute to this effort through feedback on the design, implementation for constrained devices and its evaluation in 6TiSCH networks. Mališa > On 30 Mar 2019, at 18:31, Thomas Watteyne wrote: > > The 6TiSCH WG has produced a set of documents [1,2] that specify the use of

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

ecified". > > Göran > > On 2019-03-27, 23:16, "Mališa Vučinić" wrote: > >Dear Göran, > > >Many thanks for the review! As we discussed during the WG meeting, I added > new text in the draft to stress that the procedure in Appendix B.2 of OSCO

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Hello Christian, The intent was indeed to differentiate between “I cannot do what is requested with parameter X” and “I understand parameter X but not what you are asking me to do with it”. To avoid ambiguity, I now use the terms “unsupported” and “malformed” as code values. Essentially,

Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Hello Christian, Thank you for summarizing the discussion we had and proposing these changes. I have modified the text in order to reflect the email below by: - encoding additional info as a CBOR array allowing multiple parameters to be transported within - removing the previous error code

Re: [6tisch] 2nd WG LC on draft-ietf-6tisch-minimal-security

Dear Göran, Many thanks for the review! As we discussed during the WG meeting, I added new text in the draft to stress that the procedure in Appendix B.2 of OSCORE should be used in the case of a failure event occurring at the JRC. The use of this procedure is now RECOMMENDED, and in case it

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Thanks Pascal, looks good! Mališa On Wed, Dec 12, 2018 at 1:51 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > Please see below ( I pushed the result in the repo, please let me know if > we are OK now ) > > > > *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal, Most of the resolutions to my comments look good. Couple of nits inline. Mališa *[PT>] *I think we need to define an entry for CoJP, similar to 6P. What > about; > >CoJP (Constrained Join Protocol): CoJP is a one-touch join protocol > >defined in the Minimal

Re: [6tisch] POST WGLC: draft-ietf-6tisch-architecture-18.txt

Hello Pascal, Michael, I just opened a pull request on bitbucket rewriting the join process description. The PR is at: https://bitbucket.org/6tisch/draft-ietf-6tisch-architecture/pull-requests/1/update-join-process-description/diff Could you take a look and if you agree, refine further.

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

Hello Pascal, Here are my comments on draft-ietf-6tisch-architecture. I used the latest version of the draft hosted on bitbucket. In general, an editorial pass on the whole document would be useful, there are some typos here and there. The main issue I see is that Section 6.1 is completely

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

Dear all, We submitted the -09 version of the minimal-security draft, incorporating the changes discussed during IETF 103 and summarized in the "Updates for minimal-security-09" ML thread: - Adding optional join rate parameter to Join Response. This enables JRC to manage JPs. - Aligning normative

[6tisch] Updates for minimal-security-09

Hi all, As discussed during IETF 103, here is a list of proposed changes for minimal-security-09 that we will use for the second WGLC: - Add "join rate" parameter in the Configuration structure present in Join Responses and Parameter Update requests: As discussed during IETF 103, allowing the

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

Dear all, We have just submitted version -08 of minimal-security resolving, to our knowledge, last remaining issues raised during the WGLC. I will discuss *some* of these resolutions tomorrow during the IETF 103 presentation but for completeness, please go ahead and take a look at the document

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

Hi Göran, Thanks for the feedback and the proposal. I added Appendix B detailing this deployment option: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b93e8fa6152eb2bb10761264bcf8e47f861fd418 Let me know if the current text works for you. Also, regarding the comment

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

tion 2 use the updated reference to RFC 8174 >2. In section 4 – You might want to make it explicit as one of the >item that the pledge identifier is provisioned. > > > > *From:* Mališa Vučinić > *Sent:* Tuesday, October 23, 2018 7:07 AM > *To:* Göran Selander ; Xavi

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

Dear WGLC reviewers, working group, We submitted a new version of minimal security incorporating the resolution of most of the issues raised during WGLC. There are two remaining issues that still need to be resolved, and I hope to publish these in an additional version after the draft submission

[6tisch] WGLC issues to be addressed for minimal-security-07

Dear all, I converted the extensive email and F2F discussions during the last two months around the minimal-security draft into a list of issues to be resolved. The list with relevant email discussion snippets is at:

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

On Fri, Sep 7, 2018 at 6:30 PM Tero Kivinen wrote: > Mališa Vučinić writes: > > Yes, I think it can be made to work, but I think it is quite a lot of > > work and code just to be able to claim to be "stateless". > > > > I don't quite agree that what

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

Hi Tero, Just getting back to this after my vacation, see inline. Mališa On Fri, Jul 27, 2018 at 8:25 PM Tero Kivinen wrote: > Mališa Vučinić writes: > > > > The question now is when to remove the entry with secExempt for > > pledge at JP, once it was installed from

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

after a while anyway and thus leaking it would not be a huge > problem. Depending on value of the data, the JRC could generate new data > for the message to the pledge. > > > > Jim > > > > > > *From:* Mališa Vučinić > *Sent:* Wednesday, July 18, 2018 12:

Re: [6tisch] 6tisch minimal -- when can/should JP throw-away/blacklist pledges?

Michael, See inline. Mališa On Fri, Jul 27, 2018 at 12:04 AM Michael Richardson wrote: > > (Listening to the youtube recording) > > Tero clarified the slide 8, about when the JP could throw away the > neighbour > state, and whether or not the JP could blacklist a pledge. > > The JP is not

Re: [6tisch] Link_Layer_Key

Thanks for the clarification. I still have a couple of misunderstandings, see inline. Mališa On Thu, Jul 19, 2018 at 12:47 AM Tero Kivinen wrote: > Mališa Vučinić writes: > > Thanks Tero for the proposal. Is the current "key_usage" registry enough > to > > fully c

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

wants to update the > endpoint. > > > > Jim > > > > > > *From:* Mališa Vučinić > *Sent:* Tuesday, July 17, 2018 1:22 PM > > > *To:* Jim Schaad > *Cc:* 6tisch@ietf.org > > *Subject:* Re: Review draft-ietf-6tisch-minimal-security > > > &g

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

On Tue, Jul 17, 2018 at 10:25 PM Tero Kivinen wrote: > If JRC restarts and looses track who is in the network, then it cannot > send updaes, as it does not know who is in the network. I.e., in that > case all nodes need to rejoin. > How do we detect that JRC restarted at 6LBR if JRC is in the

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

On Wed, Jul 18, 2018 at 2:36 AM Tengfei Chang wrote: > Hi Malisa and Tero, > > Thanks for answering my question! It is clear to me! > > I don't fully understand. Do you mean in which case would a node send >> another Join Request, if it has already completed the join process sometime >> before

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

(snip) On Tue, Jul 17, 2018 at 10:13 PM Tero Kivinen wrote: > > I would like at least some text in the security considerations section > warning about the common wrong ways of generating PSK. The IoT vendors > are quite often care more about the time to market than the security, > thus do use

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

ach update of the OSCORE Replay Window MUST be written to persistent memory. In the text above, there is a typo: s/Section 6.5.1/Section 7.5.1 Let me know if I am missing something else to add regarding this. Mališa On Tue, Jul 10, 2018 at 3:20 PM Jim Schaad wrote: > > > > > *From:

Re: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

Hi Tengfei, Thanks for your review! See my responses and proposed resolutions inline. Mališa On Mon, Jul 9, 2018 at 3:44 PM Tengfei Chang wrote: > Hi Malisa, > > I just reviewed the draft and have several comments below. > > *Comment 1: * > *--* > In section 9.3.2 when

Re: [6tisch] comments to the “Minimal Security Framework for 6TiSCH” document

Hi Xavi, Many thanks for sending this review. See my responses inline. Mališa On Fri, Jun 29, 2018 at 5:37 PM Xavi Vilajosana Guillen wrote: > Hi, > > I reviewed the ”Minimal Security Framework for 6TiSCH” document. > > Here some comments that have not been mentioned by others. > > 1) I miss

Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

Hi Tero, Thank you for this extensive review! See my responses inline. Mališa On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen wrote: > In section 3 there is text saying: > >The "network identifier" uniquely identifies the 6TiSCH network in >the namespace managed by a JRC. Typically,

Re: [6tisch] preliminary 6TISCH@IETF102 agenda

Hi Thomas, Pascal, For the minimal-security slot, if possible, I would need an additional 5-10 minutes. We received lots of good reviews and I would like to get input on some of the issues during the meeting. Let me know if feasible. Mališa On Tue, 3 Jul 2018 at 14:28, Thomas Watteyne wrote:

Re: [6tisch] WGLC on the “Minimal Security Framework for 6TiSCH” document

Hello Göran, Thanks for the review. See my responses inline. Mališa On Wed, Jun 27, 2018 at 3:46 PM Göran Selander wrote: > Dear WG, Pascal, Thomas, > > I have reviewed draft-ietf-6tisch-minimal-security-06 and have the > following feedback: > > > > Section 3 > > > "pledge identifier" > > >

[6tisch] Fwd: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages

Forwarding this review to the ML as part of the WGLC. -- Forwarded message - From: William Vignat Date: Tue, Jul 3, 2018 at 3:03 PM Subject: Concerns about the CoJP message size, the need for BLOCK-WISE options and the use of NON-confirmable messages To:

Re: [6tisch] Review draft-ietf-6tisch-minimal-security

Hi Jim, Thanks a million for going through the document. Regarding the problem you outline where the pledge first joins to JRC1 and then later to JRC2, this would correspond to the change of ownership of the pledge, without going through the trouble of re-provisioning the pledge with a new

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

All, As per the discussions last weeks, I submitted the -06 version of the minimal-security draft. This -06 version will be used for the F-Interop 6TiSCH plugtest to be held in Paris on 26-27 of June. Kind regards, Mališa On Fri, May 25, 2018 at 7:23 PM wrote: > >

Re: [6tisch] On minimal-security

On Thu, 24 May 2018 at 20:44, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Mališa Vučinić <malis...@gmail.com> wrote: > > @Michael, @Christian > > > I am re-reading RFC7252, Section 5.7.2: > > okay, but I'm not claiming that the Join Pro

Re: [6tisch] Updates to minimal-security-06

All, I resolved the issues we had open on minimal-security and reworked editorially the document quite heavily. Since the protocol we define is quite generic, I renamed it to "Constrained Join Protocol (CoJP)", suggested pronunciation as "cojeep". Let me know if you dislike the new name, or if

Re: [6tisch] On minimal-security

@Michael, @Christian I am re-reading RFC7252, Section 5.7.2: Unless a proxy is configured to forward the proxy request to another proxy, > it MUST translate the request as follows: the scheme of the request URI > defines the outgoing protocol and its details (e.g., CoAP is used over UDP > for

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

@Tero, Getting back to this, see inline. On Thu, May 17, 2018 at 12:36 AM Tero Kivinen <kivi...@iki.fi> wrote: > Mališa Vučinić writes: > > Thanks Tero for this feedback! Could you check if this commit takes care > of > > it: > > > > > https://bitbuck

Re: [6tisch] On minimal-security

Hi Pascal, See responses inline. Mališa On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > As you are getting ready to publish a next rev, please find simple > comments on 05 that you may want to act upon in 06. > > > > ·As

[6tisch] A terminology issue in minimal-security: (6LBR) pledge

All, With the latest developments on minimal-security-06, we have homogenized the join protocol so that it equally applies to regular pledges and the 6LBR device. Essentially, 6LBR just sets some parameters differently in the request, and it receives the keys, network prefix and PAN ID of the

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

from the key length, I also added the nonce length in the description of the algorithm in the registry. Mališa On Tue, May 15, 2018 at 11:47 PM Tero Kivinen <kivi...@iki.fi> wrote: > Mališa Vučinić writes: > > I also worked out a new key signaling mechanism using a "ke

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

On Tue, May 15, 2018 at 8:54 PM Michael Richardson wrote: > > > > I generalized the rekeying text so that it falls under the > processing rules > > of the CBOR Link-Layer Key parameter. The first join of a pledge just > > becomes a special case but there is a

Re: [6tisch] On minimal-security

Thanks for this review, Pascal. I went quickly through your comments and I should be able to fix all of this for -06. My goal is to have -06 ready for WGLC. On Tue, May 15, 2018 at 4:00 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > Hello Mališa > > > > As you are getting ready to

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, See inline. Mališa On Thu, May 10, 2018 at 8:05 PM Michael Richardson wrote: > > I see that you have an IANA registry for the Join Request and Join Response > key values. These tables need to have names and the IANA instruction needs > to ask them to create

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

<mcr+i...@sandelman.ca> wrote: > > Mališa Vučinić <malisa.vuci...@inria.fr> wrote: > mcr> I'd say that you always do this with any new key if you > mcr> have no keys. > mcr> I don't think we need a flag. > > mcr> In fact, even for the

Re: [6tisch] Optimizing Neighbor Discovery during the join process

o do a NS look up. > > > > Also, I do not necessarily agree that the ND phase is that expensive. It > is just a one-hop exchange. > > > > Cheers, > > > > Pascal > > > > *From:* Mališa Vučinić <malisa.vuci...@inria.fr> > *Sent:* jeudi 19 avril

Re: [6tisch] Optimizing Neighbor Discovery during the join process

Pascal, If we were to use the unspecified address, would the following be OK: - Join Request: L3 source: Pledge LL; L3 destination: all-zeros; L2 source: pledge EUI; L3 destination: JP EUI from the Beacon - Join Response: L3 source: all-zeros; L3 destination: pledge LL; L2 source: JP EUI; L2

Re: [6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

Michael, Reviving the discussion on the rekeying mechanism. See below. Mališa >> On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson < >> mcr+i...@sandelman.ca> wrote: >> >>> >>> >>> I'd say that you always do this with any new key if you have no keys. >>> I don't think we need a flag. >>>

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

(I just realized that I forgot to CC the 6tisch ML for the previous exchanges.) See below. On Thu, Apr 19, 2018 at 10:55 AM Christian M. Amsüss <christ...@amsuess.com> wrote: > Hi Mališa, > > On Thu, Apr 19, 2018 at 08:24:57AM +, Mališa Vučinić wrote: > > I agree

Re: [6tisch] Optimizing Neighbor Discovery during the join process

On Wed, 18 Apr 2018 at 19:17, Michael Richardson wrote: > > > Yes, I guess you could call it an ephemeral cache entry > > constructed by CoAP at JP when the join response is received, > > before being forwarded to the pledge. As soon as the packet is > >

Re: [6tisch] Optimizing Neighbor Discovery during the join process

On Wed, 18 Apr 2018 at 18:19, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Mališa Vučinić <malisa.vuci...@inria.fr> wrote: > > We had a couple of side discussions regarding Neighbor Discovery > > (ND) in minimal-security draft. > > > Th

Re: [6tisch] Observe for rekeying (was: Updates to minimal-security-06)

Christian, See inline. Mališa On Thu, Apr 12, 2018 at 3:15 PM Christian M. Amsüss wrote: > > > What would be the advantage of establishing a dynlink over specifying in > > the minimal-security draft that once the pledge joins, it needs to > expose a > > /j resource

[6tisch] Optimizing Neighbor Discovery during the join process

All, We had a couple of side discussions regarding Neighbor Discovery (ND) in minimal-security draft. The problem is that with the current text in minimal-security and the ND exchange between the pledge and the JP, we double the communication overhead on the shared cell and require the JP to

[6tisch] Rekeying for minimal-security (was: Updates to minimal-security-06)

See inline. On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne wrote: > > *About COSE_Key* > > The issue raised is that, during a rekey of key K2 by the JRC, the JRC > cannot specify an ASN from which the new key is to be used. > The JRC would need to guess how long it

Re: [6tisch] Updates to minimal-security-06

the new key end-to-end > ACK'ed, i.e. does the JRC know it got received? > Moving the discussion about the rekeying mechanism to the thread: *Rekeying for minimal-security (was: Updates to minimal-security-06).* > > Thomas > > On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson <

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:39 PM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Mališa Vučinić <malisa.vuci...@inria.fr> wrote: > > in the network. Other than adding the Observe option, together with > the > > new link-layer key we also need t

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:42 PM peter van der Stok wrote: > > No semantic difference that I know. You expressed a worry about > addressing the joining node from JRC. > Not sure any more, but do you use the IP-in-IP proxy? If yes, > maintaining the encapsulation in all

Re: [6tisch] Updates to minimal-security-06

On Thu, Mar 22, 2018 at 5:03 PM peter van der Stok wrote: > > > One doubt I have is how does the JRC send the Observe response to the > > joined node, when the request came over a Join Proxy. Essentially, the > > JRC needs to send the response to the global IPv6 address of

  1   2   >