Skip to main content

IETF Last Call Review of draft-ietf-mpls-mna-nrp-selector-03
review-ietf-mpls-mna-nrp-selector-03-secdir-lc-emery-2026-04-01-00

Request Review of draft-ietf-mpls-mna-nrp-selector
Requested revision No specific revision (document currently at 06)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2026-02-11
Requested 2026-01-21
Requested by Jim Guichard
Authors Tony Li , Vishnu Pavan Beeram , John Drake , Tarek Saad , Israel Meilik
I-D last updated 2026-05-05 (Latest revision 2026-05-05)
Completed reviews Rtgdir IETF Last Call review of -03 by Susan Hares (diff)
Secdir IETF Last Call review of -03 by Shawn M Emery (diff)
Genart IETF Last Call review of -03 by Vijay K. Gurbani (diff)
Opsdir IETF Last Call review of -03 by Xiao Min (diff)
Intdir Telechat review of -04 by Jen Linkova (diff)
Assignment Reviewer Shawn M Emery
State Completed
Request IETF Last Call review on draft-ietf-mpls-mna-nrp-selector by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/COUKLPDW2CSKjRNEl0zGCgww_qU
Reviewed revision 03 (document currently at 06)
Result Has nits
Completed 2026-04-01
review-ietf-mpls-mna-nrp-selector-03-secdir-lc-emery-2026-04-01-00
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 standards track draft specifies a set of Network Resource Partition (NRP)
Selectors that identifies i) what NRP the packet is associated with and ii) how
the packet is to be forwarded.  NRPs provide support of IETF Network Slice
services, which in turn provides network connectivity and how this network is
constructed.

The security considerations section does exist and discloses that the
forwarding network is insecure and therefore susceptible to attacks on traffic
integrity/control.  To mitigate against this they recommend a secure
link-layer, but does not help if the node itself is compromised.  I guess that
this is expected given that the overall protocol assumes this
environment/use-case?

General comments:

There is concern about no running code, has this changed recently?

Editorial comments:

Not for sure if there is already precedence, but defining each of the fields in
the network action subsections would help with having to hunt for the
associated documents.  These subsections could use some help in describing the
actions in more detail as if wasn't clear what unique purpose that each of
these selectors has (one provides just a reference but no description).