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

From: Tengfei Chang <[email-masked]>
Date: Thu, 5 Dec 2019 17:17:48 +0100

Hi All,

For securing the MSF, (comments from minimal security, thanks for the
input!)

In the next version of MSF, we need to add sentence saying MSF only adapts
the traffic which is secured, practically by checking the DSCP value set
with zero or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know
the frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic
without knowing upper layer field?

Thanks!
Tengfei
-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 5 Dec 2019 17:48:25 +0100

Hi,

> without knowing upper layer field?

I have no idea...

Why can't the "join rate" avoid such undesired cell allocations? If the 
join rate is properly configured, incoming join requests don't cause 
such allocations, do they?

https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-14#section-8.4
    o  join rate: Average data rate (in units of bytes/second) of join
       traffic forwarded into the network that should not be exceeded
       when a joined node operates as a JP, encoded as an unsigned
       integer.

https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-14#section-7.2
    The PROBING_RATE value at the JP is controlled by the join rate
    parameter, see Section 8.4.2.  Following [RFC7252], the average data
    rate in sending to the JRC must not exceed PROBING_RATE.  For
    security reasons, the average data rate SHOULD be measured over a
    rather short window, e.g.  ACK_TIMEOUT, see Section 9.

The recommended PROBING_RATE is 1 byte/second. I'm not sure how to 
interpret this value, though.... The time window to calculate the "rate" 
should be small enough, I believe.

Best,
Yatch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Dec 2019 16:50:49 +0000

Hello Tengfei

Architecturally speaking, MSF right now is used to allocate cells in the L3 bundle with a parent.

“

Layer-2 vs. Layer-3 bundle:
Bundles are associated for either Layer-2 (switching) or Layer-3 (routing) forwarding operations. A pair of Layer-3 bundles (one for each direction) maps to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an "arbitrary" cardinality and direction) corresponds to the relation of one or more incoming bundle(s) from the previous-hop neighbor(s) with one or more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part of the switching role, which may include replication and elimination

“

So even if it is operating under IP, it is working for IP. Even the notion that the neighbor is a parent is an IP layer consideration. So MSF is IPv6-aware.
IOW the IP layer passes an IP packet to the lower layer (6top), and 6top needs to assign the packet to a bundle. Once that is done, if the bundle is managed by MSF, then MSF observes the transmission. Same goes for incoming traffic.

Do you want me to provide the sentences or do you feel safe about putting your own words?

From: 6tisch <[email-masked]> On Behalf Of Tengfei Chang
Sent: jeudi 5 décembre 2019 08:18
To: 6tisch <[email-masked]>
Subject: [6tisch] MSF adapts to traffic only for secured packets

Hi All,

For securing the MSF, (comments from minimal security, thanks for the input!)

In the next version of MSF, we need to add sentence saying MSF only adapts the traffic which is secured, practically by checking the DSCP value set with zero or no, which is in IPv6 header.

In other hands, MSF is a link layer protocol, it doesn't suppose to know the frame is a IPv6 packet or not. no need to say a field value.

I would like to have some suggestions/comments on this issue.
Does anyone know other way to make the SF not adapt to unsecured traffic without knowing upper layer field?

Thanks!
Tengfei

Dr. Tengfei, Chang

www.tchang.org/<http://www.tchang.org/>
——————————————————————————————————————

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 5 Dec 2019 18:07:25 +0100

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 tagging mechanism in minimal-security is for such nodes, closer to the DAG root, to avoid allocating cells in response to the join traffic.

Mališa

> On 5 Dec 2019, at 17:48, Yasuyuki Tanaka <[email-masked]> wrote:
> 
> Why can't the "join rate" avoid such undesired cell allocations? If the join rate is properly configured, incoming join requests don't cause such allocations, do they?

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 5 Dec 2019 18:25:56 +0100

Thanks, Malisa,

Then, why cannot the IPv6 layer on an intermediate have rate limiting in 
order not to forward too much packets having AF43...? Forwarding 
decisions are made at the IPv6 layer.

Even if the intermediate node drops excess amount of forwarded join 
requests, the scheduling function in use still needs to do something? I 
may be confused...

Yatch

On 12/5/2019 6:07 PM, Mališa Vučinić wrote:
> 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 tagging mechanism in minimal-security is for such 
> nodes, closer to the DAG root, to avoid allocating cells in response to 
> the join traffic.
> 
> Mališa
> 
>> On 5 Dec 2019, at 17:48, Yasuyuki Tanaka <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Why can't the "join rate" avoid such undesired cell allocations? If 
>> the join rate is properly configured, incoming join requests don't 
>> cause such allocations, do they?
>

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 5 Dec 2019 18:46:14 +0100

Yatch,

This is simply a matter of not allocating resources, i.e. cells, in the network in response to the unauthenticated traffic. Even if the intermediate nodes have rate limiting on AF43, how could we ensure that the “acceptable” amount of unauthenticated traffic that actually gets forwarded does not trigger cell allocation? The cells used to transport the join traffic will be marked as used by MSF, and depending on the amount of regular traffic as well as the join rate limit, this may cause the cell allocation threshold to be surpassed. Right?

Mališa

> On 5 Dec 2019, at 18:25, Yasuyuki Tanaka <[email-masked]> wrote:
> 
> Thanks, Malisa,
> 
> Then, why cannot the IPv6 layer on an intermediate have rate limiting in order not to forward too much packets having AF43...? Forwarding decisions are made at the IPv6 layer.
> 
> Even if the intermediate node drops excess amount of forwarded join requests, the scheduling function in use still needs to do something? I may be confused...
> 
> Yatch
> 
>>> On 5 Dec 2019, at 17:48, Yasuyuki Tanaka <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 5 Dec 2019 19:59:20 +0100

Hi Malisa.

Thanks to your explanation, I get the point.

> how could we ensure that the “acceptable” amount of unauthenticated traffic that actually gets forwarded does not trigger cell allocation?

It'd be fine to trigger cell allocations by *acceptable* amount of 
unauthenticated traffic if necessary. Otherwise, important packets, 
authenticated traffic for applications, could be dropped because of no 
room in the TX queue filled with unauthenticated packets.

Or, the intermediate route should drop more "unauthenticated" traffic if 
you don't want to trigger. But, even doing this, we cannot ensure the 
first relayed join request since the last hour or year does not trigger 
a cell allocation.

> The cells used to transport the join traffic will be marked as used by MSF, and depending on the amount of regular traffic as well as the join rate limit, this may cause the cell allocation threshold to be surpassed. Right?

Yes, it causes another cell allocation.

Any L2 component including MSF doesn't case about information in the MAC 
frame payload field, although MSF (a 6TisCH scheduling function) is not 
on the path of outgoing packets in the protocol stack:

https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-3.7
       +--------+--------+
       | Applis |  CoJP  |
       +--------+--------+--------------+-----+
       | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
       +-----------------+--------------+-----+
       |       UDP       |      ICMPv6        |
       +-----------------+--------------------+
       |                 IPv6                 |
       +--------------------------------------+----------------------+
       |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |
       +--------------------------------------+----------------------+
       |               6top inc. 6top protocol                       |
       +-------------------------------------------------------------+
       |                 IEEE Std. 802.15.4 TSCH                     |
       +-------------------------------------------------------------+

                       Figure 4: 6TiSCH Protocol Stack

Thank you, again!
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 6 Dec 2019 18:48:57 +0100

Pascal,

Yes, MSF indeed aware of the routing information such as RPL parent, I
consider this is like an information stored at IPv6 layer that MSF can read
it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information
stored at upper layer that MSF have read access to it.

Thinking in this way, it seems OK for me.
Do you agree such interpreting?

Tengfei

On Thu, Dec 5, 2019 at 5:50 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Bundles are associated for either Layer-2 (switching) or Layer-3 (routing)
> forwarding operations. A pair of Layer-3 bundles (one for each direction)
> maps to an IP Link with a neighbor, whereas a set of Layer-2 bundles (of an
> "arbitrary" cardinality and direction) corresponds to the relation of one
> or more incoming bundle(s) from the previous-hop neighbor(s) with one or
> more outgoing bundle(s) to the next-hop neighbor(s) along a Track as part
> of the switching role, which may include replication and elimination
>
>
>
>
>
> “
>
>
>
> So even if it is operating under IP, it is working for IP. Even the notion
> that the neighbor is a parent is an IP layer consideration. So MSF is
> IPv6-aware.
>
> IOW the IP layer passes an IP packet to the lower layer (6top), and 6top
> needs to assign the packet to a bundle. Once that is done, if the bundle is
> managed by MSF, then MSF observes the transmission. Same goes for incoming
> traffic.
>
>
>
> *From:* 6tisch <[email-masked]> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 5 décembre 2019 08:18
> *To:* 6tisch <[email-masked]>
> *Subject:* [6tisch] MSF adapts to traffic only for secured packets
>
>
>
> Hi All,
>
>
>

Dr. Tengfei, Chang

www.tchang.org/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Dec 2019 18:03:24 +0000

Yes I do

Regards,

Pascal

Le 6 déc. 2019 à 09:49, Tengfei Chang <[email-masked]> a écrit :

Pascal,

Yes, MSF indeed aware of the routing information such as RPL parent, I consider this is like an information stored at IPv6 layer that MSF can read it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another information stored at upper layer that MSF have read access to it.

Tengfei

On Thu, Dec 5, 2019 at 5:50 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Tengfei

“

“

From: 6tisch <[email-masked]<mailto:[email-masked]>> On Behalf Of Tengfei Chang
Sent: jeudi 5 décembre 2019 08:18
To: 6tisch <[email-masked]<mailto:[email-masked]>>
Subject: [6tisch] MSF adapts to traffic only for secured packets

Hi All,

Thanks!
Tengfei

Dr. Tengfei, Chang

Dr. Tengfei, Chang

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 6 Dec 2019 21:31:34 +0100

Hi Pascal, Tengfei,

On 12/6/2019 6:48 PM, Tengfei Chang wrote:
> consider this is like an information stored at IPv6 layer that MSF can 
> read it from without touching the frame L2 payload.
> In such sense, I could consider the DSCP value can be another 
> information stored at upper layer that MSF have read access to it..

I think these two are different things...

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.

I don't see any problem in allocating additional cells for "acceptable" 
amount of traffic including relayed join requests. To prevent 
application packet drops, such allocations could be a good thing.

Rather than giving some L3 information to L2, the L3 may need L2 
information, like available bandwidth (cells) for a certain link. For 
the MSF case, if the IPv6 layer on an intermediate node limits outgoing 
traffic of relayed join requests below 20% of available bandwidth, 
undesired cell allocations could be avoided, assuming 
LIM_NUMCELLSUSED_HIGH is 75% and the link has almost the perfect link PDR.

Best,
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 6 Dec 2019 22:49:37 +0100

> I think these two are different things...

I agree, I am  only referring Pascal's reply before. What you discussed
with Malisa is another thing.

> 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.

> application packet drops, such allocations could be a good thing.

I get your point from your previous  comments.
I think the key point is the during the join phase, the JP can't
distinguish the traffic from:
-pledge or
- an attacker

Another way of thinking of security, if we didn't adapt the unauthorized
traffic, the attacker can still send lots of "fake" join request,
Instead of occupying the bandwidth, it delays or drops the join request
from pledge, which is an security issue as well.

I think the compromise solution is allowing MSF adapt the traffic but
report if there is unusually mount of join traffic detected.

Dr. Tengfei, Chang

www.tchang.org/

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 6 Dec 2019 23:24:35 +0100

Thank you, Tengfei.

> On Dec 6, 2019, at 22:49, Tengfei Chang <[email-masked]> wrote:
> 
> 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

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 12 Dec 2019 17:51:08 +0100

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 <[email-masked]>
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 <[email-masked]>
> 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)
>> > <[email-masked] <mailto:[email-masked]>> 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:[email-masked] <mailto:[email-masked]>>
>> >     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:[email-masked] <mailto:[email-masked]>>
>> >     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:[email-masked] <mailto:[email-masked]>
>> >     <mailto:mailto <mailto:mailto>:[email-masked]
>> >     <mailto:[email-masked]>>> wrote:
>> >      >>>     Thank you, Tengfei.
>> >      >>>      > On Dec 6, 2019, at 22:49, Tengfei Chang
>> >     <mailto:[email-masked] <mailto:[email-masked]>
>> >      >>>     <mailto:mailto <mailto:mailto>:[email-masked]
>> >     <mailto:[email-masked]>>> wrote:
>> >      >>>      >
>> >      >>>      > Handling DSCP value will be a per-packet process. Can we
>> >     pass
>> >      >>>     DCSP value
>> >      >>>      > 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:
>> >      >>>     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
>> >      >>> --
>> >      >>> http://www.tchang.org/ <http://www.tchang.org/>
>> >     http://www.tchang.org/
>> > www.tchang.org/ <http://www.tchang.org/>

Dr. Tengfei, Chang

www.tchang.org/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Dec 2019 17:04:03 +0000

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 <[email-masked]> On Behalf Of Tengfei Chang
Sent: jeudi 12 décembre 2019 17:51
To: 6tisch <[email-masked]>
Subject: Re: [6tisch] MSF adapts to traffic only for secured packets

All,

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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the confirmation Yatch!

On Thu, Dec 12, 2019 at 5:22 PM Yasuyuki Tanaka <[email-masked]<mailto:[email-masked]>> wrote:
Thank you, all.

Best,
Yatch

On 12/12/2019 6:01 AM, Tengfei Chang wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hello again
>
>
>     https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer but that
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     wrote:
>     Thanks, Malisa,
>
>     First of all,
>
>     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.
>
>     Yes, if it's not configured properly, you may have undesirable network
>     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
>     traffic, or having dedicated number of slots to AF43 in the same buffer,
>      >
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     wrote:
>      >>
>      >> Hi Tengfei, Malisa,
>      >>
>     and even L3, while keeping application requirements..
>      >>
>     traffic still have the same situation being dropped..
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     <mailto:mailto<mailto:mailto> <mailto:mailto<mailto:mailto>>:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >>>     Thank you, Tengfei..
>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>      >>>     <mailto:mailto<mailto:mailto> <mailto:mailto<mailto:mailto>>:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>      >>>      >
>      >>>     computed cell utilization (NumCellsUsed / NumCellsElapsed) goes
>      >>>     down, then a negotiated TX cell will be deleted, even if the
>      >>> http://www.tchang.org/ <http://www..tchang.org/<http://www.tchang.org/>>
> www.tchang.org/<http://www.tchang.org/> <http://www.tchang.org/>

Dr. Tengfei, Chang

Dr. Tengfei, Chang

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 12 Dec 2019 18:21:02 +0100

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) <
[email-masked]> 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
>
>
>
> *Sent:* jeudi 12 décembre 2019 17:51
> *Subject:* Re: [6tisch] MSF adapts to traffic only for secured packets
>
>
>
> All,
>
>
>
> 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,
> 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. *
>
>
>
>
>
>
>
>
>

Dr. Tengfei, Chang

www.tchang.org/