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

[[e-mail]]

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.