Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
Mališa Vučinić wrote: > 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 tagged traffic. I think that Mirja wanted a pointer to this. I thought that it was in the architecture as well, but I couldn't find it. I hope that an informative reference is enough so that we aren't delayed. >> On 5 Dec 2019, at 15:47, Michael Richardson wrote: >> >> >> Mirja Kuehlewind wrote: > I would think it > either sets it to AF43 or it does nothing about it because DSCP is not > really used in that network. In 6tisch networks, different DSCP points can be used to get different behaviours, see UHM. Let me get back to you on this, because the reference has evaporated. >> >>> A reference would be good (in the draft) :-) >> >> Hi, we had a long discussion about setting DSCP points on upward and downward >> traffic. We had said that these code point would *not* cause 6P to add bandwidth. >> Where did we say that? I feel like that the reference has gone away. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
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 tagged traffic. Mališa > On 5 Dec 2019, at 15:47, Michael Richardson wrote: > > > Mirja Kuehlewind wrote: I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. >>> >>> In 6tisch networks, different DSCP points can be used to get different >>> behaviours, see UHM. Let me get back to you on this, because the >>> reference has evaporated. > >> A reference would be good (in the draft) :-) > > Hi, we had a long discussion about setting DSCP points on upward and downward > traffic. We had said that these code point would *not* cause 6P to add > bandwidth. > Where did we say that? I feel like that the reference has gone away. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
Mirja Kuehlewind wrote: >>> I would think it >>> either sets it to AF43 or it does nothing about it because DSCP is not >>> really used in that network. >> >> In 6tisch networks, different DSCP points can be used to get different >> behaviours, see UHM. Let me get back to you on this, because the >> reference has evaporated. > A reference would be good (in the draft) :-) Hi, we had a long discussion about setting DSCP points on upward and downward traffic. We had said that these code point would *not* cause 6P to add bandwidth. Where did we say that? I feel like that the reference has gone away. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
Mirja Kuehlewind wrote:
> Sorry for my late reply (but I guess you could have just went ahead and
> push a new version anyway…). Please see below.
My edits went into a new version which Malisa did push out.
>>
>>
>>> Further on there seems to be an implicit requirement that
>>> the JP MUST implement rate limit using the PROBING_RATE parameter,
>>> however, that is never explicitly spelled out as a normative
>>> requirement. However, if this rate is not provided by the JRC, it
>>> doesn't seem that any rate limiting has to be enforced. So maybe it
>>> would be good to be more strict here.
>>
>> I think you are saying that we should have a default PROBING_RATE, if
the JRC
>> does not specify one. I think that we assumed that the RFC7257 section
4.8
>> value of 1 byte/second would apply. please confirm?
> Yes, stating this explicitly would be good!
-Following {{RFC7252}}, the average data rate in sending to the JRC must not
exceed PROBING_RATE.
+Following {{RFC7252}}, the average data rate in sending to the JRC must not
exceed PROBING_RATE, which specifies a default of 1 byte/second.
>>> 2) Also, not sure if this editorial or a real issue but I'm not sure I
>>> fully understand this sentence:
>>
>>> Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
>>> forwarded should set it to zero so that it is compressed out." If the
>>> proxy does NOT SET DSCP, why should it SET it to zero?
>>
>> Because RFC6282 (and friends) has specific encoding to omit DSCP if it
is zero.
> I understand what you want to do but saying “does not set” but “should
> set” seems to be contracting. I think this is only a wording issue
> though. I guess it could be something like this:
> "A Join Proxy that does not require a specific DSCP value on traffic
> forwarded should set it to zero so that it is compressed out.”
Done.
>>> 3) This may also be mostly editorial but just to be sure: Section 7..2
>>> provides default values for some of the CoAP transport parameter (where
>>> 2 of 3 are the same as defined in RFC7252) but not for all. Why is
>>> that?
>>
>> We got pushback about relying on 7252 defaults, because what if they
changed.
> That’s fine but the you need to add all values!
Malisa?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
Regards, Pascal > Le 5 déc. 2019 à 04:06, Mirja Kuehlewind a écrit : > > Hi Michael, > > Sorry for my late reply (but I guess you could have just went ahead and push > a new version anyway…). Please see below. > >>> On 1. Nov 2019, at 22:15, Michael Richardson wrote: >>> >>> >>> <#secure method=pgpmime mode=sign> >>> >>> Mirja Kühlewind via Datatracker wrote: >>> 1) I hope this point can be resolved quickly as it seems to only need a >>> bit more specifics but I think this part is not sufficient: >> >>> Sec 6.1: "The Join Proxy implements a data cap on outgoing join traffic >>> through CoAP's congestion control mechanism." >> >>> I think this needs an normative requirement here. Congestion control is >>> supposed to avoid network overload but also to make use available >>> resources. The congestion control as currently defined for CoAP would >>> probably limit the join traffic appropriately (to something like one >>> packet per RTT likely) but CoAP could in theory use any time a >>> different more aggrieve congestion and therefore just relying on >>> congestion control generically doesn't seem to be sufficient. >> >>> I >>> recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per >>> 3 seconds if RTT is unknown (as recommended in RFC8085) and say that >>> this can be achieved by congestion control as specified in the base >>> CoAP spec. >> >> okay, how about: >> >> + The Join Proxy implements a data cap on outgoing join traffic by >> implementing >> + the section 3.1.3 recommendation of 1 packet per >> 3 >> + seconds. >> + This can be achieved with the congestion control mechanism specified >> + in section 4.7. > > Great! Thanks! > >> >> >>> Further on there seems to be an implicit requirement that >>> the JP MUST implement rate limit using the PROBING_RATE parameter, >>> however, that is never explicitly spelled out as a normative >>> requirement. However, if this rate is not provided by the JRC, it >>> doesn't seem that any rate limiting has to be enforced. So maybe it >>> would be good to be more strict here. >> >> I think you are saying that we should have a default PROBING_RATE, if the JRC >> does not specify one. I think that we assumed that the RFC7257 section 4.8 >> value of 1 byte/second would apply. please confirm? > > Yes, stating this explicitly would be good! > >> >>> 2) Also, not sure if this editorial or a real issue but I'm not sure I >>> fully understand this sentence: >> >>> Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic >>> forwarded should set it to zero so that it is compressed out." If the >>> proxy does NOT SET DSCP, why should it SET it to zero? >> >> Because RFC6282 (and friends) has specific encoding to omit DSCP if it is >> zero. > > I understand what you want to do but saying “does not set” but “should set” > seems to be contracting. I think this is only a wording issue though. I guess > it could be something like this: > > "A Join Proxy that does not require a specific DSCP value on traffic > forwarded should set it to zero so that it is compressed out.” > > >> >>> I would think it >>> either sets it to AF43 or it does nothing about it because DSCP is not >>> really used in that network. >> >> In 6tisch networks, different DSCP points can be used to get different >> behaviours, see UHM. Let me get back to you on this, because the >> reference has evaporated. > > A reference would be good (in the draft) :-) > >> >>> 3) This may also be mostly editorial but just to be sure: Section 7.2 >>> provides default values for some of the CoAP transport parameter (where >>> 2 of 3 are the same as defined in RFC7252) but not for all. Why is >>> that? >> >> We got pushback about relying on 7252 defaults, because what if they changed. > > That’s fine but the you need to add all values! > >> >>> 4 ) And then finally on references (again): Given that use of >>> I-D.ietf-core-stateless is recommend, I believe it should be normative >>> (and wait for publication of that doc). >> >> I guess since it's a MUST for the JRC, we need to do that. > > Good. Thanks! > > >> >>> -- >>> COMMENT: >>> -- >> >>> I'm putting this one question in the comments section because there is >>> no concern that it does not work as specified but I wonder about the >>> design of the Parameter Update Response Message. Given the Parameter >>> Update Message is a confirmable CoAP message that is transmitted >>> reliable and the content of the Parameter Update Response Message is >>> empty, why do you need to send the Parameter Update Response Message at >>> all? >> >>> And some minor comments (mostly editorial proposals): >> >>> 0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document >>> title to make clear that this is a protocol spec and not "only" and >>> abstract framework or
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 made in the terminology section. Here is the change I made in the document to make this clear: -Provisioning the network identifier is RECOMMENDED. +Provisioning the network identifier to a pledge is RECOMMENDED. The excerpt now reads: "Provisioning the network identifier to a pledge is RECOMMENDED. However, due to operational constraints, the network identifier may not be known at the time when the provisioning is done. In case this parameter is not provisioned to the pledge, the pledge attempts to join one advertised network at a time, which significantly prolongs the join process. This parameter MUST be provisioned to the 6LBR pledge." As per 8.4.1, the parameter is mandatory to be included in the CoJP request. Pledge obtains its value from the enhanced beacon frames for the network it is currently attempting to join, while the 6LBR pledge must have been provisioned with it. Let me know if this clarifies. Mališa > On 1 Nov 2019, at 22:15, Michael Richardson wrote: > >> >> 1) Sec 3: Maybe I'm missing something but this seems contradictory: >> "Provisioning the network identifier is RECOMMENDED." And then at the >> end of that paragraph: "This parameter MUST be provisioned to the 6LBR >> pledge."+ > > You are right. The last sentence does not belong. > During the join process, the network identifer, returned in the CoJP response > is a MUST (8.4.1) ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
<#secure method=pgpmime mode=sign> Mirja Kühlewind via Datatracker wrote: > 1) I hope this point can be resolved quickly as it seems to only need a > bit more specifics but I think this part is not sufficient: > Sec 6.1: "The Join Proxy implements a data cap on outgoing join traffic > through CoAP's congestion control mechanism." > I think this needs an normative requirement here. Congestion control is > supposed to avoid network overload but also to make use available > resources. The congestion control as currently defined for CoAP would > probably limit the join traffic appropriately (to something like one > packet per RTT likely) but CoAP could in theory use any time a > different more aggrieve congestion and therefore just relying on > congestion control generically doesn't seem to be sufficient. > I > recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per > 3 seconds if RTT is unknown (as recommended in RFC8085) and say that > this can be achieved by congestion control as specified in the base > CoAP spec. okay, how about: + The Join Proxy implements a data cap on outgoing join traffic by implementing + the section 3.1.3 recommendation of 1 packet per 3 + seconds. + This can be achieved with the congestion control mechanism specified + in section 4.7. > Further on there seems to be an implicit requirement that > the JP MUST implement rate limit using the PROBING_RATE parameter, > however, that is never explicitly spelled out as a normative > requirement. However, if this rate is not provided by the JRC, it > doesn't seem that any rate limiting has to be enforced. So maybe it > would be good to be more strict here. I think you are saying that we should have a default PROBING_RATE, if the JRC does not specify one. I think that we assumed that the RFC7257 section 4.8 value of 1 byte/second would apply. please confirm? > 2) Also, not sure if this editorial or a real issue but I'm not sure I > fully understand this sentence: > Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic > forwarded should set it to zero so that it is compressed out." If the > proxy does NOT SET DSCP, why should it SET it to zero? Because RFC6282 (and friends) has specific encoding to omit DSCP if it is zero. > I would think it > either sets it to AF43 or it does nothing about it because DSCP is not > really used in that network. In 6tisch networks, different DSCP points can be used to get different behaviours, see UHM. Let me get back to you on this, because the reference has evaporated. > 3) This may also be mostly editorial but just to be sure: Section 7.2 > provides default values for some of the CoAP transport parameter (where > 2 of 3 are the same as defined in RFC7252) but not for all. Why is > that? We got pushback about relying on 7252 defaults, because what if they changed. > 4 ) And then finally on references (again): Given that use of > I-D.ietf-core-stateless is recommend, I believe it should be normative > (and wait for publication of that doc). I guess since it's a MUST for the JRC, we need to do that. > -- > COMMENT: > -- > I'm putting this one question in the comments section because there is > no concern that it does not work as specified but I wonder about the > design of the Parameter Update Response Message. Given the Parameter > Update Message is a confirmable CoAP message that is transmitted > reliable and the content of the Parameter Update Response Message is > empty, why do you need to send the Parameter Update Response Message at > all? > And some minor comments (mostly editorial proposals): > 0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document > title to make clear that this is a protocol spec and not "only" and > abstract framework or something... so like: title: Constrained Join Protocol for 6TiSCH > 1) Sec 3: Maybe I'm missing something but this seems contradictory: > "Provisioning the network identifier is RECOMMENDED." And then at the > end of that paragraph: "This parameter MUST be provisioned to the 6LBR > pledge."+ You are right. The last sentence does not belong. During the join process, the network identifer, returned in the CoJP response is a MUST (8.4.1) > 2) Sec 4.3.2: Not sure I fully understand the context of this sentence: > "The JP operates as the application-layer proxy." Maybe "... operates > as an application-layer proxy" or probably even better "operates as > application-layer proxy" ? Also at this part of the document it is not > clear that the proxy actually interprets the CoAP message. I recommend > to mention this
