[secdir] secdir last call review of draft-ietf-mpls-sfc-05 [was: Re: secdir last call review of draft-ietf-mpls-sfc-04]

[Russ Mundy <[e-mail]>]

Reviewer: Russ Mundy
Review result: Has Issues (improved over 04 version)

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.

Document: draft-ietf-mpls-sfc-05
Reviewer: Russ Mundy
Review Date: 2019-03-05
IETF LC End Date: 2019-03-05


Thanks for the changes incorporated into the 05 version of the document, they have made portions of the document, including the Security Considerations clearer and easier to understand.

Issue: Although the Security Considerations is certainly improved, stating that “the classifier is a trusted resource” yet not having the spec say what it is “trusted” to do (or not do) remains a an issue. It does seem that more information is needed to know what “trust” expectations are and how can one determine if they have been met.

Issue: Since the spec is silent on whether or not it’s use is appropriate for an InterCarrier Interconnect (ICI) environment (as defined in RFC5920), the spec could well be used in a multi carrier environment.  Without further specification of security characteristics (such as “trust”) it would seem appropriate to say that this specification SHOULD NOT be used in an ICI environment unless additional security vulnerability definitions as well as additional specifications of security requirements are developed.

Russ

> On Feb 1, 2019, at 3:22 PM, Russ Mundy <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 
>> On Jan 31, 2019, at 5:52 AM, Adrian Farrel <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Russ,
> 
> Hi Adrian,
> 
>> 
>> Thanks for reviewing.
> 
> You’re welcome.
> 
>> 
>> 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.
> 
> Okay, thanks for the clarification, I obviously misread what is meant by 'a logical representation of the NSH'.
> 
>> 
>>> 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).
> 
> I agree, it's important for the WG to think about security aspects of functions for each of the documents it produces. It's also important to be able to describe how a documents' security aspects relate to the security aspects of related other technologies, e.g., RFC5920 describes an overall security framework - it might contain useful information (even though it's status is Informational).  
> 
>> 
>>> 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.
> 
> Are you referring to RFC4949 or another definition?  4949 might provide a useful definition, it's worth checking to see if there’s something useful there or elsewhere.
> 
>> 
>> "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.”
> 
> This certainly sounds reasonable but I'm not sure where the concept is described - I wasn't able to find it in RFC5920, RFC7665, or RFC8300.
> 
>> 
>> 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.
> 
> I agree that this is a difficult concept to describe.  Even though protocol documents don't describe testing requirements and such, section 14 (Implementation Notes) does lead one to think about what should be done to implement the specification.  Having some security related implementation notes there would be helpful and appears to be consistent with information already in the section.
> 
> WRT the Security Considerations section, it would be useful to review sections 5 - 12 of the document to identify if there are particular structures or functions that must work correctly or the SFC design will "fail" (for some value of "fail"). If there are specific functions or structures that are crucial to the design, it would be appropriate to identify them in the Security Considerations section.   
> 
>> 
>>> 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”.
> 
> Thanks for these examples, they do clarify how the pieces fit together (terminology is always hard) - prior to the examples, it was not clear that the SFC was roughly an application using MPLS.  I think that this also means that every SFC system deployment must determine their own security requirements and how they will be met _within_ (or by) the particular SFC system, i.e., neither MPLS nor the Service Function Chaining provide confidentiality, integrity or other security services often required by applications.
> 
>> 
>> So maybe a bolder statement could be added to the document…
> 
> I think text of this nature is much better than the current paragraph. If my i.e. text above is correct, it should also be part of the introductory portion (e.g., neither MPLS or SFC provide security services application functions require).
> 
>> 
>> "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.
> 
> Since RFC5920 includes InterCarrier Interconnect (ICI), that seems difficult to assert that MPLS is a "closed network".  Perhaps I'm misinterpreting 5920 but having different/multiple carriers involved with MPLS forwarding does not seem to be a "closed network" or perhaps the functions defined in this document should not be used with MPLS ICI.  I do agree with the sentiment of the statement but think it needs a bit more clarification.
>  
>> 
>> - 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.
> 
> Would it be clearer if it read:
> - The SFC-capable devices participating in an SFC system are responsible for verifying and protecting packets and their contents as well as providing other security capabilities that might be required in the particular system.
> 
>> 
>> 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
> 
> Thank you for the prompt response, clarifications and explanations..
> 
> Russ