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

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

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 <[e-mail]> 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.