Reviewer: Watson Ladd Review result: Not Ready This is the secdir review of draft-ietf-detnet-mpls-05. Authors should treat these as any other Last Call comments. Apologies for the delays in completing this review. I am concerned that this document (and the related work) introduces some substantial differences from existing Internet architecture, and that inadequate attention is paid to the consequent security implications. Pointing to a separate, in progress draft I don't think is an adequate security consideration section. That's particularly true when we're discussing the network providing functions like duplicate packet dropping that are potentially quite expensive and which attackers may exploit to consume large amounts of resources. Saying that one can mitigate DoS on the edge of a DetNet domain isn't enough: how do you mitigate the DoS, or detect it? What if the edge is the problem? Are there resources that can be consumed in the center the edge doesn't know about? With confidentiality this draft mentions the possibility of link to link protection, ignoring the possibility of malicious nodes, and doesn't describe the way one actually uses that integration. It's not clear to me what the security goals are, and saying a mechanism may be used, without indicating how doesn't make it remediation for a security problem. I can think of a few ways to abuse the one-packet only service to rewrite flows with great ease. The Internet is composed of smart nodes at the edge and dumb forwarders in the middle. DetNet is a very different design, with significant complexity and state in the network, and guarantees not maintained by end nodes. This means that a lot that has been learned about Internet security doesn't apply, which raises a whole host of questions: what threat model is applied? Is it realistic? Are the properties such as bounded latency and low jitter maintained even in the face of adversarial behavior? While this may be appropriately handled at greater length in a separated draft, a tighter link to the mechanisms defined in this draft would be useful. It's very likely these have been discussed in the detnet wg at length as evidenced by the security considerations, but I'd like to see the MPLS draft reflect some of that conversation more directly. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
