Thanks SM. >>The text should make clear that the security properties are exactly the >>security properties of SFC as described in the SFC architecture together >>with the security properties of the MPLS data plane. This is perhaps not >>clear enough in the document, and my discussion with Russ left me with a >>plan to include some discussion: >>- of the security of the MPLS forwarding plane (with references) >>- about what would happen if someone was able to tamper with a packet >>- of the fact that if someone can successfully tamper with an MPLS packet >> in flight then they can do a lot of other bad things as well > > The "classifier" caught my attention because of the way it is > described in Section 15. I assume that you already covered that in > the discussion about "control/management plane". I'll say okay to > the above to avoid getting entangled into the SecDir thread. OK. Yes, the Classifier is configured through the management or control plane, so it is worth me highlighting the whole thing. >>In your other email you suggested removing the last paragraph. We could >>certainly do that. Are you objecting to it because it states the obvious >>(which can be frustrating, but is hardly harmful), or because it says >>something that is fundamentally wrong (in which case I don't see what it >>is)? > > I didn't read the text as stating the obvious; I may be reading it > incorrectly. I would not argue that the text is harmful as that > would be an exaggeration. Good, I must have told you a million times not to exaggerate 😊 > What if a security vulnerability is discovered in the design in > future? I read the text as meaning that it would be up to the > underlying technologies to address that. That does not make > sense to me. The text could also be read as meaning that an > (intended) proposed standard will not have any unknown > defects. The draft is not at that maturity level yet. Right, I get it. Wordsmithing is needed. Thanks, Adrian
