Telechat Review of draft-ietf-sfc-nsh-25

Request Review of draft-ietf-sfc-nsh
Requested rev. no specific revision (document currently at 28)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-09-26
Requested 2017-09-22
Authors Paul Quinn, Uri Elzur, Carlos Pignataro
Draft last updated 2017-09-28
Completed reviews Rtgdir Early review of -10 by Acee Lindem (diff)
Secdir Last Call review of -18 by Christian Huitema (diff)
Opsdir Last Call review of -18 by Jürgen Schönwälder (diff)
Rtgdir Last Call review of -18 by Acee Lindem (diff)
Opsdir Last Call review of -19 by Jürgen Schönwälder (diff)
Tsvart Last Call review of -19 by Wesley Eddy (diff)
Genart Last Call review of -19 by Dan Romascanu (diff)
Secdir Telechat review of -25 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema 
State Completed
Review review-ietf-sfc-nsh-25-secdir-telechat-huitema-2017-09-28
Reviewed rev. 25 (document currently at 28)
Review result Serious Issues
Review completed: 2017-09-28


I have already reviewed previous iterations of this draft (18) and sent comments on the mailing lists about revisions 20 to 24. The draft has significantly improved through the revisions, but I still have concerns.

First, it should be clear that standardizing addition of metadata to packet headers is, from a privacy standpoint, playing with fire. I understand that many ISP believe that they need to accumulate and use metadata in order to compete with the large scale tracking performed by some web companies. This existing competition may well be driving a race to the privacy bottom. Regardless, the minimum these ISP can do is ensure that the privacy sensitive metadata that they collect is well protected. Collecting metadata is bad enough; letting hackers access it would be disastrous, as shown in the Equifax breach. I would like to see a stronger recognition in the security consideration that this is indeed playing with fire.

I am also concerned that when writing the security considerations the authors may be playing with words. Frankly, I do not believe that the data will be magically protected because they are only transported in a single administrative domain. As Randy Bush pointed out in an email comment, some of the service functions are already provided "in the cloud" by third party contractors to the ISP. This means that in practice, the data will probably not be confined to a single provider domain. In the email, I listed three threats:

* Whether ISP believe it or not, their links will be snooped by third parties. We have to assume that adversaries will have access to some of the transmission equipment, even inside the perimeter.

* We also have to assume that persistent attackers will be able to compromise some of the devices hosting some of the functions. 

* And we have to assume that some third party providers will re-purpose the metadata that they obtain through various contracts.

What worries me is not so much the inadequacies of the defenses proposed in the security section as the absence of emphasis on the need to actually deploy these defenses. Everything seems to be optional, left to the good will of the ISP. Experience shows that in these conditions deployments use the most convenient setup, clear text transmission with little defense in depth. The security section ends up being so much empty talk designed to placate security reviewers, playing with words for security without recognizing that standardizing metadata collection is playing with fire.