Skip to main content

Telechat Review of draft-ietf-mpls-sfc-05
review-ietf-mpls-sfc-05-secdir-telechat-mundy-2019-03-06-00

Request Review of draft-ietf-mpls-sfc
Requested revision No specific revision (document currently at 07)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-03-05
Requested 2019-02-12
Authors Adrian Farrel , Stewart Bryant , John Drake
I-D last updated 2019-03-06
Completed reviews Rtgdir Last Call review of -04 by Mach Chen (diff)
Secdir Last Call review of -04 by Russ Mundy (diff)
Secdir Telechat review of -05 by Russ Mundy (diff)
Assignment Reviewer Russ Mundy
State Completed
Request Telechat review on draft-ietf-mpls-sfc by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has issues
Completed 2019-03-06
review-ietf-mpls-sfc-05-secdir-telechat-mundy-2019-03-06-00
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 <mundy@tislabs.com
<mailto:mundy@tislabs.com>> wrote: > > > >> On Jan 31, 2019, at 5:52 AM, Adrian
Farrel <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>> 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