Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

[<[e-mail]>]

Dear Narseo, 

An example to illustrate the need to inject a header in a mobile network (other than those similar to HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID, HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,HTTP_X_NX_CLID, HTTP_RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, HTTP_X_NETWORK_INFO, etc. ) is discussed in: https://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-09#section-10.2. 

Privacy related considerations of this typical example are elaborated here: https://tools.ietf.org/html/rfc6967#section-3.

Cheers,
Med

-----Message d'origine-----
De : sfc [mailto:[e-mail]] De la part de Narseo Vallina Rodriguez
Envoyé : mardi 10 février 2015 08:34
À : Ron Parker
Cc : [e-mail]
Objet : Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

Hi Ron

Thanks a lot for your explanation. I get better the point that you
were trying to make so I understand your position and I'm starting to
get a better picture of the whole draft.

I would appreciate other's opinions about why such headers may be
needed, in particular in the mobile scenario, and how the associated
privacy issues that today exist will be addressed.

Many thanks again



On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker
<[e-mail]> wrote:
> Narseo,
>
> The point I was trying to make is that the use of the SFC encapsulation metadata within the carrier's administrative domain, instead of HTTP header enrichment, will address these security considerations.   The current SFC architecture states that it is supported within a single administrative domain with inter-domain SFC for further study.   Stated another way, end-to-end SFC is not supported.
>
>     Ron
>
>
> ________________________________________
> From: Narseo Vallina Rodriguez [[e-mail]]
> Sent: Monday, February 09, 2015 7:26 PM
> To: Ron Parker
> Cc: [e-mail]
> Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection
>
> Hi Ron
>
> Thanks for the explanation. I still have some concerns about the
> header enrichment that may be worth discussing further. Let me respond
> inline.
>
>> The HTTP X-headers related to identification are typically inserted by the Subscriber Management System for the benefit of transparent midboxes such as video optimizers, IDS/IPS, Firewall, etc.   The fact that it goes all the way to the origin server is sometimes incidental.
>>
>
> That's exactly my main concern. The first example for SFC use cases in
> mobile networks is functions to protect the carrier network and the
> privacy of its users. This is contradictory with many other parts of
> the draft as in the case that we're discussing unless there are other
> reasons behind such as monetizing user's metadata.
>
> If not, why is this information leaving the network and reaching the
> origin server without any control given how sensitive it is?
>
> As you frame it, it sounds like End-to-End SFC is not the goal in this
> case. If so, aren't better ways of doing performance enhancement as in
> the video streaming case without leaking personal data as using
> "differential" values rather than unique absolute ones on a per-user
> basis?
>
> From my perspective,  adding these headers does not add much value to
> the whole chain, but still present a serious privacy concern for most
> users so that's why I would like to know about a real use case in
> which the uncontrolled leak beyond the scope of the operator (and the
> addition of the headers) is completely justify.
>
> Just for reference, we have identified the following headers added by
> mobile proxies. We have records going back to November 2013
>
> The 3 headers listed below are perma-cookies (the EFF showed their
> concerns with such headers), which do not map to any unique identifier
> such as IMEI/IMSI but they still identify the user uniquely. We have
> observed them in a bunch of operators all over the world.
>
> x-acr
> X-UIDH
> X-VF-ACR
>
> The headers below leak directly raw values without any anonymization
> as you proposed, thus becoming serious privacy leaks. In fact, these
> are some of the values that are listed on the draft as possible values
> to be included, which is worrying and also contradicting the privacy
> preserving use case.
>
> LBS-EventTime: Header probably related to location-based services.
> LBS-ZoneID: Idem
> MSISDN: Subscriber phone number.
> x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely.
> x-up-nai: Email-like name that identifies the user and operator.
> x-up-calling-line-id: Subscriber phone number.
> x-up-vodacomgw-subid: Subscriber phone number.
>
>> But, this technique is limited to only clear-text HTTP.   As end-to-end HTTPS increases, the portion of flows that can be enriched in this manner decreases.
>>
>
> Still, a large fraction of users' traffic is still HTTP, as in the
> case of ad-traffic that actually involve more than one party. Just
> check a normal online newspaper or magazine. As a result, this
> information is being collected by an uncontrolled number of online
> services. Some of them, may not be trustworthy.
>
>> SFC has the potential to solve the problem of providing policy hooks to midboxes in a more universal and elegant fashion through the use of the metadata capabilities inherent in the SFC encapsulation header.
>>
>
> So is the point to enable E2E SFC? Once more, couldn't this be done
> without enabling users' tracking and leaking their personal data?
>
> How will middleboxes take advantage of them if the x-headers are not
> standardised and are highly customized by operators and proxy
> manufacturers?
>

_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc