**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