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

From: Mališa Vučinić <[email-masked]>
Date: Tue, 17 Jul 2018 17:37:48 +0200

Hi Tero,

Thank you for this extensive review! See my responses inline.

Mališa

On Thu, Jun 28, 2018 at 12:24 AM Tero Kivinen <[email-masked]> wrote:

> In section 3 there is text saying:
>
>    The "network identifier" uniquely identifies the 6TiSCH network in
>    the namespace managed by a JRC.  Typically, this is the 16-bit
>    Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
>
> Note, that the PAN ID is not stable. The PAN coordinator is expected
> to change to use new PAN ID if it detect another network using the
> same PAN ID, i.e., if there is PAN ID conflict. See section 6.3.2 of
> the IEEE 802.15.4-2015.
>
> Because of this it might be better to use something else as PAN ID if
> stable network identifier is needed. Also in quite many cases the PAN
> ID is not known beforehand, so configuring the PAN ID to the pledge is
> challenging, as is describied in the section 4.
>
> Using something like Network ID from the
> draft-richardson-6tisch-enrollment-enhanced-beacon, would provide
> better alternative.
>

Good point: we use the term "network_identifier" for precisely this purpose
-- allow future extensions where an extended ID from e.g.
draft-richardson-6tisch-enrollment-enhanced-beacon can be used. The current
text in the draft leaves open what ID is actually used, and as such PAN ID
is supported. I wouldn't want to preclude the use of PAN ID now, since this
is how most of the people currently deploy their networks.

Would a following resolution work for you:

OLD:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4]. Companion documents can specify the use of a
different network identifier for join purposes, but this is out of scope of
this specification.  Such identifier needs to be carried within Enhanced
Beacon (EB) frames.

NEW:
> Typically, this is the 16-bit Personal Area Network Identifier (PAN ID)
defined in [IEEE802.15.4].  *However, PAN ID is not considered a stable
network identifier as it may change during network lifetime if a collision
with another network is detected.* Companion documents can specify the use
of a different network identifier for join purposes, but this is out of
scope of this specification.  Such identifier needs to be carried within
Enhanced Beacon (EB) frames.

In section 4 there is text saying:
>
>     o Pre-Shared Key (PSK).  The JRC additionally needs to store the
>       pledge identifier bound to the given PSK.  The PSK SHOULD be at
>       least 128 bits in length, generated uniformly at random.  It is
>       RECOMMENDED to generate the PSK with a cryptographically secure
>       pseudorandom number generator.  Each (6LBR) pledge SHOULD be
>       provisioned with a unique PSK.
>
> This text is fine, but knowing that most of the vendors in this space
> have been known to use unsafe methods like scrambling, encrypting,
> hashing, or macing serial number or EUI-64 address to generate "random
> unique PSKs" (or simply using fixed PSK for all devices), it might be
> good idea to provide bit more emphasis on the unique properly
> generated PSK, even when it is outside the actual scope of this
> document. Or add something like that to the security considerations
> section.
>

Göran Selander also raised an issue about this text. My response was:

> I would like to avoid referencing any particular method of generating the
PSK, I think that it would be enough to stress that the PSK that ends up
being provisioned to the pledge should meet certain statistical properties
(e.g. unpredictability, entropy).

Is this OK for you?

> In section 5.2 there is text saying "How JP accepts these unprotected
> frames is discussed in Section 6. ", but this same thing also applies
> to the section 5.3.1 too. I.e., the Join request from the pledge to JP
> is also unauthenticated and unencrypted.
>
> Perhaps that should be noted also there.
>

Sounds good.

In section 5.3.2 there is text saying:
>
>                             The JP operates as the application-
>    layer proxy, and does not keep any state to forward the message.
>
> This is not completely true. It needs to keep state to know when the
> pledge starts joining process and it needs to keep it until the pledge
> finishes it as it needs to allow pledge to send unencrypted and
> unauthenticated frames through it as explained in section 6.
>
> I.e., JP do store state for each pledge, at least for the secExempt.
> Also during this phase the pledge will be using its extended address,
> so that is also used by the JP to know which pledges are in progess of
> joining.
>

The point that you bring up here is essentially an implementation decision.
There is nothing that prevents a JP from creating an ephemeral unsecured ND
entry and setting secExempt for it in MAC security tables once JP receives
a CoAP response with Stateless-Proxy option set. The value of
Stateless-Proxy option is a byte string meaningful only to the JP, so JP
can encode there whatever it may need to operate statelessly. Off the top
of my head, I don't really see what else it would need to transport in
Stateless-Proxy except for the pledge's EUI-64.

Regarding the point that JP needs to know which pledges are in progress of
joining, I don't see why this is at all relevant to the JP. JP simply
forwards everything that it receives into the network (bandwidth caps
assumed), for "the duration of the join process". Now, the last part is a
bit tricky as the network needs to propagate coordinator's decision whether
joining is permitted. See below.

> Also section 7 says that JP does keep separate neighbor cache for
> untrusted entries, so that is even more state it will keep...
>

In fact, we were quite close on removing the need for ND between the pledge
and the JP but it was finally deemed to risky in terms of compliance with
IPv6 specs.

The current configuration in the draft mandates that insecure and secure
caches are separated. JP can implement this as a single insecure entry,
that is ephemerally instantiated every time a Join Response is received
from JRC with Stateless-Proxy set, as discussed above. In this case, if N
pledges join over a single JP, no more than a single entry at a time needs
to be filled, reducing significantly the DoS space.

> In section 6 there is text saying:
>
>
>                                            How the JP learns
>    whether the join process is ongoing is out of scope of this
>    specification.
>
> This is very important part of the process, and I think it should be
> part of this document, and not out of scope for this document. Which
> document will specify this if not this?
>

I brought up this comment as part of my IETF102 presentation. We discussed
the issue during IETF98 in Prague.

Essentially, we need to signal in EBs whether the join process is ongoing
and to propagate this information from DAG root downwards. One proposal at
IETF98 was to (ab)use one value of the Join Metric, e.g. 0xFF, for
signaling that join is not permitted. When a JP sees Join Metric == 0xFF in
the EB of its RPL preferred parent, it diffuses it in the EBs it generates
itself.

It was deemed better to define a special IE that would carry this and other
potentially useful information. Michael has been leading this work ever
since with draft-richardson-6tisch-enrollment-enhanced-beacon, and I think
"proxy prio" serves this purpose.

The basic idea was to allow for e.g. a button press on the DAG root that
will enable the join in the whole network.

Options to proceed:

Option 1) Keep this work in
draft-richardson-6tisch-enrollment-enhanced-beacon. Not ideal because of
the timeline.

Option 2) Use simplified version of (ab)using Join Metric and add that to
draft-ietf-6tisch-minimal-security.

Option 3) Add a new CoJP parameter that JRC can set using the *Parameter
Update Request* message that would mean "start acting as a JP for N
minutes" or something similar. With this, JRC would be able to instruct
each node in the network to start accepting join packets, but it would
require JRC to reach out to each node individually.

Not sure what is the best way to proceed, let's discuss tomorrow.

My guess is that JP willing to act as JP will receive first frame from
> pledge and when it sees it, it will start joining process, start
> forwarding the frames and mark that given extended address as
> something that is allowed to bypass security by setting secExempt for
> that extended address.
>

As explained above, JP does not need to do this as it can instantiate all
this information from Stateless-Proxy on-the-fly.

> The question is how can the JP know when the pledge is done. Can it
> just trust that there will be exactly one Join Response, and forward
> that and then clear out the secExempt flag from its tables and forget
> the pledge? Or should it just timeout the secExempt entries after
> certain number of seconds of inactivity? Or even pledge sending some
> kind of notify to JP using its extended address and link key to tell
> he is done?
>

No need for any of this if a bandwidth cap is implemented at JP to protect
the network and the intermediate nodes do not react with the Scheduling
Functions to unauthenticated traffic.

JP does not need to know if a given pledge is done. There is no relation
between the pledge and the JP once the join protocol is over. Pledge may
very well never again speak to this JP if it finds a better parent once it
is able to decrypt RPL DIOs.

Fixing this here by specifying method for is solves the issue for
> good, leaving it out of scope will make hard to debug problems when
> different JPs uses different methods to know when pledge is done.
>

See above.

Again the section 7 says that it is out of scope how JP decides to
> transtion from "untrusted to trusted cache".
>

Indeed, this sentence needs to be rephrased. The pledge and JP do not
"transition" each other from insecure to secure cache. When pledge becomes
a regular node and has L2 keys, a node that formerly acted as a JP may add
it to the ND table following a new ND  exchange, that *is* now protected
with L2 security.

There is no relation between this exchange and the one during join, where
pledge did not have keys.

I will take as an action point to clarify this in the draft.

> The proposed solution given there does not work. The text says:
>
>                                        One implementation
>    technique is to use the information whether the incoming frames are
>    secured at the link layer.
>
> The unauthenticated and unencrypted frames use extended address as
> their level 2 addresses. After joining process the pledge might move
> to use short address provided to it by the JRC. As far as I understand
> the message from JRC to pledge is encrypted, and JP cannot read it,
> thus JP cannot learn what will be the short address matching the
> pledge it has in its tables.
>

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?

A pledge obtains a short address, configures it in L2 and L3 and starts
using it. Neighbor nodes (some of them formerly acted as a JP) do not need
to be aware who this node was as a pledge, as long as the node proves
possession of correct L2 keys by generating fresh, L2-secured frames.

Does that make sense?

>
> Of course it can guess, that if there is pledge with extended address
> of 0x1234567812345678 and then suddenly there is new node with short
> address of 0x0010, then most likely they are same, but this might not
> be good idea to try to do guessing of the identities.

See above.

> Also outsiders
> can also do the same guess, so they will be able to coordinate the
> short address 0x0010 to the extended address quite easily, even when
> the section 11 claims otherwise.
>

I see this as a privacy concern, where based on the timing, an attacker
would be able to correlate an extended address of the pledge with the short
address. Do you have a proposal on how we could tackle this?

I think the overall protocol would be better if the JP would get
> information about the successful completion of the joining process.
> I.e., if the JRC sending frame to be forwarded to pledge by JP, would
> also indicate something in the frame that tells JP that this pledge is
> now done, and it can be removed from the untrusted neighbor cache, and
> from the secExempt list.
>

See explanations above and let me know if it makes sense.

In section 8.1. the ID of the pledge is 0x00, but ID of JRC is
> 0x4a5243. As far as I understood the OSCORE for the security it would
> be enough to just use any different value for them, i.e., using 0x00
> for pledge and 0x01 for JRC. Why does the JRC use 0x4a5243 ("JRC")
> instead of just 0x01?
>

The OSCORE ID of the JRC ("JRC") is present in the packets only for
Parameter Update Request messages, i.e. from JRC to nodes. It is not
present in Join Request or Join Response messages and therefore does not
take any space there.

When a Parameter Update Request arrives at a node, "JRC" ID is used to look
up if there is a security context available. I thought it would be better
to use something more explicit than 0x01 for this ID in order to allow
nodes to have other OSCORE contexts for application purposes, whose ID can
be a single byte value, e.g. 0x01.

Does that make sense?

> The pledge identifier is used as ID context, which is added to both
> sender and recipient key generation so in all cases the final keys are
> different even if the PSK is same as long as the pledge identifier is
> unique. If pledge identifier and PSK are not unique, then we do have
> nonce collision as both devices start with sequence number of 0.
>

Right, the use of a 3-byte identifier was simply for being (more) explicit.
Let me know if you agree or not with the reasoning above.

> I was just about to point out about the persistency of the sequence
> numbers, and I was more than happy to see that it was actually already
> mentioned in the draft. Good work!
>

Thanks!

>
> (My guess is that there is huge number of IoT devices which do not do
> that properly)
>
>
> In section 9.3.2 there is description about the rekey algorithm which
> has following sentence:
>
>                                                         Upon
>       reception and successful security processing of a link-layer frame
>       secured with a key from the new key set, a non-6LBR node MUST
>       remove any old keys it has installed from the previous key set.
>
> I think it would be better to wait for a while before deleting the old
> set, but immediately move to use the new set for transmissions. I.e.,
> we might have node B and C, which both have old and new keys, their
> parent A sends an EB with new keys out, but node C is not able to
> receive it correctly. Now if C wants to send frame to A or B, it will
> still be using old key as it has not yet seen any new frames. Both A
> and B will throw that frame out as it is using old key. If this would
> be changed to say that "node MUST remove any old keys after delay of N
> seconds" (or delay of N slotframes or whatever).
>

I agree with this resolution. Let's see if there are any opposing opinions
for including this change tomorrow at the meeting.

>
> In section 9.3.2 there is text about link-layer short address, but
> there is no requirement for the JRC, that mandates it to ensure that
> it will be unique at any given time. I.e., the security of the network
> will depend that there is never two sort address using same keys at
> the same time. I.e., if JRC is restarted and its loosing the state of
> which short addresses are allocated it MUST rekey the whole network
> with newly generated key (and as it cannot do that by sending updates,
> as it does not know who is part of network, it must force everybody to
> rejoin).

> If JRC gives out the short address without giving lease_time, it MUST
> not ever reuse those short addresses. If it does give lease time it
> should wait for some guard time before reusing short address that has
> already been expired. This guard time should include cases where node
> has sent out message and the message is waiting in transmit queue, but
> has not been sent out yet, while the address expires, and node might
> not have code to purge the tranmission from the queue. So adding guard
> time that is in order of maximum wait time for sending frame or so,
> would be good.
>

Sounds good. Are you ok to add an explanation encompassing your two
paragraphs from above in Security Considerations section and point to it in
the CBOR parameter definition paragraph?

> In section 9.3.2.2 there is text saying that "short address is unique
> LOCALLY in the network". This is incorrect. It needs to be unique in
> the whole network using the same key, i.e., globally in the network
> using the same key and part of the same TSCH network. I know that some
> vendors have been using duplicate short addresses for different parts
> of the network, when there is no risk of them overhearing each other
> for other 802.15.4 networks, but that is not safe to do in TSCH when
> short addresses are used in the nonce.
>

Good point. I will add this to security considerations.

>
> I do understand that the text is trying to say it does not need to be
> unique in the global internet, but in the local network it needs to be
> unique globally inside the whole network.
>
> Note, that short address of 0xfffe (associated, but not given short
> address) and 0xffff (broadcast) are reserved in 802.15.4-2015 and
> cannot be used. Also some other 802.15.4 extensions like L2R (layer 2
> routing) 802.15.10 do reserve additional set of short addresses for
> example for multicast (0xff00-0xfffd).
>
> Most likely this text should be reflected to that, saying that if
> address is 0xfffe, then pledge has joined the network, but JRC decided
> not to give him short address (for example it is running out of them),
> and the device should use extended address to talk to others.
>
> If JRC gives out short address of 0xffff, then it should be considered
> invalid.
>

All good points, thanks! In CoJP section, I tried to make the text a bit
generic in order to enable the use of CoJP with different link-layer
technologies, i.e. other than 6TisCH, but I will definitely add these in
the context of 802.15.4.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Jul 2018 23:13:22 +0300

Mališa Vučinić writes:
> > Typically, this is the 16-bit Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
> Companion documents can specify the use of a different network identifier for join purposes, but
> this is out of scope of this specification.  Such identifier needs to be carried within Enhanced
> Beacon (EB) frames.
> 
> NEW:
> > Typically, this is the 16-bit Personal Area Network Identifier (PAN ID) defined in [IEEE802.15.4].
>  However, PAN ID is not considered a stable network identifier as it may change during network
> lifetime if a collision with another network is detected. Companion documents can specify the use of
> a different network identifier for join purposes, but this is out of scope of this specification. 
> Such identifier needs to be carried within Enhanced Beacon (EB) frames.

Yes, I think so. 

> > I would like to avoid referencing any particular method of
> generating the PSK, I think that it would be enough to stress that
> the PSK that ends up being provisioned to the pledge should meet
> certain statistical properties (e.g. unpredictability, entropy).
> 
> Is this OK for you?

I would like at least some text in the security considerations section
warning about the common wrong ways of generating PSK. The IoT vendors
are quite often care more about the time to market than the security,
thus do use unsafe practices as they do not know better.

> The point that you bring up here is essentially an implementation
> decision. There is nothing that prevents a JP from creating an
> ephemeral unsecured ND entry and setting secExempt for it in MAC
> security tables once JP receives a CoAP response with
> Stateless-Proxy option set. The value of Stateless-Proxy option is a
> byte string meaningful only to the JP, so JP can encode there
> whatever it may need to operate statelessly. Off the top of my head,
> I don't really see what else it would need to transport in

Actually if you follow the 802.15.4 and someone sends you unsecured
frame the security processing will reject it with
IMPROPER_SECURITY_LEVEL error (section 9.2.4 f) of 802.15.4-2015). The
MAC will then indicate (section 6.7.2) this to the upper layer with
MLME-COMM-STATUS.indication primitive which will get the addresses
etc, but does not get the actual frame. Then the upper layer can
install the secExempt flag in the security tables (== creates state),
and then next packet from the same node will be allowed to go through
the security processing. So there is always some state stored, just to
be able to receive the unprotected frame.

Note, that node is allowed NOT to ack the incoming frame if the
security processing fails, so this second frame will be MAC layer
retransmit, not upper layer retransmit.

> Regarding the point that JP needs to know which pledges are in
> progress of joining, I don't see why this is at all relevant to the
> JP. JP simply forwards everything that it receives into the network
> (bandwidth caps assumed), for "the duration of the join process".
> Now, the last part is a bit tricky as the network needs to propagate
> coordinator's decision whether joining is permitted. See below.

JP needs to know when it can clear the secExempt flag for the node in
the security tables. If it does not clear it, then it will attackers
to send clear text packets claiming to come from the joining node,
even after it has already joined, and should have installed the keys.

Normally this is done when the JP would install pairwise keys for the
joining node, but in this case I think we global keys which means
there is no pairwise keys, but clearing the secExempt is still
important.

Note, that we most likely do want to keep it until the node actually
finishes the join process, and not for just one frame, just in case in
the future the joining process takes more than one round trip.

Also to be able to allow node to send ack back to you requires you to
have secExempt flag for that node when you are sending him a frame
with too lower security level.

I.e., you cannot even transmit a frame to joining node and get ACK
back unless you have secExempt for joining node.

> I brought up this comment as part of my IETF102 presentation. We
> discussed the issue during IETF98 in Prague.
> 
> Essentially, we need to signal in EBs whether the join process is
> ongoing and to propagate this information from DAG root downwards.
> One proposal at IETF98 was to (ab)use one value of the Join Metric,
> e.g. 0xFF, for signaling that join is not permitted. When a JP sees
> Join Metric == 0xFF in the EB of its RPL preferred parent, it
> diffuses it in the EBs it generates itself.

I read that text differently, i.e., not to indicate wheter joins are
allowed in the network, but whether this specific joining node is
doing join process through this JP just now.

For example if someone is doing joining process through the JP, then
it would not be nice for the JP to decide that now it is good idea to
save energy and go to sleep for next 5 minutes.

I.e., thats why I think perhaps the messages from the JRC should have
also something that the JP can check to see whether the joining
process of the joining node is finished and successful (meaning that
after sending that frame to the joining node, it can remove secExempt
and ND entries for the node), or whether it failed (in which case it
can blacklist the node, so no new joining process can be retried for
next n minutes or hours etc).

> It was deemed better to define a special IE that would carry this
> and other potentially useful information. Michael has been leading
> this work ever since with
> draft-richardson-6tisch-enrollment-enhanced-beacon, and I think

I think that is separate issue, and I think that might be left out
from this document. 

> The basic idea was to allow for e.g. a button press on the DAG root
> that will enable the join in the whole network.
> 
> Options to proceed:
> 
> draft-richardson-6tisch-enrollment-enhanced-beacon. Not ideal
> because of the timeline.
> 
> Option 3) Add a new CoJP parameter that JRC can set using the *Parameter Update Request* message
> that would mean "start acting as a JP for N minutes" or something similar. With this, JRC would be
> able to instruct each node in the network to start accepting join packets, but it would require JRC
> to reach out to each node individually.
>  
> As explained above, JP does not need to do this as it can
> instantiate all this information from Stateless-Proxy on-the-fly.

I assume you mean it just need to create state for very short periods
of time, not for the whole joining process duration?

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. 

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

On the other hand node only need to know extended and short address
for nodes it is talking to, so if there is some other mechanism to get
them that is fine.

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 see this as a privacy concern, where based on the timing, an
> attacker would be able to correlate an extended address of the
> pledge with the short address. Do you have a proposal on how we
> could tackle this?

No. I think privacy concerns are so hard that we cannot solve them. We
can help them by doing things we do here, i.e., assigning short
addresses which are transmitted in encrypted format, but that does not
solve the problem, it just makes it harder. I think that is only thing
we can do, but we should not try to claim this solves the problem.

> paragraphs from above in Security Considerations section and point
> to it in the CBOR parameter definition paragraph?

Sure.

> Good point. I will add this to security considerations.

This of course also means that short addresses cannot be generated by
hashing of the extended address or similar means locallly and then
sending out neighbor discovery to see if someone is using that
address, and if so regenerate new one. The node using the same short
address might not be in radio range, or might be sleepign etc.

So it is really important that short addresses are always assigned by
JRC and JRC takes care of them being unique.

> All good points, thanks! In CoJP section, I tried to make the text a
> bit generic in order to enable the use of CoJP with different
> link-layer technologies, i.e. other than 6TisCH, but I will
> definitely add these in the context of 802.15.4.

Good.
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Jul 2018 12:51:23 +0200

(snip)

> thus do use unsafe practices as they do not know better.

That's fine for me. I will get back to you with specific text/commit when I
implement this.

> retransmit, not upper layer retransmit.

Assumption (1): JP has the information that the join process is *allowed*.
I see this as a centralized decision, JP simply enforces it.

Assumption (2): JP removes all the state about the pledge, including L2
security table entry with secExempt set, as soon as it forwards a packet
originating from the pledge towards the JRC.

Assumption (3): JP adds an entry with secExempt set for the pledge as soon
as it receives a Stateless-Proxy. Issue: When does JP remove this entry?
See below.

You seem to agree that there is no problem for the frames going from JP to
the pledge. Right?

The issue you raise on keeping state at JP is to allow the pledge to sends
frame(s) to the JP.

Let me try to summarize:

(1) The very first frame sent by the pledge, in a fully-compliant
implementation of 802.15.4 security processing gets rejected no matter
what. A logical choice for the JP is then *not* to ACK this frame at L2.

(2) Upper layer of JP then adds an entry for the source address of the
rejected frame and sets the secExempt for it. (because join process is
allowed)

(3) L2 retransmission of the frame dropped in (1) is sent by the pledge.
The frame falls into the secExempt case while processing at JP and is
passed to the upper layer.

(4) JP keeps the entry with secExempt (i.e. state) *until* an upper layer
creates a packet destined for the JRC with Stateless-Proxy set. In that
moment, no more state for the pledge exists at JP. Issue: CoAP message sent
by the pledge is malformed and JP discards it, DoS attack where pledge does
ND but does not send Join Request. It would therefore be prudent to expire
this entry at JP after a short timeout.

For the upper-layer protocol, this seems to degrade performance in case a
pledge generates a frame  *after* JP has already forwarded one packet from
the pledge to the JRC and used Stateless-Proxy. In that case, pledge will
need to do one L2 retransmission to get the packet processed by JP. Agreed?

For CoJP, this will be the case for CoAP-layer (CoJP-layer to be precise)
retransmissions. You are also worried for future extensions where pledge
sends more than one *packet* (multiple L2 fragments are OK) before getting
a response from the JP.

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?

See above.

> the future the joining process takes more than one round trip.

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.

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

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.

[1] Broadcasting strategies in 6TiSCH networks:
http://ckan.iotlab.eu/dataset/3b96c98c-b5a4-4153-82ee-6c7cd6707232/resource/68289058-b646-441f-b37a-c138fa25549f/download/broadcasting-strategies-in-6tisch-networks.pdf

> next n minutes or hours etc).

I agree with you on the blacklisting part, see below. I don't agree on
adding signaling to JP, as explained above.

> simply consume network resources all the time, with repeated tries to

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.

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?

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

> for nodes it is talking to, so if there is some other mechanism to get

Yes, all of this happens once the pledge joined and obtained the group
key(s).We could maybe use ND for this purpose but how neighbor nodes
discover and map their extended addresses to short seems definitely out of
scope of minimal-security.

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

> we can do, but we should not try to claim this solves the problem.

If I rephrase the Privacy Considerations text adding something like:

 "Note that an eavesdropper with access to the radio medium during the join
process is able to correlate the assigned short address with the extended
address based on timing information with a non-negligable probability. This
probability decreases with an increasing number of pledges joining
concurrently."

and relax the statement that the assignment of short addresses "mitigates"
the risks to "reduces", would that be OK for you?

> JRC and JRC takes care of them being unique.

Good point, will get back to you with text/commit when I implement this.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Jul 2018 21:25:11 +0300

Mališa Vučinić writes:
> For the upper-layer protocol, this seems to degrade performance in
> case a pledge generates a frame  *after* JP has already forwarded
> one packet from the pledge to the JRC and used Stateless-Proxy. In
> that case, pledge will need to do one L2 retransmission to get the
> packet processed by JP. Agreed?
> 
> For CoJP, this will be the case for CoAP-layer (CoJP-layer to be
> precise) retransmissions. You are also worried for future extensions
> where pledge sends more than one *packet* (multiple L2 fragments are
> OK) before getting a response from the JP.
> 
> 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". 

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

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

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

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

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.

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.

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

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

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

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

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

>  "Note that an eavesdropper with access to the radio medium during
> the join process is able to correlate the assigned short address
> with the extended address based on timing information with a
> non-negligable probability. This probability decreases with an
> increasing number of pledges joining concurrently."

Sounds fine.

> and relax the statement that the assignment of short addresses
> "mitigates" the risks to "reduces", would that be OK for you?

Yes.
-- 
[email-masked]