Hi Joseph,
Thank you for the review and feedback.
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Joseph Salowey via Datatracker <noreply@xxxxxxxx>
> Envoyé : mercredi 29 janvier 2025 21:04
> À : secdir@xxxxxxxx
> Cc : draft-ietf-teas-5g-ns-ip-mpls.all@xxxxxxxx; last-
> call@xxxxxxxx; teas@xxxxxxxx
> Objet : Secdir last call review of draft-ietf-teas-5g-ns-ip-mpls-
> 15
>
>
> Reviewer: Joseph Salowey
> Review result: Ready
>
> 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.
[Med] Thanks.
> 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.
[Med] Isolation is a special one and it is not even a service objective, but an expectation (SLE). What is expected from a service is what is discussed in 9543, that I'm copying/pasting here for convenience:
==
Isolation: As described in Section 8, a customer may request that
its traffic within its IETF Network Slice Service is isolated from
the effects of other network services supported by the same
provider. That is, if another service exceeds capacity or has a
burst of traffic, the customer's IETF Network Slice Service should
remain unaffected, and there should be no noticeable change to the
quality of traffic delivered.
In general, a customer cannot tell whether a service provider is
meeting this SLE. They cannot tell whether the variation of an
SLI is because of changes in the underlay network or because of
interference from other services carried by the network. If the
service varies within the allowed bounds of the SLOs, there may be
no noticeable indication that this SLE has been violated.
==
The discussion under "Specific isolation criteria" in the sec cons of draft-ietf-teas-5g-ns-ip-mpls have this expectation as background.
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.
[Med] Fair enough. Updated the text to describe the interfaces we are referring to and the various security properties of the protocols used in that interface.
The authors should
> consider if the document should list additional places where
> security controls can be applied to reach isolation goals.
>
[Med] FWIW, a diff to track changes made so far can be seen here: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/5g-slice-realization/draft-ietf-teas-5g-ns-ip-mpls.txt&url_2=https://boucadair.github.io/5g-slice-realization/Joseph-Salowey-secdir-review/draft-ietf-teas-5g-ns-ip-mpls.txt
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
