Last Call Review of draft-ietf-mpls-sfl-control-04
review-ietf-mpls-sfl-control-04-secdir-lc-kaufman-2023-12-01-00

**Resending with corrected draft name and distribution list name**

From: secdir <secdir-bounces@ietf.org> On Behalf Of Charlie Kaufman
Sent: Friday, November 24, 2023 6:07 PM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mpls-sfi-control.all@ietf.org
Subject: [secdir] Secdir review of draft-ietf-mpls-sfi-control-04

Reviewer: Charlie Kaufman
Review result: Ready with Nits

I have reviewed this document as part of the security 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.

This ID specifies a new message type for MPLS control protocols for the purpose
of creating and maintaining MPLS synonymous flow labels. (I don't know what
those are, but don't believe I need to in order to complete this review). As
stated in Security Considerations, this is an extension to an existing protocol
that is already assumed to run over a secure channel, and this extension
introduces no additional MPLS security vulnerabilities. I agree with that
assessment.

My remaining comments are minor and not related to security.

p4-7: The indentation is confusing where the categories are indented more than
the individual items.

p5,7: It's potentially confusing to have two distinct flags named 'R'.

p6 0x12: It is not obvious how unsupported versions are supposed to be
supported. Does the responder echo back the entire message (including the
unrecognized version number) with an error indicator in a field that might have
moved in the new version of the protocol, or does it send back a message with a
version number if does understand (and if so, what does it do with the rest of
the message content).

p6 0x18 and 0x19: It is not obvious under what circumstances each of these
codes should be used. Perhaps they should be combined. Which applies if Message
Length and Num-SFL are inconsistent? And should the reply include the
inconsistent values?

There are places where looseness around time synchronization could be
troublesome. For example, the end of section 3.2.1 says: "A Querier MUST NOT
send an expired SFL to a Responder since to do so may invalidate another SFL
operation." But loose time synchronization means there will be a substantial
time when a Querier can't be sure whether an SFL is expired or not, and
therefore doesn't know whether it should send a "Refresh" or a "Request" to
reestablish / extend the life of an SFL.

p10 last paragraph of 3.2.3 talks about retrying failed Withdraw requests
without discussing why Withdraw requests would be expected to fail, and why
there isn't a similar discussion of other requests that might be failed and
possibly retried.

Typos:

p2: "MPLS network It" -> "MPLS network. It"
p2: "prodocols" -> "protocols"
p11: "introduced" -> "intruduces"

      --Charlie

Sent from http://aka.ms/weboutlook