Re: [sfc] HTTP Header injection

[🔓Dan Wing <[e-mail]>]

On 10-Feb-2015 05:06 PM, Narseo Vallina Rodriguez <[e-mail]> wrote:
> 
> Dear Walter
> 
> Thanks a lot for your response. It's actually a pleasure to read the
> draft and I think it has some very interesting points. I'd also love
> to read Martin Stiemerling's thoughts if they are available somewhere.
> 
> A few weeks ago, we wrote a short blog post about our view on HTTP
> header injection at a global scale.
> 
> http://netalyzr.icsi.berkeley.edu/blog/
> 
> We're working to extend it as paper that will be submitted this month.
> Of course, any feedback and comments, specially different views that
> may not be under our radar, will be very welcome!
> 
> In your response, you mention real use-cases. As you can see in the
> blog post, we have found a diverse array of headers that are used for
> a wide range of actions. Some of them could be used to illustrate the
> benefits of header enrichment or to describe some use cases rather
> than including use-cases involving very sensitive information such as
> the IMEI/IMSI or even Perma-cookies. For instance the headers
> reporting the transport-layer protocol may be a nice use case.
> 
> I personally think that the draft should clearly say that this
> information MUST NOT leave the actual domain of the operator in order
> to prevent user tracking by 3rd party services. It could be written in
> the same way that the HTTP standard says that any proxy MUST advertise
> its presence using the VIA field (BTW, only a small fraction of the
> mobile proxies we've seen deployed in real networks does actually
> include the standard VIA field). One more thought is that given that
> the headers are in plain HTTP text, what does prevent a client from
> impersonating someone else, specially for charging purposes, by adding
> their own headers?
> 
> So to sum up, a nice definition of what kind of information is privacy
> sensitive could be useful, specially in the mobile use case. That
> would be better than leaving the decision to the operator's or proxy
> vendor judgement. Could that be possible? Another point to make is
> that enriching such headers is OK as long as they do not leave the
> operator's domain as Ron suggested.
> 
> The US senate as well as the FCC are also showed their concerns on the
> use of perma cookies and other header enrichment techniques:
> 
> https://www.eff.org/deeplinks/2015/02/under-senate-pressure-verizon-improves-its-supercookie-opt-out

The problem is not permacookies or header 'enrichment', which is merely today's technology.  Rather, the problem is identifying that a flow belongs to a user.  That identification could be done with other technological means (including something akin to a modern IDENT, see the historic IDENT at RFC1413). It could be done with IPv6 addresses (if the IPv6 prefix is assigned to a user, as is typical).  It could be done with IPv4 addresses (if IPv4 address is assigned to a user's home, as is typical with wired residential addresses).  It could be done with TCP or IP options (draft-wing-nat-reveal-option, draft-williams-exp-tcp-host-id-opt).

Stepping back to analyze how and why such flow identification are desired by network operators, and how to approach a solution in our standards, would be useful to avoid the privacy concerns.  Including the privacy harm caused by IPv6 (and helped by IPv4 address sharing such as CGNs), which many IETFers are reluctant to acknowledge.

-d



> 
> 
> On Tue, Feb 10, 2015 at 4:06 AM, Haeffner, Walter, Vodafone DE
> <[e-mail]> wrote:
>> Dear Narseo, dear Ron,
>> 
>> Narseo, thanks for reading and commenting the draft. And thanks to Ron for the explanations.
>> 
>> Indeed, some days ago one of the co-authors (Martin Stiemerling) mentioned that HTTP Header Enrichment may come under attack. I will include a statement w.r.t. your security concerns. But as pointed out by Ron, the security issues are even more general. And we probably could have the same discussion with SIP P-Headers; or with any subscriber-related data exchanged between different carriers and ISPs.
>> 
>> Our intension for the mobility use case draft was to list a short number of representative SFC use cases which are widely in place but we didn't rate them w.r.t. security. For sure, you are right, the listed use cases are not very coherent w.r.t. security requirements. But that is what you currently  find out there in the networks.
>> 
>> I will check, if the SFC problem statement draft includes such security concerns. This is probably the best place for the privacy issues. At least, the SFC architecture draft includes a paragraph:
>> 
>> "An operator may consider the SFC Metadata as sensitive. Therefore,
>> solutions should consider whether there is a risk of sensitive
>> information slipping out of the operators control."
>> 
>> Narseo, if you have a proposal to improve the text, please feel free to send it over.
>> 
>> Best regards,
>> Walter
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: sfc [mailto:[e-mail]] Im Auftrag von Narseo Vallina Rodriguez
>> Gesendet: Dienstag, 10. Februar 2015 08:34
>> An: Ron Parker
>> Cc: [e-mail]
>> Betreff: 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
>> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc