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

From: Mališa Vučinić <[email-masked]>
Date: Fri, 7 Sep 2018 16:39:20 +0200

Hi Tero,

Just getting back to this after my vacation, see inline.

Mališa

On Fri, Jul 27, 2018 at 8:25 PM Tero Kivinen <[email-masked]> wrote:

> Mališa Vučinić writes:
> >
> > The question now is when to remove the entry with secExempt for
> > pledge at JP, once it was installed from Stateless-Proxy. From the
> > security point of view, the easiest is to remove it immediately once
> > L2 ACK from the pledge is received at JP, but this will degrade
> > performance in case of future extensions where there are more
> > messages in the protocol before join completes as the first
> > corresponding frame from the pledge to the JP will need to be
> > retransmitted.
> >
> > What do you think?
>
> 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"...

>
> > Yes, I see your point. This seems to be a performance vs security
> tradeoff, i.e.:
> >
> > (A) do we want to degrade performance with one L2 retransmission of
> > the first frame coming from the pledge when JP does not have an
> > entry, in order to reduce DoS space at JP.
> >
> > (B) keep this state at JP for the whole duration of the join process
> > of a pledge.
>
> I think B is much easier, as the JP most likely will want to limit
> number of pledges going through it anyways. I.e., it might be easier
> to configure JP so that it will have n (for example 3) slots for
> joining nodes, and after it has that many pedges trying to join
> through it it would simply not ACK on those packets at all.
>

I completely agree that B is easier but as I describe(d) below is also more
prone to DoS. Therefore, we opted for B...

> Also does the join messages going from the pledge to JRC always
> consists of exactly one L2 frame, meaning the size of messages is
> limited to around 100 octets or so? If there is multiple L2 frames to
> be sent and reassemebled in the JP, then that is definately a state
> that is much bigger than storing secExempt flag (which is less than 20
> bytes anyways in total).
>

You raise a good point that when a message results in multiple L2
fragments, which is not the case with default values, JP will need to
reassemble it at 6LoWPAN layer before passing it to CoAP. This should
indeed be discussed in the security considerations as a DoS vector as
setting the reassembly timeout value is critical.

> > Consider that the DoS metric of importance is the number of pledges
> > that can join over a single JP: N / T, where N is the number of
> > insecure entries for pledges at JP,
> > and T is the time JP has to keep them.
> > - N is the same both in (A) and (B).
> > - In (A), T is the worst-case timeout in case of an attack where JP
> > needs to expire the entry, because pledge did not send conformant
> > traffic to JRC in due time. Say a couple of seconds.
> > - In (B), T is the duration of the join process of a pledge. Much
> > greater than a couple of seconds with multiple hops to 6LBR, and JRC
> > in the cloud. With multiple pledges joining and contending for the
> > minimal cell, this is on the order of several minutes [1].
>
> 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.

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.

>
> > Finally, while I understand that there are vendors out there that
> > sell closed implementations of 802.15.4 MAC where the behavior that
> > you describe of having to reject a frame before adding an entry in
> > the security table is set in stone, please note that there are also
> > many implementations out there, e.g. Contiki, Contiki-NG, OpenWSN,
> > RIOT, and also proprietary ones that I personally worked on, where
> > this is easily implemented without *any* performance hits. With
> > that, JP can process once the frame, see that it doesn't pass
> > security processing, but add a special check if the join process is
> > ongoing so that the frame should be passed to the upper layer.
> > There, we get increased security without any performance hits.
>
> Sure there can and will be such implementations, but that also makes
> that pieces of code more complicated as it needs to do other things
> than just what is needed for MAC. The reason people try to implement
> standard interfaces is to make sure you can switch hardware and code
> without rewriting everything.
>

Sure, I am obviously not questioning the usefulness of standard interfaces,
just arguing that in a lot of cases the firmware developer has full control
over what is executing on the constrained device.

>
> Also it needs to do its decisions very quickly, as it needs to answer
> to the ACK in very short time (typically withing one ms), and before
> that it needs to do security processing (no decryption as this is
> clear text frame, but policy checking etc), verify from some other
> code that this frame needs to be passed up, even when there is no
> secExempt flag for it, generate ack and send it out.
>

I agree but all of this is feasible with modern 32-bit microcontrollers.
Not saying that we should discard older hardware, but only that in the
majority of cases there won't be any performance hit on implementing it the
way I described in the previous email.

>
> >     On the other hand blacklisting someone who has failed joining process
> >     is also good idea, but this stateless method does not allow it and
> >     then one joining node which have any kind of misconfuguration will
> >     simply consume network resources all the time, with repeated tries to
> >     join the network.
> >
> > 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?

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

>
> >
> >     > JP does not need to match the long address of a given pledge to the
> >     > newly assigned short address. The L2 nonce is constructed from the
> >     > short address and PAN ID, no?
> >
> >     Nonce can be constructed using short address, but security tables do
> >     require extended address also. See table 9-14 of the 802.15.4-2015.
> >     I.e., extended address is always needed, short address can have value
> >     0xfffe or 0xffff if they are not used or known.
> >
> >     There is no text in the 802.15.4 that would lift that requirement for
> >     the TSCH, i.e. extended address is always needed for security. That
> is
> >     the primary key for the node. The table 9-14 is used to map the short
> >     address to extended address (think it as arp table).
> >
> > Consider nodes A and B, neighbors, both are aware of each other's
> > short addresses. Group security keys used, i.e. index mode.
> >
> > You are essentially saying that even though nodes A and B do not
> > need each other's extended addresses for any interoperability or
> > security relevant reason, they need to store this information in
> > their memory. Not ideal..
>
> Yes, 802.15.4 do require them. As I said TSCH is just one mode in
> 802.15.4, and it can be enabled and disabled, and the security still
> needs to work even if you do that. Note, that in theory there can
> already be nonce collision between TSCH frames and non-TSCH frames
> using the same key, as the other uses ASN and other uses Frame
> counters. I practice I think 802.15.4 networks turn TSCH on, and keep
> it on, and does not send any secured frames without TSCH ever (or at
> least I hope so).
>
> Perhaps we need to add comment about that to the 802.15.4 revision to
> make it sure.
>

OK.

>
> And of course there will be lots of implementations that works fine
> with just short addresses, and never care about the extended
> addresses, but we cannot guarantee that all hardware implementations
> allows using just short addresses as it is not something that is
> really allowed by 802.15.4...
>
> >     Note, that TSCH mode is a mode than can be turned on/off in the
> >     802.15.4 device, and the security still needs to be work, so even if
> >     the node would be able to do security with only short addresses when
> >     TschMode is turned on, it cannot do that when TschMode is turned off.
> >     The security is written so it works regardless whether TschMode is on
> >     or off.
> >
> >     On the other hand there is nonce collision possibility if same key is
> >     used when TschMode is off and TschMode is on, as TschMode on uses ASN
> >     in nonce and TschMode off uses frame counter and security level. In
> >     theory there could be combination that causes collision, so there
> >     might be need to add text to the 802.15.4 that says that node shall
> >     not use same keys for both modes.
> >
> > I am not sure I fully understand how this would work. Network A is a
> > TSCH network. Pledge joins network A. Pledge decides to switch off
> > TSCH mode. Won't it need to join another network (i.e.
> > beacon-enabled, CSMA), with a completely different set of keys then?
>
> 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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 7 Sep 2018 19:30:26 +0300

Mališa Vučinić writes:
> 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.

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

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

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

> 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 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. 
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 10 Sep 2018 12:30:00 +0200

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

> timeout

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.

> there is no point of allowing it to do it again, lets just drop the

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.

> quite good DoS device for 802.15.4 devices in 2.4 GHz band...

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

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

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

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

> this

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.

> alleviates
> I think JP can be more resistant to DoS if it remembers something.

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

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

> reply packet back to joining node which of course does not ACK the

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.

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