Thanks again, Linda. >> I have reviewed this document as part of the SEC area 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 >> >> Section 6, paragraph 4 highlights the customer's responsibility for >> end-to-end security, even when utilizing secure network slices as a >> service provided by their service providers. This raises several questions: >> >> - Does the document imply that customers should not trust the secure >> network slices offered by service providers? > > Essentially, yes. No one should trust a security service that they cannot, themselves, verify. [Linda] sometimes a customer doesn't have the ability to verify the security services. That is why they buy security services from their trusted providers. The point is that the customer *never* has the ability to verify a security service. They hand over their unprotected traffic to the service provider on the understanding that the traffic will be protected edge-to-edge and delivered unprotected at the destination. So the crunch is "trusted provider." The level of trust depends, of course, on the nature of the traffic, the trustworthiness of the provider, and the nervousness of the customer. However, a customer that wishes to be *certain* that the traffic is adequately protected must take responsibility themselves. > However, the text doesn't go quite that far. It says that the customer is responsible for ensuring > the privacy and integrity of their traffic. If a customer chooses to do that by subscribing to a > service that claims to provide the necessary measures, then the customer is free to do so. [Linda] It might be better to say something along the line of Shared Responsibility for end to end security when using secure network slices. I disagree. Even if the protection is delegated to another party, the responsibility for protecting the traffic lies with the owner of the traffic. >> - It might be beneficial for the document to specify criteria or >> guidelines that customers can use to evaluate the security and >> integrity of secure network slices as a service. Providing such >> criteria would help customers make informed decisions and ensure they meet their security requirements. > > It might be, although that is probably way beyond the scope or competence of the authors. > > If pushed, I would say that no privacy or integrity service that cannot be independently verified by the > customer can be trusted. At this point, what do you say we leave this to the Sec AD to decide whether or not to follow-up on this point? A -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
