Re: [Teas] Intdir early review of draft-ietf-teas-5g-ns-ip-mpls-02

[Timothy Winters <[e-mail]>]

Hi Med,

Thanks for the speedy response, it resolved all my questions.

~Tim

On Mon, Feb 26, 2024 at 3:28 AM <[e-mail]> wrote:

> Hi Timothy,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Timothy Winters via Datatracker <[e-mail]>
> > Envoyé : vendredi 23 février 2024 20:25
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]
> > Objet : Intdir early review of draft-ietf-teas-5g-ns-ip-mpls-02
> >
> > Reviewer: Timothy Winters
> > Review result: Almost Ready
> >
> > I am an assigned INT directorate reviewer for draft-ietf-teas-5g-ns-
> > ip-mpls.
> > These comments were written primarily for the benefit of the Internet
> > Area Directors. Document editors and shepherd(s) should treat these
> > comments just like they would treat comments from any other IETF
> > contributors and resolve them along with any other Last Call comments
> > that have been received. For more details on the INT Directorate,..
> >
> > Summary: I don't think there are any Internet issues in this document.
> > I think it's in good shape for publishing as Informational document. I
> > found the Appendix C was helpful, as I'm not an expert in 5G
> > deployments.
> >
> > This document recommends encoding of the IP addressing in section 4.2
> > using most significant 96-bits to simplify mapping tables.
>
> [Med] Please note that the document does not recommend it per se. It is
> provided as an example to simplify the mapping table:
>
>    The mapping table can be simplified if, for example, IPv6 addressing is
> used to
>    address NFs.
>
>  There is
> > nothing wrong with this, but it should be noted for privacy and other
> > considerations if/when deploying over the public internet space.
>
> [Med] Thanks. Tried to generalize the concern by adding this new text:
>
> NEW:
>    In order to avoid the need for a mapping table to associate source/
>    destination IP addresses and slices' specific S-NSSAIs, Section 4.2
>    describes an approach where some or all S-NSSAI bits are embedded in
>    an IPv6 address using an algorithm approach.  An attacker from within
>    the transport network who has access to the mapping configuration may
>    infer the slices to which belong a packet.  It may also alter these
>    bits which may lead to steering the packet via a distinct network
>    slice, and thus lead to service disruption.  Note that such an on-
>    path attacker may make more damage (e.g., randomly drop packets).
>
> > Section 5.2.1 allows for IPv6 encapsulation using SR6, so there is no
> > issue with MTU that any encapsulation technique would encounter.  It
> > uses DSCP for QoS, so there no use of flow labels or additional
> > headers.
> >
> > Nits:
> > Figure 32 table has some formatting errors.
> >
>
> [Med] Thanks for reporting this. Will check how to fix it as the issue
> seems to be only for html while the txt version is OK.
>
>
>
> ____________________________________________________________________________________________________________
> 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.
>
>