Ben, Thanks for responding to this and so for bringing it to my attention (somehow it was missing from my inbox). SM, I had some exchanges (on this list) with Russ Mundy who did a SecDir review during WG last call. I believe that this will lead to some edits to the Security Considerations section. But I don't think that this document has holes to plug. There are, of course, no control plane implications in this document, so that doesn't need attention. That leaves us with the architecture/function of SFC itself, and the underlying transport. 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 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)? Thanks, Adrian -----Original Message----- From: Benjamin Kaduk <kaduk@xxxxxxx> Sent: 11 February 2019 16:29 To: S Moonesamy <sm+ietf@xxxxxxxxxxxx> Cc: Adrian Farrel <adrian@xxxxxxxxxxxx>; ietf@xxxxxxxx Subject: Re: Last Call: <draft-ietf-mpls-sfc-04.txt> (An MPLS-Based Forwarding Plane for Service Function Chaining) to Proposed Standard Hi SM, On Sat, Feb 09, 2019 at 05:41:55AM -0800, S Moonesamy wrote: > Hi Adrian, > At 11:52 AM 17-01-2019, The IESG wrote: > >The IESG has received a request from the Multiprotocol Label Switching WG > >(mpls) to consider the following document: - 'An MPLS-Based Forwarding Plane > >for Service Function Chaining' > > <draft-ietf-mpls-sfc-04.txt> as Proposed Standard > > > >The IESG plans to make a decision in the next few weeks, and solicits final > >comments on this action. Please send substantive comments to the > >ietf@xxxxxxxx mailing lists by 2019-01-31. Exceptionally, comments may be > > I took a quick look at the draft. Section 15 states that the draft > does not introduce any security vulnerabilities and leaves it to the > underlying technologies using the design to address the security > vulnerabilities which they might introduce. That is like the IETF > stating that there are no known or unknown defects in the design > except for what has been stated in the first three paragraphs of Section 15. >From a purely rhetorical perspective, you are just making some statements about the document that seem to be statements of fact. If you are asking for the document to change, it would probably be useful to actually say what you would change. -Ben
