Last Call Review of draft-ietf-detnet-mpls-05
review-ietf-detnet-mpls-05-secdir-lc-ladd-2020-03-10-00

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.