Subject: [sfc] concerns about progressing draft-ietf-sfc-nsh

From: Alia Atlas <[email-masked]>
Date: Mon, 11 Sep 2017 11:06:42 -0400

I am still quite concerned about the security implications for NSH.
I do think that the security considerations section is much improved - but
the issues aren't just describing better what could be done.

Here are my concerns:
    a) There is no integrity protection for the NSH. It is, of course,
possible to
         do transport-layer security for some transports - but that doesn't
prevent
         a single compromised SF, SFF, etc. from modifying the NSH. This is
primarily
         a concern for the SFP & SI fields where such a modification could
move the
         packet to a different chain or no chain at all. Without
transport-layer security,
         any MITM attack could easily do so.  While the intent is for this
to be in a single
         administrative domain, that includes multi-tenancy data-centers.
That includes
         cables that could be compromised.

         Consider the case where a VM comes up and claims an address that is
         expected to be an SFF. Traffic could be directed to it. I don't
see a way of
         solving this problem that doesn't consider control plane aspects
or that
         doesn't have more than 1 transport-hop security. Fundamentally, if
a MITM
         can strip off the NSH without being detected, I am concerned.
         It feels like the single administrative domain is being used to
assume that there
         is no possibility of MITM.

         This all may be similar to the case where a VLAN is used with
static wiring to
         indicate the next-hop and the VLAN could be changed or stripped
off, but I am
         concerned that the attack surface is greater.

         I hope that this concern can be resolved by having a clear threat
analysis in the
         Security Considerations - with an indication of which threats are
handled by
         transport/overlay layer security. I know this is a hard problem;
solving it is out
         of my area of expertise - but documenting the threats is the
minimum.

    b) The meta-data provides a method for sending along any information with
the packet.
         This allows any MITM to eavesdrop on that information - as well as
modify it. For
         cases where the meta-data represents subscriber information, this
presents not
         merely a privacy threat but also a financial threat - where a
different subscriber could
         be substituted.

         There is no mechanism currently adopted or even not expired for
         encrypting the meta-data. There is nothing that would require
meta-data to be so
         encrypted when allocated by other organizations.

         I could see an approach where IETF standardized & allocated
meta-data could be
         plain text, assuming that the IETF process would be sufficiently
sensitive to privacy
         concerns. Integrity protection is still a concern (unless the
assumption really is no
         MITM). I could see an approach where meta-data from other ranges
MUST be
         encrypted. Perhaps there are middle grounds.

Let me discuss briefly about MITM attacks. In a multi-tenancy environment,
it is quite
possible for there to be malicious VMs that try to attack. Even in a single
administrative
domain, a VM image could be infected with malware or there can be malicious
(ex-)employees. Inside attacks at corporations are a persistent concern.

I have had and expected serious concerns about security and privacy aspects
for years. I strongly steered towards a security DT to serious probe into a
threat analysis & solutions, because I & Stephen Farrel were trying to get
security issues resolved before the NSH draft and other work progressed.
The DT tried but did not get traction in the WG. At the interim meeting in
Jan 2017, there was agreement to handle the security issues as part of each
document. That is what this means!

I am also still concerned about the lack of OAM work around NSH. It was 2
years ago when the compromise of at least defining the minimum behavior for
the OAM bit was put in. There has been no meaningful progress on OAM since
then - and we have a desire to push strongly forward with NSH despite that.
For every encapsulation, we say that we must build in good troubleshooting
and OAM from the beginning - and, yet again, the WG has failed to do so. It
has failed to convincingly engage in this area at all. The lack of thought
as to whether the OAM flag is pitched by re-classification is just another
indication that the WG is not seriously thinking about or trying to solve
OAM. I know that the OAM framework just had a new version published; a
framework is nice but it is NOT a technical solution. The WG doesn't even
have connectivity or trace functionality defined for SFC - which seems the
bare minimum.  (I do understand that the charter suggests that more
understanding is needed - but that was written almost 4 years ago!).  I
hope that there are no more lurking issues around OAM in the minimum that
is defined for interoperability in NSH. When I find an issue this late
(after many many readings of this draft), it does make me concerned about
what has still been missed. I would greatly appreciate others reviewing
this document from the OAM perspective - thinking about how a traceroute &
connectivity functionality would work through reclassifiers & other more
complex scenarios.

I am concerned by the transport directorate reviews that note it is
challenging to consider transport considerations without any companion
drafts on what transport/overlays are expected to be used. I don't see that
being solved as part of the NSH draft - but I really wish that the WG had
made work on the needed companion drafts. I am not sure how
interoperability could work without some agreement on transport/overlays.

draft-ietf-sfc-nsh-20 has improved greatly in terms of readability and in
terms of suggesting some of what might be possible while strongly trying to
push all concerns into someone else's problem. The drafts to support that
push aren't there yet.

I do not consider that these issues are the responsibility of the
draft-ietf-sfc-nsh editors and authors, who have been doing an excellent
job recently of improving the readability and documenting what is there.
These are WG issues.

I have asked Kathleen & Benoit to review draft-ietf-sfc-nsh-20 and provide
their feedback.

I am still considering what to do.

Regards,
Alia