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