Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Pascal!

Thank you for publishing -25.  It addresses my concern.  I have one detailed response below about a possible edit based on your question.

Roman

> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[e-mail]]
> Sent: Thursday, August 22, 2019 11:19 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-
> 24: (with COMMENT)
> 
> Hello Roman:
> 
> Many thanks for your review, your time is much appreciated.
> 
> Please see below:
> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > ** Why are both Section 3.4 and Section 4.4 needed?  Both appear to
> > explain the four scheduling mechanisms.  Section 4.4. appears to have
> more details.
> 
> Section 3 is a high level architecture, section 4 a low level. Having both in 1
> document was  a conscious decision since the early review by Ralph. We split
> in a high and a low level architecture and kept them combined to avoid the
> explosion of documents. For the same reason, we later incorporated the
> terminology that was initially a separate spec.
> 
> As a result this draft has 2/3 documents in one, with commonalities in section
> 3.4 and 4.4 for instance. That's where we are and as you say, there is no
> fundamental new reason to undo that.
> 
> There was a desire to make section 4 self-sufficient, with the idea of possibly
> splitting section 3 and 4 which we never did. Still it might be useful to the
> reader who just reads that section.
> And there was a desire to have a discussion at the high level architecture on
> this topic so removing 3.4 is not good either.
> 
> I'm quite afraid to destabilize the document by doing a major change now.

Understood.  I can appreciate the intent here.

> 
> > ** Section 3.6. Per the summary table in this section, what is the
> > routing technique “reactive P2P”.  It doesn’t appear to be explained in the
> text above.
> 
> PT> I removed the P2P which is not explained. The relevant text
> PT> otherwise is
> "
> or by in a distributed fashion using a reactive routing protocol and
>    a Hop-by-Hop scheduling protocol.
> "
> 
> 
> > ** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling column
> > in the summary table, to what does the “TBD”?
> 
> PT> good catch. It is now AODV RPL, updated the picture
> 

Thanks.

> > ** Section 6.  In reviewing the Security Considerations section, there
> > is a substantial amount of technical detail (thank you!).  However,
> > despite this detail, understanding the overall security properties of
> > the architecture and associate implementations mechanisms used by the
> > architecture was challenging for me.  Specifically, if 6TiSCH “is
> > subject to the observations in section 5 of
> > [I-D.ietf-detnet-architecture]”, then per [I-D.ietf-detnet-
> > architecture] it should provide “confidentiality of data traversing
> > the DetNet”, “authentication and authorization … for each connected
> > device”, availability, and precision timing. The text needs to be
> > clearer on how those properties are realized, and if there are
> > residual threat.  My recommended way to realize this clarity is restructure
> the text into blocks around the relevant security properties and explicitly
> state the property as an introduction.
> 
> PT >  I made an attempt at it, please see -25 once published.
> The outlook would be
> 
>    6.  Security Considerations . . . . . . . . . . . . . . . . . . .  51
>      6.1.  Availability of Remote Services . . . . . . . . . . . . .  51
>      6.2.  MAC-Layer Security  . . . . . . . . . . . . . . . . . . .  52
>      6.3.  Time Synchronization  . . . . . . . . . . . . . . . . . .  53
>      6.4.  Selective Jamming . . . . . . . . . . . . . . . . . . . .  53
>      6.5.  Validating ASN  . . . . . . . . . . . . . . . . . . . . .  53
>      6.6.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . .  54
>      6.7.  Deeper Considerations . . . . . . . . . . . . . . . . . .  54
> 
> More below

This new text if very helpful and addresses my concern.  Thank you.

> 
> > A few additional points:
> >
> > -- Per precision timing, the text in this section says “measures must
> > be taken to protect the time synchronization, and for 6TiSCH this
> > includes ensuring that the Absolute Slot Number (ASN), which is used
> > as ever incrementing counter for the computation of the Link-Layer
> > security nonce, is not compromised, more below on this.”  In the
> > subsequent text there is “[t]he standard [IEEE802154] assumes that the
> ASN is distributed securely by other means.
> > The ASN is not passed explicitly in the data frames”.  To confirm, is
> > this the intended guidance on avoiding “compromising” the ASN –
> > distribute it out of band and don’t pass it in the data frame?
> 
> PT > ASN is not passed in the frame because it would was 5 octets. A network
> is non-functional if nodes do not have the right sense of ASN so if the
> network works, it means the 5 bytes can be saved.
> PT > With 6TiSCH, ASN is learned from unsecured beacons, and needs t be
> proven before used. We hint how that is done in this spec, and detail in
> minimal security.
> PT > once installed and as long as the node is synchronized to the network
> ASN is implicit and cannot be compromised.
> PT > One of the new sections deals with ASN protection and the details are in
> the 6tisch minimal security draft
> 
> > -- Per confidentiality (but it is really more than that), a series of
> > security mechanisms/assumptions are inherited from [IEEE Std.
> > 802.15.4] around link- layer security. They need to be explicitly
> > stated (i.e., confidentiality, authenticity, with what crypto,
> > relative to whom, etc.).  The operational details of key management has no
> treatment.
> 
> PT>
> PT > For the most part, I pointed at the minimal security draft for more
> details, made it a normative reference: this comes from a chat with Ben
> Kaduk and the authors of minimal security. We wish to place the gory details
> in the security section of minimal security, and that includes key
> management. Still I added some of the text below, a section on rekeying,
> and MAC security, which is basically CCM* with a network-wide key, using
> ASN and MAC addresses in the nonce:
> "
> 
> 6.4.  Rekeying
> 
>    Though it is possible to use peer-wise keys, a 6TiSCH network
>    typically uses a network-wide key that is common for all
>    transmissions in the LLN.  [I-D.ietf-6tisch-minimal-security] enables
>    to obtain that key and to rekey the network when needed.  Since the
>    ASN is expressed in 5 octets, it should never wrap during a network
>    lifetime, and it is possible that a network never needs to rekey.
> 
>    Still, there are occasions where rekeying is necessary, for instance:
> 
>    o  An unwelcome node has joined and needs to be expelled
> 
>    o  The JRC needs to reassign a short address that was already
>       assigned while the current network key was in use.
> 
>    o  Resetting Epoch time when rebooting the network.
> "
> 
> " 6.2.  Relative to MAC-Layer Security
> 
>    This architecture operates on IEEE Std. 802.15.4 and expects the
>    Link-Layer security to be enabled at all times between connected
>    devices, except for the very first step of the device join process,
>    where a joining device may need some initial, unsecured exchanges so
>    as to obtain its initial key material.  In a typical deployment, all
>    joined nodes use the same keys and rekeying needs to be global.
> 
>    The 6TISCH Architecture relies on the join process to deny
>    authorization of invalid nodes and preserve the integrity of the
>    network keys.  A rogue that managed to access the network can perform
>    a large variety of attacks from DoS to injecting forged packets and
>    routing information.  "Zero-trust" properties would be highly
>    desirable but are mostly not available at the time of this writing.
>    [I-D.ietf-6lo-ap-nd] is a notable exception that protects the
>    ownership of IPv6 addresses and prevents a rogue node with L2 access
>    from stealing and injecting traffic on behalf of a legitimate node.
> 
> ...
> "

Works for me.

> > -- Per availability, the text notes “communication with the PCE must
> > be secured and protected against DoS”.  Secured how?
> 
> PT > This is what section 9 of RFC 8453 discusses. Note that it mostly insists on
> PKI / AAA as opposed to delay attacks and black holes.
> How can take us in network architecture, isolation, firewalls. That seems to
> take us quite off topic , doesn't it?
> 
> 
> 
> 
> > ** Section 6.  Per “Section 9 of [RFC8453] applies equally to 6TiSCH”,
> > this reference organizes threats and mitigations around the CMI and
> > MPI interfaces.
> > What is the analog to those in this architecture?
> 
> PT> This is the same parallel as done in the DetNet architecture from which
> this is inherited, using the same reference.
> The security issues that arise when a centralized control is separate from the
> forwarding plane are similar: rogue access to one of the components, and
> attacks on the connectivity on the control path, including interception,
> blackholing or latency injection.
> I can remove the reference and replace by text like the above, please advise.
> In parammme please condsider the security section of the detnet
> architecture, it is in AUTH 48 but still changeable.

I would recommend taking a hybrid approach.  I think it's worth making the more specific statement you propose but also citing that the more general version of this consideration comes from [RFC8453].

> 
> >
> > ** Section 6.  Please provide a citation for “CCM*”
> 
> PT > Added

Thanks.

> > ** Editorial
> > -- Section 3.1. Typo. s/an homogenous/a homogenous/
> >
> > -- Section 3.5. Typo. s/[RFC6550]is/[RFC6550] is/
> >
> > -- Section 3.6. Typo. s/A central/a central/
> >
> > -- Section 3.6. Typo.  s/an hybrid/a hybrid/
> >
> > -- Section 3.7.  The paragraph starting with “The reference stack that
> > the 6TiSCH architecture presents …” doesn’t seem to add any clarity.
> >
> > -- Section 4.2.1. Typo.  s/(JP):/(JP),/
> >
> > -- Section 4.2.2.  Typo. /ND ot the/ND to the/
> >
> > -- Section 4.3.1.1. Typo. s/are are/are/
> >
> > -- Section 4.3.1.1. Duplicate phrase.  “added/moved/deleted, in which
> > case 6top can only act as instructed,” appears twice.
> >
> > -- Section 4.3.5.  Typo.  s/an height/a height/
> 
> PT> all nits processed, many thanks!

Thanks for these changes.

 
> I will publish 25 to provide a abase on which we can refine in the next
> minutes.
> Please consider it before replying to this mail.
>
> Many thanks again!
> 
> Pascal