ah... I agree with you . Just submitted the current version though. Will correct it in next version.
On Thu, Dec 12, 2019 at 6:04 PM Pascal Thubert (pthubert) < pthub...@cisco.com> wrote: > A nit Tengfei : > > > > « *before it is passed to MSF. “* > > Would be > > *“before it is passed to the 6top sublayer where MSF can observe it.” Or > something similar?* > > > > Otherwise, all good! > > > > Pascal > > > > *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang > *Sent:* jeudi 12 décembre 2019 17:51 > *To:* 6tisch <6tisch@ietf.org> > *Subject:* Re: [6tisch] MSF adapts to traffic only for secured packets > > > > All, > > > > The following is our internal discuss about this issue. > > > > We will add the following text in "Security Consideration " section in > MSF-09: > > > > > > > > > > > > > > > > > > > > > > > * MSF adapts to traffics containing packets from IP layer. It is > possible that the IP packet has a non-zero DSCP (Diffserv Code Point > [RFC2597]) value in its IPv6 header. The decision whether to hand over > that packet to MAC layer to transmit or to drop that packet belongs to > the upper layer and is out of scope of MSF. As long as the decision is > made to hand over to MAC layer to transmit, MSF will take that packet > into account when adapting to traffic. Note that non-zero DSCP value may > imply that the traffic is originated at unauthenticated pledges, > referring to [I-D.ietf-6tisch-minimal-security]. The implementation at > IPv6 layer SHOULD ensure that this join traffic is rate-limited before > it is passed to MSF. In case there is no rate limit for join traffic, > intermediate nodes in the 6TiSCH network may be prone to a resource > exhaustion attack, with the attacker injecting unauthenticated traffic > from the network edge. The assumption is that the rate limiting > function is aware of the available bandwidth in the 6top L3 bundle(s) > towards a next hop, not directly from MSF, but from an interaction with > the 6top sublayer that manages ultimately the bundles under MSF's > guidance. How this rate limit is set is out of* > > * scope of MSF. * > > > > > > > > > > On Thu, Dec 12, 2019 at 5:26 PM Tengfei Chang <tengfei.ch...@gmail.com> > wrote: > > Thanks for the confirmation Yatch! > > > > I will forward our discuss back to the mailing list for information. > > > > > > > > On Thu, Dec 12, 2019 at 5:22 PM Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> > wrote: > > Thank you, all. > > The proposed text looks very good to me. It resolves my concerns. > > Best, > Yatch > > On 12/12/2019 6:01 AM, Tengfei Chang wrote: > > Cool! Thanks for the additional info! Integrated as well! > > > > On Thu, Dec 12, 2019 at 4:55 PM Pascal Thubert (pthubert) > > <pthub...@cisco.com <mailto:pthub...@cisco.com>> wrote: > > > > Hello again > > > > > > > Note that non-zero DSCP value may imply that the traffic is > > originated at unauthenticated pledges, see {{minimal-security}}. > > > The implementation at IPv6 layer SHOULD ensure that this join > > traffic is rate-limited before it is passed to MSF. > > > In case there is no rate limit for join traffic, intermediate > > nodes in the 6TiSCH network may be prone to a resource exhaustion > > attack, with the attacker injecting unauthenticated traffic from the > > network edge. > > > How this rate limit is set is out of scope of MSF. > > > > This would be a nice addition to the security section : ) > > > > Note that the upper layer can only do load control if it is aware of > > the amount of bandwidth that the current bundles provide. 6top > > knows. So either 6top does the whole rate limiting, or there is an > > interface between the IP layer and 6top, that is not described, even > > in the architecture. > > > > The idea was to describe all this in > > https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer but that > > will probably not happen anytime soon. > > > > So maybe complementing Malisa's text as follows: > > > > ." > > Note that non-zero DSCP value may imply that the traffic is > > originated at unauthenticated pledges, see {{minimal-security}}. > > The implementation at IPv6 layer SHOULD ensure that this join > > traffic is rate-limited before it is passed to MSF. > > In case there is no rate limit for join traffic, intermediate nodes > > in the 6TiSCH network may be prone to a resource exhaustion attack, > > with the attacker injecting unauthenticated traffic from the network > > edge. > > The assumption is that the rate limiting function is aware of the > > available bandwidth in the 6top L3 bundle(s) towards a next hop, not > > directly from MSF, but from an interaction with the 6top sublayer > > that manages ultimately the bundles under MSF's guidance. How this > > rate limit is set is out of scope of MSF. > > " > > > > Pascal > > > > > > On Wed, Dec 11, 2019 at 6:03 PM Yasuyuki Tanaka > > <mailto:yasuyuki.tan...@inria.fr <mailto:yasuyuki.tan...@inria.fr>> > > wrote: > > Thanks, Malisa, > > > > First of all, > > > > > 1) MSF not allocating cells in response to AF43 traffic > > > > I think it's a layer violation as I mentioned in previous emails in > > other expressions. So, I'm trying to avoid to do this. MSF, part of > L2, > > shouldn't do anything based on contents in the MAC payload field of a > > frame in process. > > > > > Under the assumption that application traffic is given higher > > priority than join AF43, is this not solved with the two above? Do I > > miss some other issue you raised? > > > > You may be able to solve the issue by that, although prioritizing > > traffic is not a job of a scheduling function. > > > > > Are you considering to set the maximum link capacity (i.e. total > > number of cells) between two neighbors? This is a function of the > > application traffic and the acceptable “untrusted” traffic, where > > you only know the latter in advance through the admin policy. IMO, > > this risks to introduce application drops as well if not properly > > configured.. > > > > If we have the maximum link capacity to a neighbor, we can avoid > > resource exhaustion. But the link could be occupied by acceptable > > "untrusted" traffic, which can cause application packet drops. To > > prevent that, rate limit for AF43 packets at L3 should be aligned > > with , > > less than, the maximum link capacity configured to MSF. > > > > Yes, if it's not configured properly, you may have undesirable > network > > performance. But, it's only a matter of configuration. > > > > > The normative keyword in minimal-security is a SHOULD. If we have > > a good reason not to follow that, we can explain in MSF why it is > > the case... > > > > Thanks; yes I'm aware of that. Having the concern about the layer > > violation thing, I'm not a fan of the section itself. I think now you > > know that. :-) Considering the stage of the CoJP draft, I DON'T > suggest > > any change to Section 6.1.1. > > > > Best, > > Yatch > > > > > > On 12/11/2019 6:09 AM, Mališa Vučinić wrote: > > > Yatch, > > > > > > What I don’t understand is how the combination of > > > > > > 1) MSF not allocating cells in response to AF43 traffic > > > 2) keeping AF43 in a separate buffer from application/network > > traffic, or having dedicated number of slots to AF43 in the same > buffer, > > > > > > has issues we previously discussed. My understanding is that you > > worry about the application traffic being dropped due to AF43 > > traffic being present in the same buffer and occupying cells but not > > causing allocations. Under the assumption that application traffic > > is given higher priority than join AF43, is this not solved with the > > two above? Do I miss some other issue you raised? > > > > > > p.s. yes, we are trying to avoid resource exhaustion where the > > attacker injects join requests into the network causing higher power > > consumption on intermediate nodes. > > > > > > Some remarks on your proposal below. > > > > > > Mališa > > > > > >> On 11 Dec 2019, at 16:02, Yasuyuki Tanaka > > <mailto:yasuyuki.tan...@inria.fr <mailto:yasuyuki.tan...@inria.fr>> > > wrote: > > >> > > >> Hi Tengfei, Malisa, > > >> > > >>> To resolve the issue Yatch mentioned in the thread, > > >> > > >> My opinion is, to allow allocations by *acceptable* amount of > > untrusted traffic. This won't need any modification on MSF, TSCH, > > and even L3, while keeping application requirements.. > > >> > > >> L3 enforces traffic controls to ensure untrusted traffic keeps > > below the limit configured by adminimistrative policy. This is a > > common practice in IP networks, I believe. > > >> > > >>> Malisa pointed out we should states that the buffers for trust > > traffic > > >>> and untrusted traffic should be separated. > > >> > > >> This doesn't solve the issue. Suppose a case when NumCellsUsed > > is 74.9999...% and we're going to send one single untrusted packet > > stored in the buffer for such packets, the untrusted packet will > > cause NumCellsUsed to exceed LIM_NUMCELLSUSED_HIGH (75%), and will > > trigger an additional allocation. > > >> > > >> Here is one of Pascal's ideas: > > >> > > >>> You can have different thresholds based on AF to trigger the > > allocation. > > >> > > >> It sounds like, this idea allows additional allocations by AF43 > > traffic to some extent? > > >> > > >> Anyway, as he mentioned, > > >> > > >>> This only pushes the problem a bit though. > > >> > > >> It does. > > >> > > >>> You can have a turbo mode during network startup ... But that > > is not in scope for MSF. > > >> > > >> Regarding "turbo mode" in Pascal's email, it is out of the scope > > of MSF, and could be difficult to implement in a right way since > > there is no explicit timing of the end of network "bootstrap". > > >> > > >> As you may notice, if we don't allow any allocation by > > "untrusted" traffic at all, this would give another DoS window to > > attackers. > > >> > > >> What the CoJP draft is trying to resolve is, resource exhaustion > > attacks by join request packets? > > > > > >> If MSF has the upper limit of scheduled cells, it won't allocate > > cells by untrusted traffic endlessly. Of course, the upper limit > > should be configured with consideration for application requirements > > and acceptable "untrusted" traffic. > > >> > > >> So, with an assumption L3 controls traffic of AF43 packets, my > > opinion ends up to be: > > >> > > >> - 1. allow allocations by "untrusted" traffic > > >> - 2. set the upper limit of (TX/RX) cells scheduled with an > > selected parent > > > > > > I don’t understand point 2. Are you considering to set the > > maximum link capacity (i.e. total number of cells) between two > > neighbors? This is a function of the application traffic and the > > acceptable “untrusted” traffic, where you only know the latter in > > advance through the admin policy. IMO, this risks to introduce > > application drops as well if not properly configured.. > > > > > >> > > >> I'm sorry for raising this at this stage of the CoJP draft... I > > didn't notice Section 6.1.1 of > > draft-ietf-6tisch-minimal-security-14. Section 6.1.1 is very > > constraining. I remember we had a related discussion on this matter > > last summer, regarding MSF autonomous cell allocation. Then, I > > thought, after the discussion, the text of MSf dind't have any issue > > in handing AF43 packets. But, clearly, it isn't the case… > > > > > > The normative keyword in minimal-security is a SHOULD. If we have > > a good reason not to follow that, we can explain in MSF why it is > > the case... > > > > > >> > > >> Best, > > >> Yatch > > >> > > >> On 12/11/2019 1:17 AM, Tengfei Chang wrote: > > >>> Hi Yatch, Pascal, > > >>> Malisa and I have discussed personally on this topic and think > > it's better to have an internal discussion on this. > > >>> To resolve the issue Yatch mentioned in the thread, not > > adapting the untrusted traffic could make the application traffic > > being dropped because of limited bandwidth. > > >>> Malisa pointed out we should states that the buffers for trust > > traffic and untrusted traffic should be separated. > > >>> So they won't effect each other. However, the pledge's join > > traffic still have the same situation being dropped.. > > >>> What is your opinion to handle this issue in MSF? > > >>> Tengfei > > >>> On Fri, Dec 6, 2019 at 11:24 PM Yasuyuki Tanaka > > <mailto:yasuyuki.tan...@inria.fr <mailto:yasuyuki.tan...@inria.fr> > > <mailto:mailto <mailto:mailto>:yasuyuki.tan...@inria.fr > > <mailto:yasuyuki.tan...@inria.fr>>> wrote: > > >>> Thank you, Tengfei.. > > >>> > On Dec 6, 2019, at 22:49, Tengfei Chang > > <mailto:tengfei.ch...@gmail.com <mailto:tengfei.ch...@gmail.com> > > >>> <mailto:mailto <mailto:mailto>:tengfei.ch...@gmail.com > > <mailto:tengfei.ch...@gmail.com>>> wrote: > > >>> > > > >>> > Handling DSCP value will be a per-packet process. Can we > > pass > > >>> DCSP value > > >>> > to the TSCH layer using the interface for transmission > > defined by > > >>> > IEEE802.15.4? I don't think so. > > >>> > > > >>> > TC: Not sure this is a standard way to do so. For > > implementing, > > >>> tut this value or a flag could have a default value. > > >>> > TC: If this value is not given, i.e. frame from > IEEE802.15.4 > > >>> layer, just use the default value. > > >>> What we would do are: > > >>> - 1. don't update NumCellsUsed for AF43 packets, otherwise > > update them > > >>> - 2. don't update NumTX/NumTxAck for AF43 packets, > > otherwise update them > > >>> The first one may cause undesirable deallocations. If a > > node has > > >>> relayed join request continuously for a certain period of > > time, the > > >>> computed cell utilization (NumCellsUsed / NumCellsElapsed) > goes > > >>> down, then a negotiated TX cell will be deleted, even if the > > >>> negotiated TX cell was scheduled to handle application > > traffic to > > >>> forward. This behavior may degrade end-to-end reliability. > > >>> The second one may prevent the node from monitoring link > > PDRs on > > >>> scheduled cells correctly. This could affect the scheduling > > >>> collision detection. > > >>> Best, > > >>> Yatch > > >>> -- > > >>> —————————————————————————————————————— > > >>> Dr. Tengfei, Chang > > >>> Postdoctoral Research Engineer, Inria > > >>> http://www.tchang.org/ <http://www..tchang.org/ > <http://www.tchang.org/>> > > >>> —————————————————————————————————————— > > > > > > > > > > > -- > > —————————————————————————————————————— > > > > Dr. Tengfei, Chang > > Postdoctoral Research Engineer, Inria > > > > http://www.tchang.org/ > > —————————————————————————————————————— > > > > > > > > -- > > —————————————————————————————————————— > > > > Dr. Tengfei, Chang > > Postdoctoral Research Engineer, Inria > > > > www.tchang.org/ <http://www.tchang.org/> > > —————————————————————————————————————— > > > > > -- > > —————————————————————————————————————— > > > > Dr. Tengfei, Chang > > Postdoctoral Research Engineer, Inria > > > > www.tchang.org/ > > —————————————————————————————————————— > > > > > -- > > —————————————————————————————————————— > > > > Dr. Tengfei, Chang > > Postdoctoral Research Engineer, Inria > > > > www.tchang.org/ > > —————————————————————————————————————— > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
