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

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

Hello Roman:

I elided the pieces where we are in sync
 

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

PT> I caught that hint and gave it a try in 25, which is already a change in that direction:

   As with DetNet in general, the communication with the PCE must be
   secured and should be protected against DoS attacks, including delay
   injection and blackholing attacks, and secured as discussed in the
   security considerations defined for Abstraction and Control of
   Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which
   applies equally to DetNet and 6TiSCH.  In a similar manner, the
   communication with the JRC must be secured and should be protected
   against DoS attacks when possible. 

PT> I'm happy to modify it deeper in 26, and would appreciate a suggestion : )

Many thanks again!

Pascal