Skip to main content

Last Call Review of draft-ietf-mpls-sfl-framework-08

Request Review of draft-ietf-mpls-sfl-framework
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-07-06
Requested 2020-06-22
Authors Stewart Bryant , Mach Chen , George Swallow , Siva Sivabalan , Greg Mirsky
Draft last updated 2020-07-02
Completed reviews Rtgdir Last Call review of -06 by Michael Richardson (diff)
Tsvart Last Call review of -08 by Dr. Bernard D. Aboba (diff)
Secdir Last Call review of -08 by Tero Kivinen (diff)
Genart Last Call review of -08 by Pete Resnick (diff)
Tsvart Last Call review of -10 by Dr. Bernard D. Aboba (diff)
Assignment Reviewer Tero Kivinen
State Completed
Review review-ietf-mpls-sfl-framework-08-secdir-lc-kivinen-2020-07-02
Posted at
Reviewed revision 08 (document currently at 11)
Result Has Issues
Completed 2020-07-02
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.

This document describes a way to make synonyms for MPLS flows so those
flows can be processed differently. It does include privacy considerations
which says that depending on how the synonyms are used there might
be privacy issues. 

It does claim in the security considerations section that there is no new
security issues associated with the MPLS dataplane. I think that is not true.
If there is any kind of different processing depending which synonym
is used that can be used to bypass that processing by using the another
synonym instead of the intended one. For example if attacker knows 
that specific synonym causes deep packet inspection (one of the examples
given), and he might want to use the synonym which bypasses this 
inspection, in case he is sending things he does not want to be 
inspected. This could be some kind of malicious code somehow
loaded to the sending device or something.

On the other hand my understanding that trust model of MPLS
is mostly we blindly trust everything other end says, so someone
able to use different synonyms are most likely also able to do 
other even worse things, but I think there are new things caused
by this addition than what is already present in the MPLS now.