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

[Tengfei Chang <[e-mail]>]

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) <
[e-mail]> 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 <[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]>
> 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]>
> 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]>> 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]>>
> >     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]>>
> >     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:mailto <mailto: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:mailto <mailto: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/>
> > ——————————————————————————————————————
>
>
>
>
> --
>
> ——————————————————————————————————————
>
>
>
> 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/
——————————————————————————————————————