Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello David:

Many thanks for your review. I do hope that you found it interesting.

> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?

This is really a MAC layer question for IEEE. I'm cc'ing Thomas who was one of the inventors of TSCH, as well as Michael and Malisa who led the join process study.

Time synchronization (date):
--------------------------------------
For all I know, the time sync is about giving a epoch time from which an Absolute Slot Number (ASN, expressed in slot duration e.g., 10ms) is derived.
ASN plays a key role as it is used in NONCE. An attack that one could think of would be to fool the new node into thinking that ASN is earlier. This could happen before the keys are exchanged, or if an authorized peer is compromised.
For the former, I'll defer to the others to answer fully how we protect the new comer. 
For the latter, 6TiSCH provides an additional protection since we derive time from a RPL parent. RPL has its own protections, some of them in the standard itself, some of them in zerotrust papers that need publishing. 

Time synthonization (precise tic, hourless)
--------------------------------------------------------
This is the process whereby a node corrects its tic to realign with the parent. ASN is not changed but the drift of crystals is compensated.
An attacker could try to inject a sense of time that it slightly shifted to the point that the node lose sync with the rest of the network (the guard time is like an event horizon). Then again, RPL provides an additional protection on top of the MAC provisions.


In the meantime your remark reserves some text. Note that the dependency on time is inherited from DetNet and TSN, and DetNet has text about it that we can reference.

In conjunction with Andrew's review I'd propose:
"
    The operation of 6TiSCH Tracks inherits its high level operation from DetNet
    and is subject to the observations in section 5 of [ietf-detnet-architecture].
    As discussed there, measures  must be taken to protect the time 
    synchronization, and for 6TiSCH this includes ensuring that the ASN, which is
    used for the computation of NONCE, is not compromised. Also, the installation
    and maintenance of 6TiSCH Tracks depends in the availability of a controller
    with a PCE to compute and push them in the network. When that connectivity
    is lost, existing Tracks may continue to operate until the end of their
    lifetime, but cannot be removed or updated, and new Tracks cannot be
    installed. As with DetNet in general, the communication with the PCE must be
    secured and should be protected against DoS attacks, and the discussion on
    the security considerations defined for Abstraction and Control of Traffic
    Engineered Networks (ACTN) applies equally to 6TiSCH.
"

Does that sound good?

Pascal

> -----Original Message-----
> From: David Mandelberg <[e-mail]>
> Sent: lundi 24 juin 2019 03:22
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: secdir review of draft-ietf-6tisch-architecture-21
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> The summary of the review is Ready with nits.
> 
> The review deadline for this was really short, so I didn't have a chance to read
> this as closely as I would have liked. That said, from skimming the document
> and reading the sections that looked most interesting, it looks pretty good. The
> security considerations section covers what I expected it to. I have only one
> question/concern:
> 
> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?