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

[Mališa Vučinić <[e-mail]>]

On Fri, Sep 7, 2018 at 6:30 PM Tero Kivinen <[e-mail]> wrote:

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


Please note the difference between the protocol (CoJP), the configuration
of the stack and the implementation decisions.

Yes, in the particular case where the timer needs to be implemented in
order to relieve the state from the stack because the MAC layer was
implemented in such a way that the timer is necessary to get the
communication going, you can regard it as a state that needs to be kept for
a short amount of time. I am arguing that *in this particular case*
implementing it in such a way with a timeout taking into account
(re)transmission on a single hop will reduce vulnerability to DoS in
respect to a timeout to expire 1/N entries end-to-end, as discussed in one
of the previous emails.


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

I respectively disagree: There is no security association between JP and
the pledge for very practical reasons as any node in the network can play
the role of a JP. What you propose makes sense in the case where the JP can
authenticate the pledge and drop the protocol messages due to failed
security processing. This is simply not the case and you are proposing to
make a blind decision at JP to prevent this pledge from joining, because a
previous authentication with JRC failed.

This is not the decision of the JP, but of the JRC.

By shifting this decision to JP, you are introducing unnecessary complexity
in the JP code which will simply result in more misconfigurations being
made.



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

Indeed, a hammer also acts as a good DoS device.


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

So now it seems we are talking about 802.15.4 attackers. If the attacker
has 16 802.15.4 radios and can jam all the channels at the same time we can
hardly do anything about that. That, however,  requires hardware that is
(significantly) more expensive than a single-radio 15.4 device (see for
example http://www.beamlogic.com/802-15-4-siteanalyzer#price).
Nevertheless, such an attack is our point of reference.

If we now consider single-radio jammer, due to channel hopping the
effectiveness of the attack significantly decreases.

When working on the minimal-security spec, we consider DoS attacks that
would allow the attacker with a typical single-radio 802.15.4 device and a
slightly modified firmware to prevent the network from forming, simply by
sending a couple of radio frames. I hope you see the difference in
investment from the point of view of an attacker to perform such an attack
in respect of getting specialized equipment.

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

Agreed, but as described above, the JP has no means of knowing whether the
pledge was 'misconfigured'. If you now start adding complexity at JP to
*imply* whether a pledge was misconfigured you just increase the space for
misconfiguration (of the JP) to happen.


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

I am not arguing that the limit (i.e. bandwidth cap) should be anywhere but
on the JP, I am arguing that the logical decision on what should be
prioritized within that cap is JRC's, not JP's.

We simply cannot do that sort of prioritization with JP making the
decisions as there is no security association between the pledge and the
JP. I hope we agree on that?


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

I expect the bandwidth cap at JP to be a much much lower value than what is
available upstream.

If you assume MSF running, you apriori know that every node that has joined
the network has at least one dedicated cell to its parent. Setting the
bandwidth cap at JP to a small portion of that dedicated bandwidth would be
prudent as you simply don't want to allocate all of the bandwidth to
unauthenticated traffic, as the attack there may now disturb the
functioning of the network.

Yasuyuki Tanaka is currently working on a very similar issue using the
6TiSCH simulator and with his input I expect we will propose a default
value for the set of minimal 6TiSCH specifications (RFC8180, 6P, MSF and
minimal-security) running together.



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

Well, before JP installs a blacklist entry, it will have to process at
least one packet and forward it onwards. This is equivalent behavior to
what I proposed with JRC.

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

Sure, therefore my description on the DoS vulnerability metric with your
approach and the current design some exchanges ago.


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

I don't quite see how this is relevant. In both cases we will forward
packets from JP to JRC. The question is who decides whether a given EUI64
should be blacklisted.


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


The term 'state' can be related to many different things and it doesn't
seem we are on the same page when it comes to that.