Skip to main content

Last Call Review of draft-ietf-teas-5g-ns-ip-mpls-15
review-ietf-teas-5g-ns-ip-mpls-15-secdir-lc-salowey-2025-01-29-00

Request Review of draft-ietf-teas-5g-ns-ip-mpls
Requested revision No specific revision (document currently at 18)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-01-28
Requested 2025-01-07
Requested by Jim Guichard
Authors Krzysztof Grzegorz Szarkowicz , Richard Roberts , Julian Lucek , Mohamed Boucadair , Luis M. Contreras
I-D last updated 2025-11-05 (Latest revision 2025-04-03)
Completed reviews Rtgdir Early review of -02 by Alvaro Retana (diff)
Tsvart Early review of -02 by Yoshifumi Nishida (diff)
Intdir Early review of -02 by Timothy Winters (diff)
Rtgdir IETF Last Call review of -15 by Mike McBride (diff)
Genart IETF Last Call review of -14 by Lars Eggert (diff)
Opsdir IETF Last Call review of -16 by Tim Wicinski (diff)
Secdir IETF Last Call review of -15 by Joseph A. Salowey (diff)
Secdir Telechat review of -16 by Joseph A. Salowey (diff)
Intdir Telechat review of -16 by Timothy Winters (diff)
Assignment Reviewer Joseph A. Salowey
State Completed
Request IETF Last Call review on draft-ietf-teas-5g-ns-ip-mpls by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/6R8jjAhGsl0Y7o4wB2hWtNXwolA
Reviewed revision 15 (document currently at 18)
Result Ready
Completed 2025-01-29
review-ietf-teas-5g-ns-ip-mpls-15-secdir-lc-salowey-2025-01-29-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.

The summary of the review is ready, but could possibly be improved.

The document does have security considerations that highlight some of the areas
in the architecture where security controls can be applied.  It leaves most of
the details of the these controls to other documents, which seems appropriate.
As someone not intimately familiar with slices I found it little hard to
determine if other should be considered in other sections of the document to
help enforce the desired isolation.  It would be helpful to understand what
security guarantees the isolation is expected to provide and what deployment
parameters and choices affect those guarantees. It could be that the list in
the security considerations section is complete, but it seemed a bit short. 
For example it mentions NSC authentication in security considerations as out of
scope, an this is the only mention of the NSC authentication. As a somewhat
naive reader I'm not sure where this control would be applied and how it
affects the architecture, this may be discussed in other documents but after a
brief investigation this wasn't clear. The authors should consider if the
document should list additional places where security controls can be applied
to reach isolation goals.