Subject: [sfc] HTTP Header injection

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Mon, 9 Feb 2015 11:43:38 -0800

Hi,

I've been working for a while on analyzing headers added by
middleboxes, in particular in the context on mobile networks. This
draft is very interesting to read.

It brings a number of questions to mind.  The most basic is regarding
user's privacy.  I'd appreciate hearing perspectives on it.  In
particular, I'm wondering about the security and privacy implications
for mobile user associated with adding unique identifiers (aka
perma-cookies), and other values such as the IMEI, IMSI and MSISDN
that can be maliciously used to identify, profile and track mobile
users.

Many thanks,

Narseo Vallina-Rodriguez
http://www.icsi.berkeley.edu/~narseo

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Mon, 9 Feb 2015 13:10:25 -0800

Just to clarify, I'm referring to this specific use-case for mobile networks:

https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-00#section-3.3

---

From: Ron Parker <[email-masked]>
Date: Mon, 9 Feb 2015 22:27:58 +0000

Narseo,

There are a few techniques I know of that are sometimes utilized to address this issue:

1.  One-way anonymization of identifying fields
2.  Reversable anonymization with dictionary maintained separately and/or securely
3.  Encrypted values inserted as the values of the headers

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Narseo Vallina Rodriguez
Sent: Monday, February 9, 2015 4:10 PM
To: [email-masked]
Subject: [GRAYMAIL] Re: [sfc] HTTP Header injection

> http://www.icsi.berkeley.edu/~narseo

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

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Mon, 9 Feb 2015 14:53:45 -0800

Hi Ron

Thanks a lot for your response!

As I understand from your answer, that will prevent the leak of the
real value itself but the problem is that it still allows any server
(as the HTTP headers are injected to ANY HTTP request) to track any
user uniquely.

For instance, the hash of the IMSI will not leak the IMSI value itself
but it will still be a unique value for a given GSM subscriber. As a
result, any web-server could use this information for tracking
purposes and profiling, which could be used maliciously.

There is no way of controlling where this information actually ends
up, and web tracking is becoming a serious privacy concern. As a
result, this is still a quite sensitive privacy leak in my opinion.
Moreover, we have seen that mobile proxies do not advertise their
presence as it is supposed to be done with the VIA field according to
the HTTP standards so the header injection happens behind the scenes
without user awareness.

I'm curious about the reason behind injecting this information as I
can see the privacy implications but not the actual benefit for the
user or even for the operator unless it's for advertisement purposes.
It's a bit contradictory, as the draft mentions that one of the
use-cases is protecting users' privacy.

Any insight will be very appreciated

Many thanks!

Cheers

---------- Forwarded message ----------
From: Ron Parker <[email-masked]>
Date: Mon, Feb 9, 2015 at 2:27 PM
Subject: RE: [GRAYMAIL] Re: [sfc] HTTP Header injection
To: Narseo Vallina Rodriguez <[email-masked]>,
"[email-masked]" <[email-masked]>

Narseo,

There are a few techniques I know of that are sometimes utilized to
address this issue:

1.  One-way anonymization of identifying fields
2.  Reversable anonymization with dictionary maintained separately
and/or securely
3.  Encrypted values inserted as the values of the headers

   Ron

---

From: Ron Parker <[email-masked]>
Date: Mon, 9 Feb 2015 23:33:31 +0000

Narseo,

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.

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.

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.

   Ron

-----Original Message-----
From: Narseo Vallina Rodriguez [mailto:[email-masked]] 
Sent: Monday, February 9, 2015 5:54 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection

Hi Ron

As I understand from your answer, that will prevent the leak of the real value itself but the problem is that it still allows any server (as the HTTP headers are injected to ANY HTTP request) to track any user uniquely.

For instance, the hash of the IMSI will not leak the IMSI value itself but it will still be a unique value for a given GSM subscriber. As a result, any web-server could use this information for tracking purposes and profiling, which could be used maliciously.

There is no way of controlling where this information actually ends up, and web tracking is becoming a serious privacy concern. As a result, this is still a quite sensitive privacy leak in my opinion.
Moreover, we have seen that mobile proxies do not advertise their presence as it is supposed to be done with the VIA field according to the HTTP standards so the header injection happens behind the scenes without user awareness.

I'm curious about the reason behind injecting this information as I can see the privacy implications but not the actual benefit for the user or even for the operator unless it's for advertisement purposes.
It's a bit contradictory, as the draft mentions that one of the use-cases is protecting users' privacy.

Many thanks!

Cheers

---------- Forwarded message ----------
From: Ron Parker <[email-masked]>
Date: Mon, Feb 9, 2015 at 2:27 PM
Subject: RE: [GRAYMAIL] Re: [sfc] HTTP Header injection
To: Narseo Vallina Rodriguez <[email-masked]>, "[email-masked]" <[email-masked]>

Narseo,

1.  One-way anonymization of identifying fields 2.  Reversable anonymization with dictionary maintained separately and/or securely 3.  Encrypted values inserted as the values of the headers

   Ron

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Mon, 9 Feb 2015 16:26:47 -0800

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.   T…

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 encapsulati…

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?

---

From: Ron Parker <[email-masked]>
Date: Tue, 10 Feb 2015 00:54:36 +0000

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 [[email-masked]]
Sent: Monday, February 09, 2015 7:26 PM
To: Ron Parker
Cc: [email-masked]
Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection

Hi Ron

x-acr
X-UIDH
X-VF-ACR

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Mon, 9 Feb 2015 23:34:28 -0800

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

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Tue, 10 Feb 2015 12:06:27 +0000

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:[email-masked]] Im Auftrag von Narseo Vallina Rodriguez
Gesendet: Dienstag, 10. Februar 2015 08:34
An: Ron Parker
Cc: [email-masked]
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

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Tue, 10 Feb 2015 17:06:36 -0800

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

---

From: <[email-masked]>
Date: Fri, 13 Feb 2015 14:12:09 +0000

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:[email-masked]] De la part de Narseo Vallina Rodriguez
Envoyé : mardi 10 février 2015 08:34
À : Ron Parker
Cc : [email-masked]
Objet : Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

Hi Ron

Many thanks again

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Tue, 17 Feb 2015 18:17:56 -0800

Hi Mohamed

Thanks a lot for the pointer. That explains the reason why certain
headers may be useful but still does not answer why some privacy
sensitive headers are explicitly listed on the mobile use case.

Are there any examples about the privacy sensitive headers?

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 17 Feb 2015 22:25:37 -0800

> 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

---

From: <[email-masked]>
Date: Wed, 18 Feb 2015 07:37:26 +0000

Hi Narseo,

"Sensitive" headers need to be stripped before existing the PLMN. I think most of the cases can "disappear" from the public Internet by alerting those operators. Headers I'm aware of are injected for a service usage that is local to a PLMN. It may happen that an information is leaked outside the domain due to various reasons. 

Understanding the privacy implications of a header requires understanding the service motivation at first place. Unfortunately, the IETF is still resisting to work on such topics even if "Forward" was published recently: http://tools.ietf.org/html/rfc7239 or the analysis in https://tools.ietf.org/html/rfc6967. 

Cheers,
Med

-----Message d'origine-----
De : Narseo Vallina Rodriguez [mailto:[email-masked]] 
Envoyé : mercredi 18 février 2015 03:18
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; Ron Parker
Objet : Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

Hi Mohamed

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Fri, 20 Feb 2015 11:25:50 +0000

Dear Narseo,

Sorry for this late feedback. I was out of office for a while. Your blog is a very valuable contribution. I will share it with all Vodafone operational units you mentioned. Wrt Vodafone Germany I can tell you that
- we overwrite http headers. Means whatever a cheater would inject does not survive.
- at the moment we transfer IMSI to third party subscribers we have a contractual relationship. Use case e.g. is charging ring tone downloads (or games etc)
- we will fully block IMSI usage in the future and instead use an IPv6 user address. Getting the user identity then requires an authorized, encrypted LDAP query.
Do you see any issues with this planned procedure?

Wrt the IETF draft I will work out a small paragraph describing these facts. But I want to avoid a security discussion on possible solutions. This must be part of the other SFC drafts.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: Narseo Vallina Rodriguez [mailto:[email-masked]] 
Gesendet: Mittwoch, 11. Februar 2015 02:07
An: Haeffner, Walter, Vodafone DE
Cc: Ron Parker; [email-masked]; Stiemerling, Martin, Prof. Dr. ([email-masked])
Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

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.

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:

On Tue, Feb 10, 2015 at 4:06 AM, Haeffner, Walter, Vodafone DE <[email-masked]> wrote:
>> header enrichment that may be worth discussing further. Let me 
>> respond inline.
>>
>> 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.
>>
>> 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 
>> 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
>>
>> 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.
>>

---

From: Narseo Vallina Rodriguez <[email-masked]>
Date: Fri, 20 Feb 2015 14:43:46 -0800

Hi Walter

Thanks for the feedback. I'm glad to see that operators are taking
these considerations into account.

Regarding the IPv6 addition, that is still a quite sensitive leak in
my opinion. If all the traffic is being proxied, and the client IPv6
address is included on a HTTP header, which is unique, then any server
will be able to track the client independently of the LDAP lookup.

If the LDAP lookup is going to be implemented nonetheless, a better
way could be generating a random temporal key that expires in a
relative short term. Then the server will perform the lookup but the
key will be randomly generated, making harder any tracking. I'd also
suggest that the VIA field is also included in the header as the HTTP
standards indicate so both client and server know that the HTTP
traffic has been proxied.

Does it make sense?

Cheers

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Tue, 24 Feb 2015 09:59:01 +0000

Hi Narseo,

We also discuss internally if IPv6 should be leaked or not. Indeed we also have a solution in place and ready to implement which is based on a one-time, session-based key exchanged between user equipment and third party OTT service platform. Guess this method basically reflects your idea below. 

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: Narseo Vallina Rodriguez [mailto:[email-masked]] 
Gesendet: Freitag, 20. Februar 2015 23:44
An: Haeffner, Walter, Vodafone DE
Cc: Ron Parker; [email-masked]; Stiemerling, Martin, Prof. Dr. ([email-masked])
Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection

Hi Walter

Thanks for the feedback. I'm glad to see that operators are taking these considerations into account.

Regarding the IPv6 addition, that is still a quite sensitive leak in my opinion. If all the traffic is being proxied, and the client IPv6 address is included on a HTTP header, which is unique, then any server will be able to track the client independently of the LDAP lookup.

If the LDAP lookup is going to be implemented nonetheless, a better way could be generating a random temporal key that expires in a relative short term. Then the server will perform the lookup but the key will be randomly generated, making harder any tracking. I'd also suggest that the VIA field is also included in the header as the HTTP standards indicate so both client and server know that the HTTP traffic has been proxied.

Does it make sense?

Cheers

On Fri, Feb 20, 2015 at 3:25 AM, Haeffner, Walter, Vodafone DE <[email-masked]> wrote:
> Dear Narseo,
>
> Sorry for this late feedback. I was out of office for a while. Your 
> blog is a very valuable contribution. I will share it with all 
> Vodafone operational units you mentioned. Wrt Vodafone Germany I can 
> tell you that
> - at the moment we transfer IMSI to third party subscribers we have a 
> contractual relationship. Use case e.g. is charging ring tone 
> downloads (or games etc)
>>> 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.
>>>
>>> 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
>>>