[mpls] Re: [iesg] Éric Vyncke's Discuss on draft-ietf-mpls-mna-nrp-selector-04: (with DISCUSS and COMMENT)

[Tony Li <[e-mail]>]

Hello éric,

> The INT-DIR review was the basis of one of my DISCUSS point, may I suggest a reply to this review ? I.e., writing that -06 has addressed the issue.


I have replied.


> > ### Deployment (Section 3)
> >
> > Please be clear whether all devices must have this feature enabled (e.g., if
> > not the case, then traffic is still flowing but without isolation/QoS/...).
> 
> 
> This comment should be directed to the TEAS NRP architecture.  MPLS will happily transport the NRPS over nodes that do not support it, if requested.  This is the whole point of the U bit in the ISD LSE Formats.
> 
> EV> up to you whether you think that the last 2 sentences above should appear in section 3


draaft-ietf-mpls-mna-hdr, Section 5.4 is the single source of truth for unknown network action handling.


> > ### Section 5
> >
> > Please add some privacy considerations as the NRP itself may leak some
> > information about the packet content (even if transport/application crypto is
> > used). It is also unclear whether the NRP values are opaque.
> 
> 
> The forwarding plane is insecure. There is no privacy. The NRPS is opaque to MPLS in that it’s just a value, without any semantics at the MPLS level.
> 
> EV> thanks, strongly suggest adding the last sentence to the section and adding "therefore no information about the data is leaked".


I disagree. Since there is no crypto of any form, all information about the value of the NRPS is leaked.  If an attacker wants to know that the packet is using NRPS 643, they will be able to ascertain that from any packet dump.

MPLS is insecure. It operates in a ‘limited domain’. This is not news.

Regards,
Tony