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 _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
