Re: [6tisch] My comments to the draft-ietf-6tisch-minimal-security-06

[Tero Kivinen <[e-mail]>]

Mališa Vučinić writes:
>     Yes, I think it can be made to work, but I think it is quite a lot of
>     work and code just to be able to claim to be "stateless".
> 
> I don't quite agree that what is typically a one-liner to schedule a timeout
> event and a couple of lines of code in the callback to remove the entry can be
> deemed as "quite a lot of work and code"...

Adding timer will create state, thus the protocol is no longer
stateless. I think trying to make things very hard so it can be done
stateless might make things harder.

Example of this is when misconfigured node will try to joining again
and again and again. If you do everything in stateless way you are
going to act like every single one of those is completely new
connection and do full processing of all of them. If you do store some
state, you can remember that this node tried this few seconds ago,
there is no point of allowing it to do it again, lets just drop the
frame.

>     True, but in B the JP can also protect network and JRC, as it actually
>     KNOWS how many pledges have sent messages to JRC through it. In case
>     A, it will always forward messages, as it does not know how many
>     ongoing ones there still is. Of course it could use some kind of
>     statistics counters to limit that number, by saying only n joining
>     operations per minute, but that is again more code and complexity than
>     just saying that keep the 20 bytes of state for each pledge doing
>     joining process, and limit the number of those to fixed number of n.
> 
> For case B, it doesn't seem that you are considering that a malicious pledge
> can spoof its EUI64.

You are now talking about DoS attacks which happen within radiorange
of the network. For such attacker they can simply do DoS by putting
few bluetoot devices nearby... I have understood that bluetooth acts
quite good DoS device for 802.15.4 devices in 2.4 GHz band...

Or simply transmit all the time and nothing will go through. That is
much easier than spoofing EUI64 for joining purposes.

On the other hand having non-malicious node which has wrong parameters
and cannot join because of that, but will retry every few minutes will
most likely be much more common case.

I.e., if you have malicious node which can send radio traffic, they
can do so much more anyways to DoS the network.

And if the attacker changes its EUI64 then at one point the JP
notices that it has too many joining connections ongoing and when the
fixed limit is reached it will drop future attempts until some of them
finishes.

Regardless what we do the attacker who can fake EUI64 can fake so many
joining requests that real nodes will not be able to join anymore.
Doing the limit explictly in JP is easier than doing it by running
out of bandwidth somewhere in the network for joining traffic packets.

> For case A, we discuss this bandwidth cap that you mention in Security
> Considerations section. Note that the bandwidth cap is for example already
> implemented as part of CoAP's congestion control mechanism. By setting
> PROBING_RATE from RFC7252 of JP to a value different than those of pledges,
> existing code is used to limit how much traffic is forwarded into the
> network. We don't have explicit text on the use of CoAP's mechanism for this
> but I am discussing with CORE experts about it and I will provide some text in
> the next revision.

Configuring that bandwidth cap is bit challenging as JP does not know
how much bandwidth is available further in upstream. I.e., it might
have enough capacity to send for its next hop neighbor, but that
neighbor might not have enough for sending traffic further. 


>     > While blacklisting does not add much in terms of security, as source
>     > addresses can be spoofed,  I agree that it's beneficial to have
>     > blacklisting as a feature in case of misconfiguration, for
>     > performance reasons. I think that the JRC should be the one who
>     > decides if a given address should be blacklisted, from the amount of
>     > traffic it receives and other information it possesses.
>    
>     I assume this kind of misconfigurations will be much more common than
>     actual attacks...
> 
> I agree with the statement above, but I am still concerned with DoS during
> network formation. Blacklisting, as proposed below from JRC -> JP alleviates
> the misconfiguration case, keeping the JP stateless increases robustness to
> DoS... Do you agree with that?

No.

I think JP can be more resistant to DoS if it remembers something. It
should have limits how much state it will store, but quite often in
constrained devices it is faster to just check blacklist and drop
packet, than do full processing of packet and send it forward, even
when the first case do have state, and second form can be stateless.

I think it is much more important to limit the amount of data is kept
and only keep data that is useful than make sure we never store any
state.

Yes, attacker can use random EUI64 to get through blacklist, but he
can also block the whole channel with random garbage also.

So I think trying hard to make things explictly stateless is not a
good goal. It is better to have good DoS protections instead
regardless whether they have state or not. 

Also if we always forward the frame from JP to JRC (within the
bandwidth caps etc) that allows attackers to do amplification factor
of 2 * n + maxRetransmissions where n is number of hops from JP to
JRC. I.e., for single packet attacker sends it will consume radio
resources and battery life for 2 * n frames in the network in total
and maxRetransmissions count from the JP, when the JP tries to send
reply packet back to joining node which of course does not ACK the
frame...

> 
>     > How about we add a CoJP parameter "blacklist" that can be signaled
>     > in Parameter Update Request messages that carries a list of
>     > blacklisted addresses. The JRC sends this at any time to JP(s) over
>     > their secure channel, and JP can then filter these frames in
>     > hardware for example, since many chips support this already. What do
>     > you think?  
>    
>     Sounds good. So this would not be part of joining message, but
>     completely separate message from JRC to JP directly?
> 
> Yes, that was the intent. 

Which of course do create state in the JP, but that is state that will
make DoS properties better... 

>     I would expect it to happen other way around. The node starts up, and
>     joins non-TSCH configuration network it can see near by (or perhaps
>     send active beacon request to "hidden" configuration network assuming
>     the configuration device to respond to it). Over this 802.15.4 link
>     (without TSCH) it will fetch its configuration, and after it has
>     finished this, it will turn on TSCH as it now have enough
>     configuration to know how to join the TSCH network.
>    
>     Finding non-TSCH configuration network is much faster and easier than
>     TSCH network. Finding TSCH network can take several minutes or even an
>     hour depending how many channels you have.
>    
>     I.e., on 16 channel TSCH network using 10 ms, 100 slots setting, with
>     beacon interval of 5, and allowing 3 missed beacons means that node
>     needs to listen 0.01 * 100 * 3 * 5 * 16 seconds = 240 seconds.
>    
>     What I understood that most implementions do not even try to find the
>     TSCH network on all channels, they just try first n (3?) or something
>     and if they do not find beacon on them they will give up. Note, that
>     you cannot just assume that first channel etc is used, as it might
>     have been blocked up in the network by hopping sequence because there
>     might be some other network running on that channel instead causing
>     problems.
>    
>     Anyways hopefully the non-TSCH and TSCH networks will use different
>     keys, but knowing that most IoT vendors do not care or understand
>     security, my guess is that if non-TSCH network is using any security
>     it is using same keys than TSCH network.
> 
> I guess the most we can do about this in minimal-security is a paragraph in
> the Security Considerations.. I will get back to you with some text.

I made comment in 802.15.4 revision about TSCH and non-TSCH security
already. 
-- 
[e-mail]