Last Call Review of draft-ietf-sfc-nsh-18
review-ietf-sfc-nsh-18-secdir-lc-huitema-2017-08-11-00

• Status
• Email expansions
• History

• Versions
• 00

Requesting in parallel with doing my AD review.  Earlier reviews appreciated!

Review
review-ietf-sfc-nsh-18-secdir-lc-huitema-2017-08-11

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.

The summary of this review is a puzzled reviewer. Why was I asked to 
review this? Why is the IETF even working on such specifications? What
does this have to do with the Internet? And why such disregard
for privacy and security? In any case, this document has significant
issues. It does not explaining where exactly the proposed Network
Service Header would be inserted (MPLS or IPv6?). The security
provisions boil down to lip-service mentions of IPSEC, and that's way
insufficient given the nature of the protocol.

Sometimes you read a document and it gives you a glimpse of an alternate
universe in which the Internet has been replaced by a mad pile-up of
middle boxes. Of course, they will not be called that. Instead, we will
speak of "service functions" providing such essential features as NAT
and deep packet inspection. I suppose that censorship and surveillance
are not desirable key words in marketing brochures, and that metadata
collection and the insertion of adverts are better described in yet to
be published extensions.

As far as I can tell, the so called "Service Function Chaining
Architecture" tries to standardize this pile-up of middleboxes, so that
service providers can procure them from multiple vendors. The draft that
I am reviewing, draft-ietf-sfc-nsh-18, defines a clear-text "network
service header" (NSH) that would inserted between the "transport" used
in the domain and the IPv4 or IPv6 packet itself. Boxes could look at
this header, add metadata to it, and forward it to other boxes along a
"service path". I mentioned IPv4 or IPv6, but there are also provisions
for passing pure NSH information, probably for maintaining the "service
path", or passing Ethernet, MPLS or experimental frames, because why not.

The specification itself is appropriately baroque, with the header
composed of three components and multiple options, but the basic idea is
to allow different boxes to see the packet so they can read, update and
process the metadata. As far as I can tell, there are no serious attempt
to provide any kind of security or privacy protection except maybe some
basic ingress filtering, which means that the metadata can be observed
by any entity able to tap the path, or can be spoofed by any system
inserted on the path, such as for example a virus infected box. The only
security reference is a short note that deployments "could use IPSEC",
through a token reference to RFC 6071.

When first reading the document, I was under the impression that the
"transport" used in the domain would be some kind of close layer 2
system, MPLS or maybe Ethernet. That would give some assurance that the
collection of middle boxes would be part of a somewhat controlled
domain. It was only the reference to IPSEC that enlightened me. If IPSEC
is plausible, it probably means that the packet would be composed of an
IP header, the SFH, and the original IP payload. So the proposed usage
implies carrying metadata like subscriber information and identification
of content in clear text  over long distance paths. What could possibly
go wrong? And if that was not enough, imagine what an adversary could
achieve by spoofing the service packets.

Of course, the same threats would still apply if the protocol was
strictly carried over layer 2, as several adversaries are quite capable
of snooping and spoofing layer 2 traffic.

Coming at the end of this review, I hesitate between two options. One
would be to just express my disgust, wash my hands, and hope that the
effort will fail under its own weight, maybe after a couple of
catastrophic security failures. The other option is to provide some
advice on how to solve the most blatant issues. In a spirit of
cooperation, I choose the latter, and here is the two steps advice:

The first step to better security and privacy there would be to present
the practical deployment conditions. I could only make guesses, and
that's silly. There should be some kind of diagram explaining how the
SFH is inserted in packets, and where it sits between Ethernet, MPLS and
IP.

The next step is to develop a protection model. Given that the goal of
the architecture is to decorate the packets with sensitive metadata,
there need to be some thinking about who should be able to see it. How
would path encryption like IPSEC be deployed? Should all elements on
path really be able to access all metadata, or should some of it be
further protected?

Please fix that before the document is published.


-- 
Christian Huitema