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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Tengfei Chang
Sent: jeudi 12 décembre 2019 17:51
To: 6tisch <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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)
> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>     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:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>     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:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     <mailto:mailto<mailto:mailto> <mailto:mailto<mailto:mailto>>:[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>> wrote:
>      >>>     Thank you, Tengfei..
>      >>>      > On Dec 6, 2019, at 22:49, Tengfei Chang
>     <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>      >>>     <mailto:mailto<mailto:mailto> <mailto:mailto<mailto:mailto>>:[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>> 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/> <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/<http://www.tchang.org/>
——————————————————————————————————————