Maybe to expand on Joel's point about "metadata".
There has (of course) been a lot of discussion of metadata in the context of end-user privacy. I think that has left many people with a specific understanding of "metadata", but as Joel says this is not the intention in this case.
That said, the description of metadata in this document and in RFC 7665 is perhaps a little vague. 7665 has...
Metadata: Provides the ability to exchange context information
between classifiers and SFs, and among SFs.
...from which we might deduce that metadata does two things:
1. Provide a channel for communication between SFC entities for them to synchronize state/actions related to traffic that follows a specific service function chain.
2. Carry information related to a specific packet that has been extracted or derived from that packet (for example, a hash) by an SFC entity that save subsequent SFC entities from having to derive the same information (thus allowing the subsequent SFC entities to be dumber or less CPU-rich).
7665 also says...
One use of metadata is to provide and share the result of
classification (that occurs within the SFC-enabled domain, or
external to it) along an SFP. For example, an external
repository might provide user/subscriber information to a service
chain classifier. This classifier could in turn impose that
information in the SFC encapsulation for delivery to the
requisite SFs. The SFs could in turn utilize the user/subscriber
information for local policy decisions. Metadata can also share
SF output along the SFP.
...which may help explaining the intention.
Personally, I think that tightening the description and scope of metadata might be a way to help address Christian's concerns. At the moment the scope seems to be left wilfully open to allow freedom of choice for future use cases: that seems to me to be dangerously open-ended.
Cheers,
Adrian
> -----Original Message-----
> From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Joel M. Halpern
> Sent: 28 September 2017 20:54
> To: Christian Huitema; secdir@xxxxxxxx
> Cc: ietf@xxxxxxxx; sfc@xxxxxxxx; draft-ietf-sfc-nsh.all@xxxxxxxx
> Subject: Re: Secdir telechat review of draft-ietf-sfc-nsh-25 - motivation
>
> We really need to separate issues here.
>
> The first part of your note talks about the need for metadata. You
> assert that this is related to a need to compete with large scale
> tracking. While I can not prohibit that use, that is NOT the problem
> that drives this work.
> Rather, the whole point is to support separating the currently
> monolithic service platofrms into component services that can be
> combined both to deliver existing services, and to deliver new service
> combinations. To do that, the existing internal methods for passing
> data within a service delivery monolith have to be replaced with an
> external, interoperable, method for doing this.
> My employer would be very happy if the operators would give up on this
> and go back to buying our nice, high reliability, high price, intgrated
> service platforms. But that is not what the operators are asking us
> to provide.
>
> Yours,
> Joel
>
> On 9/28/17 3:42 PM, Christian Huitema wrote:
> > Reviewer: Christian Huitema
> > Review result: Serious Issues
> >
> > 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.
> >
> >