Hi Russ, Thanks for reviewing. A few responses ... > Summary: > > This document defines defines a methods to achieve Service Function Chaining (SFC) > using Network Service Header (NSH) in Multiprotocol Label Switching (MPLS) networks. No, it absolutely does not. To quote from the Abstract... This document describes how Service Function Chaining can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. The point of this document is exactly that it does not use the NSH. Instead it encodes the fields of the NSH in MPLS headers. This is crucially important because if one wanted to use the NSH in an MPLS network one would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation. > Issues: > > First, the document and in particular the Security Considerations section points to published RFCs > for discussions of the security properties. In particular, RFC7665 and RFC8300 are referenced > however each of these documents left some significant security descriptions & definitions to be > addressed by implementation documents such as this one. Additionally, the SECDIR reviews of > the IDs prior to publication of these RFCs point out several security related issues that, as far as > I could tell, were primarily addressed by saying that future implementation specifications will > address them. Since this ID is such an implementation specification, referring to the earlier RFCs > for the security properties results in essentially no security properties provided in either the > earlier RFCs or this implementation document - security properties need to be identified avoided > via circular references. I think you have a good point here that, although the aspects of security related to SFC are inherited from whatever documents the SFC WG produces (complete with whatever flaws exist in that set of documents that need to be patched by that WG), *this* document needs to talk about the security of the mechanisms that it defines. That means some discussion of the security of the MPLS forwarding plane (with references) and some discussion about what would happen if someone was able to tamper with a packet (noting that if someone can successfully tamper with an MPLS packet in flight then they can do a lot of other bad things as well). > Next, the Security Considerations section identifies that the certain elements of the design must > be a ‘trusted resource’ and that some functions must also be trusted. The term “trusted” in > relationship to computing and software has a wide range of different meanings (as shown by > many years of research in the CS field). In the context of this document, my guess is that it > means that some unidentified (but not defined) entity believes (“trusts”) that the software > will do the “right thing” - to me (from a security perspective) it also means trusting that the > software will not do the wrong thing. All of this is very abstract (both the Security > Considerations text & this critique) which in my view is why the 'trust' section is very > inadequate for an implementation document. If there is an IETF security definition of "trust" that we could look at, that would help. "Do the right thing" is probably not quite what we mean. I think we mean "Not act maliciously so as to wilfully break the network or send traffic to/via the wrong places." But this is all a little like how we "trust" a router. A malign router could drop or redirect packets contrary to the routing information it has received. We typically test for that in the lab, and maybe watch for it in the field, but other procedures (such as checking software images) are generally out of scope for protocol documents. > Additionally, the last paragraph of the Security Considerations section asserts: > > Thus the security vulnerabilities are addressed (or should be > addressed) in all the underlying technologies used by this design, > which itself does not introduce any new security vulnerabilities. > > As far as I could see, the assertion is not supported anywhere in the document > itself or other referenced documents, i.e., what vulnerabilities should the > implementation be concerned with (e.g. passive monitoring, active attacks > on metadata, etc??) that result from this implementation. Since the > document does not provide a clear identification of it's security requirement, > any security services it does (or might) provide nor require from underlying > technologies, the assertion should be clarified, supported by additional > information or removed from the section. I *do* understand where you are coming from on this, but I'm not sure where we go with it. Let's consider for a moment the case of email being carried over an MPLS network. There is a security vulnerability that passive monitoring of MPLS packets would allow inspection of the contents of the email. There are a number of ways to protect against this including encryption at the application layer (i.e. of the email) and encryption at the transport layer, and encryption at the IP layer. There is also the possibility to encrypt the underlying transport (such as MACsec). Now, you are asking about whether this document should discuss the security of any metadata carried in the MPLS encoding of an SFC system (I realise this is just one example of the concerns you are raising). And I would say that it should not. It should observe that metadata is an SFC concept (SFC is the application using MPLS) and encryption of that data is a function of the "SFC layer". So maybe a bolder statement could be added to the document... "The MPLS forwarding plane does not include any security mechanisms. That means that procedures described in this document rely on three basic principles: - The MPLS network is often considered to be a closed network such that insertion, Modification, or inspection of packets by an outside party is not possible. - The underlying transport mechanisms (such as Ethernet) between adjacent MPLS Nodes may offer security mechanisms that can be used to defend packets "on the Wire" - The SFC-capable devices participating in the network are responsible for verifying And protecting packets and their contents. Deployments of any SFC system will need to consider these issues, especially the last point. It is expected that a deployment of the techniques defined in this document would benefit from the more general security mechanisms defined for SFC." Thanks, Adrian
