Subject: RE: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC

From: <[email-masked]>
Date: Thu, 2 Mar 2017 09:17:29 +0000

Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Hardie [mailto:[email-masked]]
Envoyé : samedi 25 février 2017 01:26
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC

Hi Mohamed,
Some replies in-line.

On Fri, Feb 24, 2017 at 12:55 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 24 février 2017 00:40
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC

HI Mohamad,

Thanks for rechecking; some further comments in-line.

On Wed, Feb 22, 2017 at 11:21 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted,

Thank you for the reply and for implementing these changes.

I checked the diff, but I’m afraid the -06 version has the same issues as the ones I reported in January 31.

I did respond to the particular comments and text proposals, so I assume this is the more general issue.  If I understand correctly, you would prefer this document to be structured as a revision to the threat model document or connected to a larger consideration of the issues.  I understand that, and it was considered, but I believe that this format is still the most effective for the narrow issue it addresses.
[Med] That was one of my concerns; not the only one. In Particular, I’m trying to understand how this document will be used in the future to better strengthen forthcoming specifications. Further, the experience I had when advancing some RFCs is that RFC7258 wording can be further enhanced to provide clear guidance. Also, considerations such as the following are missing from the document:
It's difficult to say how something will be used in the future.
[Med] An advice that is not implementable makes more troubles, IMHO.
My intent (and the understanding of other reviewers) is to highlight that these mechanisms have a privacy-damaging result and that this should be considered.
[Med] I do think existing documents already make that job. I do think we need more.
 In particularly, I'm concerned that some application functions in the network (e.g. recursive resolvers or proxies) do not consider the postive privacy implications of their aggregation and so do not consider adding this data back as problematic.
[Med] I’m also concerned with that, too (see e.g., http://www1.icsi.berkeley.edu/~narseo/papers/hotm42-vallinarodriguez.pdf). In the meantime, I’m also concerned with (1) some applications that leak privacy information without the consent of the user and (2) some application servers that may correlate various information shared by an application client to track users (e.g., https://panopticlick.eff.org/). BTW, I see that you are using “application function” which may not have the same meaning as the general “protocol” wording used in draft-hardie-*. Do you consider a DHCP relay as an “application function”?
   Highlighting this enables them to see this traffic in a different context.
[Med] Isn’t this already assumed by some protocol designers (e.g., RFC6973, SIP)? BTW, there are subtleties when proxies are in the same trust domain of the client or server.

* that data may not be always available to the endhost
Understood, but even in this case, it is better to make the permission to add the data explicit.
[Med] This may be easy to implement for some applications, but this may not be generalized to ** all ** protocols. Putting aside the interaction with a user to get a consent and how that consent will need to be changed when another user uses the same device to connect to the Internet. Consider a user who does not want an upstream DHPC relay to insert the line-id (https://tools.ietf.org/html/rfc6788) to the server, and let’s suppose the relay received a signal (by some means, to be yet specified) that for this particular DHCP client, the line-id must not be inserted. For this case, connectivity won’t be provided to that user. This would mean extra calls to the hotline for that network provider. This is not desirable for both customers and network providers.

Another example is address-sharing (https://tools.ietf.org/html/rfc6269#section-13.1), a misbehaving user may impact all the users under the same address. I bet such user won’t give his/her permission so that means to demux its packets.

It is also often possible for the end system to gain this data at the cost of other traffic(e.g. the STUN server requests noted in the document).
[Med] I’m not sure whether this is ‘often’, but for sure this is possible for some cases. Extra requests may be needed, Indeed. Better, the information may even be even available locally, for example there is even no need to run STUN/PCP to provide an XFF or Forward-For headers.

If this can be done in parallel with other actions, then the latency impact can be minimized.
[Med] These are assumptions and implications that are worth to be added to the draft. BTW, this falls into this general discussion in https://tools.ietf.org/html/rfc6973:

   a.  Trade-offs.  Does the protocol make trade-offs between privacy
       and usability, privacy and efficiency, privacy and
       implementability, or privacy and other design goals?  Describe
       the trade-offs and the rationale for the design chosen.
* a misbehaving node may be tempted to spoof the data to be injected. A remote device that will use that data to enforce policies will be broken.
This point was discussed extensively in the GEOPRIV work and essentially a single carve-out was made:  for emergency services, where falsely asserted location data could be used to SWAT individuals or consume safety resources.    I don't think that falls into this narrow advice, but I would be willing to add something like this to the security considerations:
"Note that some emergency service recipients, notably PSAPs (Public Safety Answering Points) may prefer data provided by a network to data provided by end system, because an end system could use false data to attack others or consume resources.   While this has the consequence that the data available to the PSAP is often more coarse than that available to the end system, the risk of false data being provided involved a risk to the lives of those targeted."
[Med] Thank you. Providing PSAP as an example is OK, but I’d like the issue to be called out as a generic one while PSAP is provided as an example. What about the following:

"Note that some servers (e.g., emergency service recipients, notably PSAPs (Public Safety Answering Points) [RFC6443]) may prefer data provided by a network to data provided by the end system, because an end system could use false data to attack others or consume resources.  While this has the consequence that the data available to the server is often more coarse than that available to the end system, the risk of false data being provided involved a risk to the lives of those targeted."

* it was reported in the past that some browsers leak the MSISDN and other sensitive data.
This is true, but it seems to me unrelated to the point of the document.
[Med] It is related because blindly trusting an application client (and server) has its own privacy risks. This is even exacerbated given the rich data that is available to an application client and also because of the visibility on various layers available to an application server.
From that flow some of your other concerns about audience, at least as I understand.  As written, this is narrow advice for a broad audience: basically, anyone who would consider the form of metadata insertion it describes.  You would, if I understand you, prefer a narrower description of the audience in a larger context.

[Med] The key point here is about the practicality of implementing the advice NOT changing the scope. For example, the document says that it is better that a host is injecting the data but the document does not question whether that supplied data can be trusted or not, or how the consent will be obtained from a user.

In general, the point of the document is that the host should be able to omit the data without mid-network devices adding it back.  That's the point of protecting the traffic in the first place, after all.  I am saying that if the protocols require the data, then getting it from the end host has better privacy properties than getting from it from mid-network entities.
[Med] I’m not sure we can have such general statement because the data may not be available (e.g., DHCP for example) to clients + the data supplied by clients (when possible) may not be reliable + enforcing policies based on client-supplied data may have implication on other users (e.g., spoofing XFF for example). Obviously, getting some of the information from a client may have implications on QoE…the user needs to understand the root causes of a degradation of QoE. Of course, these implications may not be new for users who are familiar with disabling Java scripts and cie.

For example, the document states that the information in a Forward-For header can be supplied by the host itself and then communicated to a remote consumer. This is indeed possible, but because of abusing hosts some servers implement whitelists to trust proxies; see https://meta.wikimedia.org/w/extensions/TrustedXFF/trusted-hosts.txt.

The Wikimedia case is a very interesting one to raise, because it derives from a set of assumptions about the network that are somewhat flawed and then attempts to patch those flaws in ways that actually damage the mechanisms of the system they originally built.
Wikimedia wants to allow folks to edit without login credentials.  This allows for anonymous users to make corrections or additions; this is a goal.  The consequence of that goal being achieved is that trolls or malicious editors can have at anything they want.
Rather than institute credentials and ACLs, Wikimedia attempts to substitute blocking by IP for blocking by credential.  The property they are looking for in IPs is not really there, though:  they are not unique to individuals, especially over time.

This damages those who share IP addresses (due to NATs or proxies).  As far as I can tell, the NAT problem is simply treated as collateral damage.  For the proxies, they attempt to work around the damage using XFF.  That's spoofable, though, so they attempt to limit it to specific proxies whose XFF they trust--many of which require logins.  That shifts the information about who is editing Wikipedia out of their hands, but leaves it in the network and thus not truly anonymous.  I understand the engineering balance they are trying to strike, but I'm not sure I can recommend their solution.

[Med] I’m not recommending their solution either, but I’m trying to raise the point that an engineering balance is out there. ACKing that deployment reality is better than ignoring it.

I’m reiterating that most of my comments are still unaddressed in -06.

I realize that the document did not change to address the audience or document integration you preferred; I think there we simply disagree on how to make this advice effective.  I'm sorry that first message apparently did not describe the disagreement effectively.
If I have misunderstood your comments, please accept my apologies. I would be happy of further clarification and suggested text to illustrate your preferences would be especially welcome.
[Med] Sure. Before that, can you please consider rechecking the detailed list of comments available at: https://www.ietf.org/mail-archive/web/ietf/current/msg101629.html. Thank you.

Thanks again for your engagement on this,
regards,
Ted

thanks,
Ted Hardie

Cheers,
Med

De : Ted Hardie [mailto:[email-masked]<mailto:[email-masked]>m]
Envoyé : mercredi 22 février 2017 23:09
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC

Hi Mohamed,
Thanks for your review.  I've uploaded a draft -06 with updates from your and other reviews.  Some notes in-line.

On Tue, Jan 31, 2017 at 1:49 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Ted,

Please find below my general review of the document and also my detailed comments.

* Overall:
- I don't think the document is ready to be published as it is. It does not discuss the usability and implications of the advice. Further, it may be interpreted that a client/end system/user can always by itself populate data that is supplied by on-path nodes (in current deployments). That's assumption is not true for some protocols.
- The purpose of publishing this advice is not clear. For example, how this advice will be implemented in practice? What is its scope?
- I would personally prefer an updated version of RFC7258 with more strict language on the privacy-related considerations. This is more actionable with concrete effects in documents that will required to include a discussion on privacy related matters.

Detailed comments are provided below:

* The abstract says the following:

   The IAB has published [RFC7624] in response to several revelations of
   pervasive attack on Internet communications.  This document considers
   the implications of protocol designs which associate metadata with
   encrypted flows.  In particular, it asserts that designs which do so
   by explicit actions of the end system are preferable to designs in
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   which middleboxes insert them.

I suggest you explicit what is meant by "the end system".

I have updated this to clarify that this is the host/end system not the user.

If you mean the owner/user, then the text should say so. If you mean a client software instance, then bugs/inappropriate default values may lead to (privacy leak) surprises too. It was reported in the past that some browsers inject the MSISDN too.

* Introduction: "To ensure that the Internet can be trusted by users"

Rather « To minimize the risk of Internet-originated attacks targeted at users ».

I've adopted this language.

It's reasonable to claim the Internet can be trusted by users; see how the usage of social networks has become severely twisted for example

I've also considered your point that an updated version of RFC7258 might be a better outlet for advice like this. We did consider several approaches, including incorporating the text in an update to  RFC 3552 or as part of a document describing the full set of companion mitigations to the threats in RFC 7624 (draft-iab-privsec-confidentiality-mitigations would be one approach).  Those are all valid approaches, but it seemed that short, easily read documents tackling a single point might be easier to produce and consume.
Thanks again for your review,
Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Mar 2017 10:02:05 -0800

> [Med] An advice that is not implementable makes more troubles, IMHO.
Sorry, I thought you were asking what wgs or protocols planned to reference
this.  For that, I don't know.  The intent is that it is information useful
to those considering whether restoring metadata lost to encryption in
mid-network is the right way to go.

> My intent (and the understanding of other reviewers) is to highlight that
> these mechanisms have a privacy-damaging result and that this should be
> considered.
>
Sorry, did you mean "do not think we need more"?  If so, I obviously
disagree.  This design pattern is used uncritically enough that a brief
document describing why it isn't safe still seems to me useful.  Were it
incorporated into a more general document (as noted before), that would
also work.  If it later is, that more general work could obsolete this
(though that's a bid for an informational document).

>  In particularly, I'm concerned that some application functions in the
> network (e.g. recursive resolvers or proxies) do not consider the postive
> privacy implications of their aggregation and so do not consider adding
> this data back as problematic.
>
> [Med] I’m also concerned with that, too (see e.g.,
> http://www1.icsi.berkeley.edu/~narseo/papers/hotm42-vallinarodriguez.pdf).
> In the meantime, I’m also concerned with (1) some applications that leak
> privacy information without the consent of the user and (2) some
> application servers that may correlate various information shared by an
> application client to track users (e.g., https://panopticlick.eff.org/).
> BTW, I see that you are using “application function” which may not have the
> same meaning as the general “protocol” wording used in draft-hardie-*. Do
> you consider a DHCP relay as an “application function”?
>
> [Med] Isn’t this already assumed by some protocol designers (e.g.,
> RFC6973, SIP)? BTW, there are subtleties when proxies are in the same trust
> domain of the client or server.
>
> There are certainly some protocol designers that have internalized this,
but my experience has been that this is not always the case.  In a fair few
cases, folks deploy  methods like this because they see encryption of
metadata in data integrity terms or see aggregation only in terms of data
usage minimization.  They restore the metadata mid-network because it is
the quickest solution for them to get back to the status quo ante for their
understanding of the system.

> [Med] This may be easy to implement for some applications, but this may
> not be generalized to ** all ** protocols.
>

You are certainly correct that many deployed protocols would find it hard
to retrofit this consent model into their existing flows.    This is,
however, advice for folks at the design phase.  If RFC 6788 were being
written after the publication of this document, its authors might well have
looked at the protocol mechanics in section 5.2:

   The AN
   intercepts and then tunnels the received Router Solicitation in a
   newly created IPv6 datagram with the Line-Identification Option
   (LIO).  The AN forms a new IPv6 datagram whose payload is the
   received Router Solicitation message as described in [RFC2473
<https://tools.ietf.org/html/rfc2473>],
   except that the Hop Limit field of the Router Solicitation message
   MUST NOT be decremented.

and asked whether the circuit identifier corresponding to the logical
access loop port of the AN from which the RS was initiated PII.  If so, this
document would have them consider whether transparent interception
is the appropriate choice if it is.  There clearly are flows in which
the AN's role
would be explicit.

I don't know, frankly, which choice is right in this case, but I would
prefer that
the choice be made with an easy reference to the implications of
inserting metadata
at hand.

Putting aside the interaction with a user to get a consent and how that
> consent will need to be changed when another user uses the same device to
> connect to the Internet. Consider a user who does not want an upstream DHPC
> relay to insert the line-id (https://tools.ietf.org/html/rfc6788) to the
> server, and let’s suppose the relay received a signal (by some means, to be
> yet specified) that for this particular DHCP client, the line-id must not
> be inserted. For this case, connectivity won’t be provided to that user.
> This would mean extra calls to the hotline for that network provider. This
> is not desirable for both customers and network providers.
>
> I
>

> f this can be done in parallel with other actions, then the latency impact
> can be minimized.
>
> [Med] These are assumptions and implications that are worth to be added to
> the draft.
>

Okay, how about the following text being added to section 5.

There also tensions with latency of operation. For example, where the end
system does not initially know the information which would be added by
on-path devices, it must engage the protocol mechanisms to determine it.
Determining a public IP address to include in a locally supplied header
might require a STUN exchange, and the additional latency of this exchange
discourages deployment of host-based solutions.  To minimize this latency,
engaging those mechanisms may need to be done in parallel with or in
advance of the core protocol exchanges with which this metadata would be
supplied.

> BTW, this falls into this general discussion in
> https://tools.ietf.org/html/rfc6973:
>
>
>
> * a misbehaving node may be tempted to spoof the data to be injected. A
> remote device that will use that data to enforce policies will be broken.
>
> This point was discussed extensively in the GEOPRIV work and essentially a
> single carve-out was made:  for emergency services, where falsely asserted
> location data could be used to SWAT individuals or consume safety
> resources.    I don't think that falls into this narrow advice, but I would
> be willing to add something like this to the security considerations:
>
> "Note that some emergency service recipients, notably PSAPs (Public Safety
> Answering Points) may prefer data provided by a network to data provided by
> end system, because an end system could use false data to attack others or
> consume resources.   While this has the consequence that the data available
> to the PSAP is often more coarse than that available to the end system, the
> risk of false data being provided involved a risk to the lives of those
> targeted."
>
> [Med] Thank you. Providing PSAP as an example is OK, but I’d like the
> issue to be called out as a generic one while PSAP is provided as an
> example. What about the following:
>
>
>
> "Note that some servers (e.g., emergency service recipients, notably PSAPs
> (Public Safety Answering Points) [RFC6443]) may prefer data provided by a
> network to data provided by the end system, because an end system could use
> false data to attack others or consume resources.  While this has the
> consequence that the data available to the server is often more coarse than
> that available to the end system, the risk of false data being provided
> involved a risk to the lives of those targeted."
>
>
>

I don't think that emergency service recipients shifting to an example
works here, because it broadens the carve out.  In the emergency services
case, the resources consumed are fire trucks, ambulances, and swat teams.
For other servers, resources consumed could simply be  CPU cycles or disk;
that's really not the same.  Balancing location consent requirements
against one was agreed; balancing it against the other was not.

> [Med] It is related because blindly trusting an application client (and
> server) has its own privacy risks. This is even exacerbated given the rich
> data that is available to an application client and also because of the
> visibility on various layers available to an application server.
>

I agree that it has its own privacy risks, but I don't think this is the
document that should explore them.

> From that flow some of your other concerns about audience, at least as I
> understand.  As written, this is narrow advice for a broad audience:
> basically, anyone who would consider the form of metadata insertion it
> describes.  You would, if I understand you, prefer a narrower description
> of the audience in a larger context.
>
>
>
> [Med] The key point here is about the practicality of implementing the
> advice NOT changing the scope. For example, the document says that it is
> better that a host is injecting the data but the document does not question
> whether that supplied data can be trusted or not,
>
>
Broadening this a bit, you're looking at two cases: one in which the data
the host has is wrong and one in which there is an adversarial
relationship.  For the first case, we can add text saying that when an end
system supplies data it is the end system's responsibility to ensure that
it is correct; don't use a STUN result from last week as fresh, for
example.   For the second case,  in which the server treats user supplied
data as potentially misleading because the user may wish to circumvent
restrictions, I'll point out the Wikimedia example demonstrates that simply
shifting the trust to a mid-point entity doesn't work; it has to be shifted
to an entity within the trust domain of the server.  So the question isn't
really "end-user system supplied data can be trusted or not", the same
question applies to whomever supplies the data.

or how the consent will be obtained from a user.

You're right that I'm leaving aside the question of how the user sets the
policies, because it may vary by protocol and type of device too much to
make general advice useful.  If you would like me to add an explicit
statement to that effect, I am happy to note that it is not covered.

>
>
> In general, the point of the document is that the host should be able to
> omit the data without mid-network devices adding it back.  That's the point
> of protecting the traffic in the first place, after all.  I am saying that
> if the protocols require the data, then getting it from the end host has
> better privacy properties than getting from it from mid-network entities.
>
> [Med] I’m not sure we can have such general statement because the data may
> not be available (e.g., DHCP for example) to clients + the data supplied by
> clients (when possible) may not be reliable + enforcing policies based on
> client-supplied data may have implication on other users (e.g., spoofing
> XFF for example). Obviously, getting some of the information from a client
> may have implications on QoE…the user needs to understand the root causes
> of a degradation of QoE. Of course, these implications may not be new for
> users who are familiar with disabling Java scripts and cie.
>
>
>
> For example, the document states that the information in a Forward-For
> header can be supplied by the host itself and then communicated to a remote
> consumer. This is indeed possible, but because of abusing hosts some
> servers implement whitelists to trust proxies; see
> https://meta.wikimedia.org/w/extensions/TrustedXFF/trusted-hosts.txt.
>
>
>
>
>
>
> The Wikimedia case is a very interesting one to raise, because it derives
> from a set of assumptions about the network that are somewhat flawed and
> then attempts to patch those flaws in ways that actually damage the
> mechanisms of the system they originally built.
>
> Wikimedia wants to allow folks to edit without login credentials.  This
> allows for anonymous users to make corrections or additions; this is a
> goal.  The consequence of that goal being achieved is that trolls or
> malicious editors can have at anything they want.
>
> Rather than institute credentials and ACLs, Wikimedia attempts to
> substitute blocking by IP for blocking by credential.  The property they
> are looking for in IPs is not really there, though:  they are not unique to
> individuals, especially over time.
>
> This damages those who share IP addresses (due to NATs or proxies).  As
> far as I can tell, the NAT problem is simply treated as collateral damage.
> For the proxies, they attempt to work around the damage using XFF.  That's
> spoofable, though, so they attempt to limit it to specific proxies whose
> XFF they trust--many of which require logins.  That shifts the information
> about who is editing Wikipedia out of their hands, but leaves it in the
> network and thus not truly anonymous.  I understand the engineering balance
> they are trying to strike, but I'm not sure I can recommend their solution.
>
>
>
> [Med] I’m not recommending their solution either, but I’m trying to raise
> the point that an engineering balance is out there. ACKing that deployment
> reality is better than ignoring it.
>
>
>

The deployment considerations text is meant to point out the engineering
balance.  I'm happy to add the text noted above (on latency, the end user
responsibility for correct data, the PSAP carve out, and the explicit note
that the document does not treat how to obtain consent from a user so that
an end system can supply data).

I'm less happy to add language on adversarial treatment of client-supplied
data.  This is partly because many of the systems which use
network-supplied data are based on a misunderstanding of the properties of
the data being added.  It is partly because the adversarial relationship
can extend to network-supplied data.  It is also because a fair few of them
are simply security theater.  If you have a specific edit you would like to
propose, though, I will consider it.

Thanks again,

Ted

---

From: <[email-masked]>
Date: Fri, 3 Mar 2017 09:23:28 +0000

Hi Ted,

Please see inline.

Cheers,
Med

Envoyé : jeudi 2 mars 2017 19:02

wing are missing from the document:
It's difficult to say how something will be used in the future.
[Med] An advice that is not implementable makes more troubles, IMHO.
Sorry, I thought you were asking what wgs or protocols planned to reference this.  For that, I don't know.
[Med] OK. IMHO lacking such considerations, there is a high risk that the advice will be lost or that it can be used as a permanent DISCUSS point in later stages of preparing documents. I’d prefer if actionable points to be considered by WGs and document authors in early stages.

The intent is that it is information useful to those considering whether restoring metadata lost to encryption in mid-network is the right way to go.
[Med] This is another assumption in the document that I disagree with: It seems that you assume that an on-path device, that inserts metadata, is necessarily RESTORING back that information. This is not true for many efforts:

·         A Forward-For header inserted by a proxy does not restore any data; it does only reveal data that is already present in the packet issued by the client itself.

·         An address sharing device, under for example DS-Lite (RFC6333), that inserts the source IPv6 prefix in the TCP HOST_ID option (RFC7974) is not RESTORING any data. The content of that TCP option is already visible in the packet sent by the host.

·         Service Function Chaining WG (https://datatracker.ietf.org/wg/sfc/about/) is defining an architecture to communicate metadata by on-path devices; that metadata is inserted at the network side. Border nodes will make sure that data is stripped before forwarding packets to the ultimate destinations. The metadata can be a subscriber-id, a policy-id, etc.

So when draft-hardie-* says: “Do not add metadata to flows at intermediary devices unless
   a positive affirmation of approval for restoration has been received
   from the actor whose data will be added.”

(1) Do you assume that the sample examples I listed above fall under your advice?
(2) How an on-path device will know the data it intends to insert is a “restoration”?
(3) Does it mean that for new data (i.e., that are not restoration), on-path devices are free to do whatever they want? For me, this is undesirable. There is a void there. A statement to require those networks to avoid leaking privacy information must be included.

Another assumption is made here:

   Instead, design the protocol so that the actor can add such metadata
   themselves so that it flows end-to-end, rather than requiring the
   action of other parties.  In addition to improving privacy, this
   approach ensures consistent availability between the communicating
   parties, no matter what path is taken.

This text claims that providing data by the endpoint ensures a “consistent availability” of that information. This is broken for a multi-homed host that uses for example Forward-For header: Obviously, the content of the header if injected by the endpoint will depend on the path. A way to ensure a “consistent availability” is to insert many Forward-For headers; each enclosing the content that is specific to a given network attachment. But doing that raises a privacy concern because the remote server can track clients.
My intent (and the understanding of other reviewers) is to highlight that these mechanisms have a privacy-damaging result and that this should be considered.
[Med] I do think existing documents already make that job. I do think we need more.

Sorry, did you mean "do not think we need more"?
[Med] I meant we need more than only highlighting the issue. We need something which is actionable. Requiring a Privacy Section in every RFC may a direction to consider.

  If so, I obviously disagree.  This design pattern is used uncritically enough that a brief document describing why it isn't safe still seems to me useful.  Were it incorporated into a more general document (as noted before), that would also work.  If it later is, that more general work could obsolete this (though that's a bid for an informational document).

 In particularly, I'm concerned that some application functions in the network (e.g. recursive resolvers or proxies) do not consider the postive privacy implications of their aggregation and so do not consider adding this data back as problematic.
[Med] I’m also concerned with that, too (see e.g., http://www1.icsi.berkeley.edu/~narseo/papers/hotm42-vallinarodriguez.pdf<http://www1.icsi.berkeley.edu/%7Enarseo/papers/hotm42-vallinarodriguez.pdf>). In the meantime, I’m also concerned with (1) some applications that leak privacy information without the consent of the user and (2) some application servers that may correlate various information shared by an application client to track users (e.g., https://panopticlick.eff.org/). BTW, I see that you are using “application function” which may not have the same meaning as the general “protocol” wording used in draft-hardie-*. Do you consider a DHCP relay as an “application function”?
   Highlighting this enables them to see this traffic in a different context.
[Med] Isn’t this already assumed by some protocol designers (e.g., RFC6973, SIP)? BTW, there are subtleties when proxies are in the same trust domain of the client or server.
There are certainly some protocol designers that have internalized this, but my experience has been that this is not always the case.  In a fair few cases, folks deploy  methods like this because they see encryption of metadata in data integrity terms or see aggregation only in terms of data usage minimization.  They restore the metadata mid-network because it is the quickest solution for them to get back to the status quo ante for their understanding of the system.

[Med] I hear you. What would be the harm if those solutions strip that information before sending it to the server? If they don’t strip it, this means that either the information can be parsed and used by the server, or at least its presence does not lead to session failures. In the case the server parses and uses that information, this means that the presence of that information is important for the service to deliver. In that case, the question is why the client does not supply that information at the first place.
* that data may not be always available to the endhost
Understood, but even in this case, it is better to make the permission to add the data explicit.
[Med] This may be easy to implement for some applications, but this may not be generalized to ** all ** protocols.

You are certainly correct that many deployed protocols would find it hard to retrofit this consent model into their existing flows.    This is, however, advice for folks at the design phase.  If RFC 6788 were being written after the publication of this document, its authors might well have looked at the protocol mechanics in section 5.2:

   The AN

   received Router Solicitation message as described in [RFC2473<https://tools.ietf.org/html/rfc2473>],

   MUST NOT be decremented.

and asked whether the circuit identifier corresponding to the logical
access loop port of the AN from which the RS was initiated PII.  If so, this
document would have them consider whether transparent interception
is the appropriate choice if it is.  There clearly are flows in which the AN's role
would be explicit.

I don't know, frankly, which choice is right in this case, but I would prefer that
the choice be made with an easy reference to the implications of inserting metadata
at hand.
Putting aside the interaction with a user to get a consent and how that consent will need to be changed when another user uses the same device to connect to the Internet. Consider a user who does not want an upstream DHPC relay to insert the line-id (https://tools.ietf.org/html/rfc6788) to the server, and let’s suppose the relay received a signal (by some means, to be yet specified) that for this particular DHCP client, the line-id must not be inserted. For this case, connectivity won’t be provided to that user. This would mean extra calls to the hotline for that network provider. This is not desirable for both customers and network providers.
I

f this can be done in parallel with other actions, then the latency impact can be minimized.
[Med] These are assumptions and implications that are worth to be added to the draft.

Okay, how about the following text being added to section 5.
There also tensions with latency of operation. For example, where the end system does not initially know the information which would be added by on-path devices, it must engage the protocol mechanisms to determine it.  Determining a public IP address to include in a locally supplied header might require a STUN exchange, and the additional latency of this exchange discourages deployment of host-based solutions.  To minimize this latency, engaging those mechanisms may need to be done in parallel with or in advance of the core protocol exchanges with which this metadata would be supplied.
[Med] Looks good to me. Thanks.

BTW, this falls into this general discussion in https://tools.ietf.org/html/rfc6973:

I don't think that emergency service recipients shifting to an example works here, because it broadens the carve out.  In the emergency services case, the resources consumed are fire trucks, ambulances, and swat teams.  For other servers, resources consumed could simply be  CPU cycles or disk; that's really not the same.  Balancing location consent requirements against one was agreed; balancing it against the other was not.

[Med] Resources may not be restricted to CPU or disk but may be granting access to the service (e.g., download a file when a quota per source address is enforced). It can be whatever the servers consider to be critical for them; it is up to the taste of the service design to characterize it. The NEW wording proposed above is technically correct. Please reconsider adding it to the draft.

I agree that it has its own privacy risks, but I don't think this is the document that should explore them.
[Med] You don’t need to explore them, but to add one or two sentences to remind that privacy leaks are still a valid concern even if only clients are supplying data without the help of an on-path network device.
From that flow some of your other concerns about audience, at least as I understand.  As written, this is narrow advice for a broad audience: basically, anyone who would consider the form of metadata insertion it describes.  You would, if I understand you, prefer a narrower description of the audience in a larger context.

[Med] The key point here is about the practicality of implementing the advice NOT changing the scope. For example, the document says that it is better that a host is injecting the data but the document does not question whether that supplied data can be trusted or not,

Broadening this a bit, you're looking at two cases: one in which the data the host has is wrong and one in which there is an adversarial relationship.  For the first case, we can add text saying that when an end system supplies data it is the end system's responsibility to ensure that it is correct; don't use a STUN result from last week as fresh, for example.
[Med] OK.

  For the second case,  in which the server treats user supplied data as potentially misleading because the user may wish to circumvent restrictions, I'll point out the Wikimedia example demonstrates that simply shifting the trust to a mid-point entity doesn't work; it has to be shifted to an entity within the trust domain of the server.  So the question isn't really "end-user system supplied data can be trusted or not", the same question applies to whomever supplies the data.
[Med] Fully agree. Having some text to record that the concern applies, including for client supplied data.

You're right that I'm leaving aside the question of how the user sets the policies, because it may vary by protocol and type of device too much to make general advice useful.  If you would like me to add an explicit statement to that effect, I am happy to note that it is not covered.
[Med] Please add some text about this point. Thank you.

The deployment considerations text is meant to point out the engineering balance.  I'm happy to add the text noted above (on latency, the end user responsibility for correct data, the PSAP carve out, and the explicit note that the document does not treat how to obtain consent from a user so that an end system can supply data).
[Med] Ok, thanks.
I'm less happy to add language on adversarial treatment of client-supplied data.  This is partly because many of the systems which use network-supplied data are based on a misunderstanding of the properties of the data being added.
[Med] I agree this may be the case for some of them, but not all.
  It is partly because the adversarial relationship can extend to network-supplied data.  It is also because a fair few of them are simply security theater.  If you have a specific edit you would like to propose, though, I will consider it.
Thanks again,
Ted

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Mar 2017 15:48:48 -0800

Hi Mohamed,

I've updated the draft and posted -07.  I believe it includes all of the
elements on which we have already agreed.  Some additional comments
in-line, once again with some snippage for readability.

On Fri, Mar 3, 2017 at 1:23 AM, <[email-masked]> wrote:

>
>
>
> The intent is that it is information useful to those considering whether
> restoring metadata lost to encryption in mid-network is the right way to go.
>
> [Med] This is another assumption in the document that I disagree with: It
> seems that you assume that an on-path device, that inserts metadata, is
> necessarily RESTORING back that information. This is not true for many
> efforts:
>
·         A Forward-For header inserted by a proxy does not restore any
> data; it does only reveal data that is already present in the packet issued
> by the client itself.
>
That's what restore means here.  If the information is present as metadata
in the packet sent to the proxy but would be absent as metadata under
normal operation of the proxy, adding it back in somewhere else restores
the metadata.  So origin IP address starts out in the IP header of the
original packet but gets pushed from that slot when the proxy constructs
the onward IP packet to the server.  For it to reach the server, it has to
be placed somewhere else in the onward packet, restoring the lost metadata.

Had it been present in the packet as header value in the HTTP exchange, it
would not have been stripped by normal operation.  There proxy operation
forwarding it on would be simply preserving it.

> ·         An address sharing device, under for example DS-Lite (RFC6333),
> that inserts the source IPv6 prefix in the TCP HOST_ID option (RFC7974) is
> not RESTORING any data. The content of that TCP option is already visible
> in the packet sent by the host.
>
I agree with the IESG analysis of RFC7974.  It does restore information by
taking information which normal operation would have elided and restores it.

> ·         Service Function Chaining WG (https://datatracker.ietf.org/
> wg/sfc/about/) is defining an architecture to communicate metadata by
> on-path devices; that metadata is inserted at the network side. Border
> nodes will make sure that data is stripped before forwarding packets to the
> ultimate destinations. The metadata can be a subscriber-id, a policy-id,
> etc.
>
>
>

I'm afraid I don't have enough context to know what border node operations
are here, so this is difficult for me to comment on, but I hope the two
examples above clarify my thinking.

> (2) How an on-path device will know the data it intends to insert is a

If the data is taken from a portion of the packet that would not normally
be forwarded to an upstream host and added to a portion that is forwarded
to an upstream host, then the device adding the data back in should know it
is a restoration.

> (3) Does it mean that for new data (i.e., that are not restoration),
> on-path devices are free to do whatever they want? For me, this is
> undesirable. There is a void there. A statement to require those networks
> to avoid leaking privacy information must be included.
>
>
Brian Trammell has an ever growing list of side channels attacks, and this
document doesn't mean to cover that entire ground.  It's advice for
protocol designers on what the privacy implications are of making the
choice to use network elements to carry this data.

> This text claims that providing data by the endpoint ensures a “consistent
> availability” of that information. This is broken for a multi-homed host
> that uses for example Forward-For header: Obviously, the content of the
> header if injected by the endpoint will depend on the path.
>

If the endpoint sends the data, data will be consistently available in that
header.  The data changes, of course.

>
> [Med] Resources may not be restricted to CPU or disk but may be granting
> access to the service (e.g., download a file when a quota per source
> address is enforced). It can be whatever the servers consider to be
> critical for them; it is up to the taste of the service design to
> characterize it. The NEW wording proposed above is technically correct.
> Please reconsider adding it to the draft.
>
>
>

I did consider it, but I continue to believe that it moves the needle too
far into simple server preference.  I retained the original PSAP language
in -07 as a result.

I also added a note about your extensive review.  While you and I clearly
have some differences of view, the document has gotten better from your
engagement with it, and I appreciate your efforts.

regards,

Ted

---

From: <[email-masked]>
Date: Mon, 6 Mar 2017 09:48:05 +0000

Hi Ted,

Please see inline.

Cheers,
Med

Envoyé : samedi 4 mars 2017 00:49

Hi Mohamed,
I've updated the draft and posted -07.  I believe it includes all of the elements on which we have already agreed. Some additional comments in-line, once again with some snippage for readability.

On Fri, Mar 3, 2017 at 1:23 AM, <[email-masked]<mailto:[email-masked]>> wrote:

•         A Forward-For header inserted by a proxy does not restore any data; it does only reveal data that is already present in the packet issued by the client itself.
That's what restore means here.
[Med] Then, this needs to be defined in the document. I naively assumed that “restored” is used to mean any piece of information that the client does not want to insert in a packet, but an on-path device decides to inject it despite there is no consent from the client. What you are describing is more about “maintaining” or “preserving” information not restoring it.

  If the information is present as metadata in the packet sent to the proxy but would be absent as metadata under normal operation of the proxy, adding it back in somewhere else restores the metadata.
[Med] “normal operation of proxy” is not a standard. A “normal operation of proxy” would be to maintain the information sent by the client when relaying it to the server. I’m sure you know for instance that SIP B2BUAs can do whatever they want!

So origin IP address starts out in the IP header of the original packet but gets pushed from that slot when the proxy constructs the onward IP packet to the server.  For it to reach the server, it has to be placed somewhere else in the onward packet, restoring the lost metadata.
[Med] The client agreed to send packets with its source IP address (which mean consent). Why the proxy would need to an extra channel to get consent for relaying the source IP address to a server?

Had it been present in the packet as header value in the HTTP exchange, it would not have been stripped by normal operation.  There proxy operation forwarding it on would be simply preserving it.
[Med] This is another question: whether the same or distinct channel can be used to communicate the SAME data that was present in the initial packet issued by a host.

•         An address sharing device, under for example DS-Lite (RFC6333), that inserts the source IPv6 prefix in the TCP HOST_ID option (RFC7974) is not RESTORING any data. The content of that TCP option is already visible in the packet sent by the host.
I agree with the IESG analysis of RFC7974.  It does restore information by taking information which normal operation would have elided and restores it.
[Med] The  implication of what you are saying here is that proxies are good because they hide the source IP addresses of host!

•         Service Function Chaining WG (https://datatracker.ietf.org/wg/sfc/about/) is defining an architecture to communicate metadata by on-path devices; that metadata is inserted at the network side. Border nodes will make sure that data is stripped before forwarding packets to the ultimate destinations. The metadata can be a subscriber-id, a policy-id, etc.

I'm afraid I don't have enough context to know what border node operations are here, so this is difficult for me to comment on, but I hope the two examples above clarify my thinking.
[Med] A BN is defined here : https://tools.ietf.org/html/rfc7665#section-4.4

If the data is taken from a portion of the packet that would not normally be forwarded to an upstream host and added to a portion that is forwarded to an upstream host, then the device adding the data back in should know it is a restoration.
[Med] That definition is not trivial as mentioned above. I would use “preserve” or “maintain” rather than “restore”.

Brian Trammell has an ever growing list of side channels attacks, and this document doesn't mean to cover that entire ground.  It's advice for protocol designers on what the privacy implications are of making the choice to use network elements to carry this data.

This text claims that providing data by the endpoint ensures a “consistent availability” of that information. This is broken for a multi-homed host that uses for example Forward-For header: Obviously, the content of the header if injected by the endpoint will depend on the path.

If the endpoint sends the data, data will be consistently available in that header.  The data changes, of course.
[Med] I’m not sure to follow you here. What is meant by “consistent availability” then? Do you mean the same channel/procedure to communicate the information? Or “consistent data”?

I did consider it, but I continue to believe that it moves the needle too far into simple server preference.  I retained the original PSAP language in -07 as a result.
[Med] emergency is only an example ; other services may exist that impose the same trust model.

I also added a note about your extensive review.  While you and I clearly have some differences of view, the document has gotten better from your engagement with it, and I appreciate your efforts.
[Med] I reviewed the -07. Although it is better compared to -05, I still don’t think it is ready to be published as it is. Thank you for your effort.
regards,
Ted

---

From: Ted Hardie <[email-masked]>
Date: Mon, 6 Mar 2017 09:14:29 -0800

Hi Mohamed,

Replies in-line.

On Mon, Mar 6, 2017 at 1:48 AM, <[email-masked]> wrote:

> [Med] Then, this needs to be defined in the document. I naively assumed
> that “restored” is used to mean any piece of information that the client
> does not want to insert in a packet, but an on-path device decides to
> inject it despite there is no consent from the client.
>
What you are describing is more about “maintaining” or “preserving”
> information not restoring it.
>
>
>
The common uses of restore in English all focus on putting something back
that has been lost, so I believe restore is better than "maintain" or
"preserve", which imply something is being carried forward as-is, rather
than being put back after loss.

>   If the information is present as metadata in the packet sent to the
> proxy but would be absent as metadata under normal operation of the proxy,
> adding it back in somewhere else restores the metadata.
>
> [Med] “normal operation of proxy” is not a standard. A “normal operation
> of proxy” would be to maintain the information sent by the client when
> relaying it to the server. I’m sure you know for instance that SIP B2BUAs
> can do whatever they want!
>

You're right that the normal operation of a proxy is not a standard, and I
should have said "the normal operation of the protocols used by a proxy".
If the action of the proxy is to start a new TCP connection to an origin
server, for example, the normal operation of TCP is to use the initiator's
IP address.  The loses the IP address of the querying host is implied by
that normal operation(in other words, it elides metadata about any client
that caused this new TCP connection to be createD).

>
>
> So origin IP address starts out in the IP header of the original packet
> but gets pushed from that slot when the proxy constructs the onward IP
> packet to the server.  For it to reach the server, it has to be placed
> somewhere else in the onward packet, restoring the lost metadata.
>
> [Med] The client agreed to send packets with its source IP address (which
> mean consent). Why the proxy would need to an extra channel to get consent
> for relaying the source IP address to a server?
>
>
>

Because the client agreed to send packets to the proxy by putting it in the
destination, and did not agree to general disclosure; you can't infer
onward consent.

> [Med] This is another question: whether the same or distinct channel can
> be used to communicate the SAME data that was present in the initial packet
> issued by a host.
>
>

That depends on the nature of the channel.  Obviously, if you set the
origin clients IP address as the source address, you're going to get a
different result from that spoofing than putting it in a client subnet EDNS
option or forwarded-for header.

> [Med] The  implication of what you are saying here is that proxies are
> good because they hide the source IP addresses of host!
>
>
>
Aggregating proxies can have a positive privacy impact, yes.  An observer
seeing traffic from an aggregating proxy to sensitive-topic.example.com
knows only that some user behind that proxy is looking for information on
sensitive-topic.  To know which user, the observer must have either
suborned the proxy or have a way of observing traffic between hosts and the
proxy.  Both are more expensive and at higher risk of discovery than a
simple tap near sensitive-topic.example.com.

> [Med] That definition is not trivial as mentioned above. I would use
> “preserve” or “maintain” rather than “restore”.
>
> Please see above.  "Restore" is closer, in my opinion, than either
preserve or maintain.

>
>
> If the endpoint sends the data, data will be consistently available in
> that header.  The data changes, of course.
>
> [Med] I’m not sure to follow you here. What is meant by “consistent
> availability” then? Do you mean the same channel/procedure to communicate
> the information? Or “consistent data”?
>
>

I mean that if you define a protocol such that a well-formed message from
the client has the data the server needs, it will be consistently
available.  If you rely on intermediate network devices to add the data, it
may not be available if there is not cooperating network device on path
(e.g. if the DNS resolver does not support the relevant EDNS0 option).

> [Med] emergency is only an example ; other services may exist that impose

I think there is a qualitative difference between situations in which the
resources at risk are human lives and those where they are host resources.
That's why the carve out was limited in the GEOPRIV case.

> [Med] I reviewed the -07. Although it is better compared to -05, I still
> don’t think it is ready to be published as it is. Thank you for your effort.
>
And thank you for yours,

regards,

Ted

---

From: <[email-masked]>
Date: Tue, 7 Mar 2017 07:31:56 +0000

Hi Ted,

Thank you for the answers.

Please see inline.

Cheers,
Med

Envoyé : lundi 6 mars 2017 18:14

Hi Mohamed,
Replies in-line.

On Mon, Mar 6, 2017 at 1:48 AM, <[email-masked]<mailto:[email-masked]>> wrote:

•         A Forward-For header inserted by a proxy does not restore any data; it does only reveal data that is already present in the packet issued by the client itself.
That's what restore means here.
[Med] Then, this needs to be defined in the document. I naively assumed that “restored” is used to mean any piece of information that the client does not want to insert in a packet, but an on-path device decides to inject it despite there is no consent from the client.
What you are describing is more about “maintaining” or “preserving” information not restoring it.

The common uses of restore in English all focus on putting something back that has been lost,
[Med] But that information is not lost for an on-path device that encapsulates a packet in another one (so the inner header is still carrying the source IP address) or the one that supplies the original source IP address as a metadata when source IP address/port rewriting is required. The notion of “putting back” does not make sense to me because we are not dealing with the internal processing of a packet within an on-path device, but we only focus on the external behavior. This is exactly the role of “via” headers for SIP proxies; when there is a mismatch the received tag is completed with the visible source address.

so I believe restore is better than "maintain" or "preserve", which imply something is being carried forward as-is, rather than being put back after loss.
[Med] Please see above. Because we don’t have a standard behavior of an on-path device (proxy, tunnel-endpoint.), I seems weird to me to say that a proxy that preserves the source IP address is “putting pack an information that is lost”.

You're right that the normal operation of a proxy is not a standard, and I should have said "the normal operation of the protocols used by a proxy".
[Med] This is much better, but still not sufficient. On-path devices that manipulate packets may not be a “protocol-specific proxy”: tunnel endpoint (e.g., LISP), CGN (NAT64, NAT44, DS-Lite), MAP-E BR, etc.

  If the action of the proxy is to start a new TCP connection to an origin server, for example, the normal operation of TCP is to use the initiator's IP address.
[Med] This is protocol-specific. I can provide an example of a proxy behavior that relays the source IP address/port as part of its normal operation: http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
  - TCP/IPv4 :
      "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n"
    => 5 + 1 + 4 + 1 + 15 + 1 + 15 + 1 + 5 + 1 + 5 + 2 = 56 chars

  - TCP/IPv6 :
      "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n"
    => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = 104 chars

  The loses the IP address of the querying host is implied by that normal operation(in other words, it elides metadata about any client that caused this new TCP connection to be createD).
[Med] This makes sense if losing the original IP address is an intended propriety of the proxy. But this cannot be a generalized proxy behavior (see the example above).

Because the client agreed to send packets to the proxy by putting it in the destination
[Med] The client is not even aware that proxy exists on the path! Packets are sent to the ultimate server’s address, not the one of the proxy. Even for SOME cases where packets are sent explicitly to the proxy (e.g., SOCKS proxy), a state is already in place to graft the outgoing packets to a binding context involving the destination server.

, and did not agree to general disclosure; you can't infer onward consent.
[Med] Hmm…I’m afraid this conclusion is not technically backed, e.g.,
* A client that sends packets to a server located on the Internet is NOT necessarily aware that a proxy is solicited in forwarding path. Packets are sent using the server’s IP address.
* The client and proxy may be owned by the same administrative entity (case of enterprise networks). That entity is responsible for ensure which information the proxy needs to leak.
* The proxy and the server may be owned by the same administrative entity (content provider). Supplying data by a proxy to the server, based on the content of a packet received from a host, does not induce a privacy concern here because the proxy and the server owned by the same entity.

That depends on the nature of the channel.  Obviously, if you set the origin clients IP address as the source address, you're going to get a different result from that spoofing than putting it in a client subnet EDNS option or forwarded-for header.
[Med] Agree.

Aggregating proxies can have a positive privacy impact, yes.  An observer seeing traffic from an aggregating proxy to sensitive-topic.example.com<http://sensitive-topic.example.com> knows only that some user behind that proxy is looking for information on sensitive-topic.  To know which user, the observer must have either suborned the proxy or have a way of observing traffic between hosts and the proxy.  Both are more expensive and at higher risk of discovery than a simple tap near sensitive-topic.example.com<http://sensitive-topic.example.com>.

[Med] The main point here is that, even in the presence of an aggregating proxy, a server can demux users by correlating various information leaked at the application layer (e.g., https://panopticlick.eff.org/). Tracking those users when they change their source IP address is possible in this case, too.

If the data is taken from a portion of the packet that would not normally be forwarded to an upstream host and added to a portion that is forwarded to an upstream host, then the device adding the data back in should know it is a restoration.
[Med] That definition is not trivial as mentioned above. I would use “preserve” or “maintain” rather than “restore”.
Please see above.  "Restore" is closer, in my opinion, than either preserve or maintain.

I mean that if you define a protocol such that a well-formed message from the client has the data the server needs, it will be consistently available.  If you rely on intermediate network devices to add the data, it may not be available if there is not cooperating network device on path (e.g. if the DNS resolver does not support the relevant EDNS0 option).

[Med] Thank you. Please clarify this in the draft. I had troubles to parse what you meant by “consistent availability”. That’s said, there might be also “not cooperating on-path devices” that may strip/alter the content of client supplied data (easy for HTTP for example).

I think there is a qualitative difference between situations in which the resources at risk are human lives and those where they are host resources.
[Med] I agree with you as an individual. But, it is not up to us to mandate this condition for executing services. It is up to the (protocol) designers/service providers to decide what is critical/key for their service operation.
  That's why the carve out was limited in the GEOPRIV case.
[Med] GEOPRIV is not the only protocol/service that is concerned with human lives, we can consider vehicular networking that trust the information shared by the infrastructure. I prefer neutral wording that cites emergency as an example.

regards,
Ted

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Mar 2017 12:07:38 +0000

Hi Med and Ted,

Thanks for the discussion. My conclusion from that is that
the best next step will be to continue with IESG evaluation.
Progressing this draft had fairly clear support in earlier
discussions on the saag list and in saag meetings, so it
may be Med that you're just in the rough - given the limited
comment during LC, I'd say getting the IESG to evaluate
this will be the easiest way to figure that out. And as an
outgoing AD, I'd much prefer to try get this sorted before
I'm done rather than leaving it to Kathleen or Eric to pick
up later. (Though we can go there if needed.) Anyway, I
think logistically it makes sense to keep this on the March
16th IESG telechat and see where we go from there. I'll
include a pointer to the archive for this mail so other
ADs can easily find this discussion.

As to the content of the discussion, I think Ted has answered
your comments, even though you and he haven't reached full
agreement on all topics. For me it seems like the remaining
areas of discussion were:-

- language around "restore" or not (fwiw I agree with Ted's
  take on that term)

- "consent" - actually it may be best to just remove the two
  uses of that term entirely - the term is fairly legally
  "loaded" and I'm not sure it's needed for this design
  advice anyway - if we can figure a way to rephrase those
  bits that may be an improvement worth making

I'll start the iesg evaluation process for -07 shortly.

Cheers,
S.

PS: Sorry if I've missed anything else that is outstanding.
The form of (not really;-) quoting earlier messages used makes
it very hard to follow the conversation over more than two
emails.

On 07/03/17 07:31, [email-masked] wrote:
> Cheers, Med
> De : Ted Hardie [mailto:[email-masked]] Envoyé : lundi 6 mars
> 2017 18:14 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked];
> [email-masked] Objet : Re: Last
> Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design
> considerations for Metadata Insertion) to Informational RFC
> 
> Hi Mohamed, Replies in-line.
> 
> 
> On Mon, Mar 6, 2017 at 1:48 AM,
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> 
> 
> •         A Forward-For header inserted by a proxy does not restore
> any data; it does only reveal data that is already present in the
> packet issued by the client itself. That's what restore means here. 
> [Med] Then, this needs to be defined in the document. I naively
> assumed that “restored” is used to mean any piece of information
> that the client does not want to insert in a packet, but an on-path
> device decides to inject it despite there is no consent from the
> client. What you are describing is more about “maintaining” or
> “preserving” information not restoring it.
> 
> The common uses of restore in English all focus on putting something
> back that has been lost, [Med] But that information is not lost for
> an on-path device that encapsulates a packet in another one (so the
> inner header is still carrying the source IP address) or the one that
> supplies the original source IP address as a metadata when source IP
> address/port rewriting is required. The notion of “putting back”
> does not make sense to me because we are not dealing with the
> internal processing of a packet within an on-path device, but we only
> focus on the external behavior. This is exactly the role of “via”
> headers for SIP proxies; when there is a mismatch the received tag is
> completed with the visible source address.
> 
> so I believe restore is better than "maintain" or "preserve", which
> imply something is being carried forward as-is, rather than being put
> back after loss. [Med] Please see above. Because we don’t have a
> standard behavior of an on-path device (proxy, tunnel-endpoint.), I
> seems weird to me to say that a proxy that preserves the source IP
> address is “putting pack an information that is lost”.
> 
> 
> proxy but would be absent as metadata under normal operation of the
> proxy, adding it back in somewhere else restores the metadata. [Med]
> “normal operation of proxy” is not a standard. A “normal
> operation of proxy” would be to maintain the information sent by
> the client when relaying it to the server. I’m sure you know for
> instance that SIP B2BUAs can do whatever they want!
> 
> You're right that the normal operation of a proxy is not a standard,
> and I should have said "the normal operation of the protocols used by
> a proxy". [Med] This is much better, but still not sufficient.
> On-path devices that manipulate packets may not be a
> “protocol-specific proxy”: tunnel endpoint (e.g., LISP), CGN
> (NAT64, NAT44, DS-Lite), MAP-E BR, etc.
> 
> If the action of the proxy is to start a new TCP connection to an
> origin server, for example, the normal operation of TCP is to use the
> initiator's IP address. [Med] This is protocol-specific. I can
> provide an example of a proxy behavior that relays the source IP
> address/port as part of its normal operation:
> http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt - TCP/IPv4
> : "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n" => 5 +
> 1 + 4 + 1 + 15 + 1 + 15 + 1 + 5 + 1 + 5 + 2 = 56 chars
> 
> - TCP/IPv6 : "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535
> 65535\r\n" => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = 104
> chars
> 
> 
> The loses the IP address of the querying host is implied by that
> normal operation(in other words, it elides metadata about any client
> that caused this new TCP connection to be createD). [Med] This makes
> sense if losing the original IP address is an intended propriety of
> the proxy. But this cannot be a generalized proxy behavior (see the
> example above).
> 
> So origin IP address starts out in the IP header of the original
> packet but gets pushed from that slot when the proxy constructs the
> onward IP packet to the server.  For it to reach the server, it has
> to be placed somewhere else in the onward packet, restoring the lost
> metadata. [Med] The client agreed to send packets with its source IP
> address (which mean consent). Why the proxy would need to an extra
> channel to get consent for relaying the source IP address to a
> server?
> 
> 
> Because the client agreed to send packets to the proxy by putting it
> in the destination [Med] The client is not even aware that proxy
> exists on the path! Packets are sent to the ultimate server’s
> address, not the one of the proxy. Even for SOME cases where packets
> are sent explicitly to the proxy (e.g., SOCKS proxy), a state is
> already in place to graft the outgoing packets to a binding context
> involving the destination server.
> 
> , and did not agree to general disclosure; you can't infer onward
> consent. [Med] Hmm…I’m afraid this conclusion is not technically
> backed, e.g., * A client that sends packets to a server located on
> the Internet is NOT necessarily aware that a proxy is solicited in
> forwarding path. Packets are sent using the server’s IP address. *
> The client and proxy may be owned by the same administrative entity
> (case of enterprise networks). That entity is responsible for ensure
> which information the proxy needs to leak. * The proxy and the server
> may be owned by the same administrative entity (content provider).
> Supplying data by a proxy to the server, based on the content of a
> packet received from a host, does not induce a privacy concern here
> because the proxy and the server owned by the same entity.
> 
> Had it been present in the packet as header value in the HTTP
> exchange, it would not have been stripped by normal operation.  There
> proxy operation forwarding it on would be simply preserving it. [Med]
> This is another question: whether the same or distinct channel can be
> used to communicate the SAME data that was present in the initial
> packet issued by a host.
> 
> 
> origin clients IP address as the source address, you're going to get
> a different result from that spoofing than putting it in a client
> subnet EDNS option or forwarded-for header. [Med] Agree.
> 
> 
> •         An address sharing device, under for example DS-Lite
> (RFC6333), that inserts the source IPv6 prefix in the TCP HOST_ID
> option (RFC7974) is not RESTORING any data. The content of that TCP
> option is already visible in the packet sent by the host. I agree
> with the IESG analysis of RFC7974.  It does restore information by
> taking information which normal operation would have elided and
> restores it. [Med] The  implication of what you are saying here is
> that proxies are good because they hide the source IP addresses of
> host!
> 
> 
> Aggregating proxies can have a positive privacy impact, yes.  An
> observer seeing traffic from an aggregating proxy to
> sensitive-topic.example.com<http://sensitive-topic.example.com> knows
> only that some user behind that proxy is looking for information on
> suborned the proxy or have a way of observing traffic between hosts
> and the proxy.  Both are more expensive and at higher risk of
> discovery than a simple tap near
> sensitive-topic.example.com<http://sensitive-topic.example.com>.
> 
> [Med] The main point here is that, even in the presence of an
> aggregating proxy, a server can demux users by correlating various
> information leaked at the application layer (e.g.,
> https://panopticlick.eff.org/). Tracking those users when they change
> their source IP address is possible in this case, too.
> 
> 
> If the data is taken from a portion of the packet that would not
> normally be forwarded to an upstream host and added to a portion that
> is forwarded to an upstream host, then the device adding the data
> back in should know it is a restoration. [Med] That definition is not
> trivial as mentioned above. I would use “preserve” or
> “maintain” rather than “restore”. Please see above.
> "Restore" is closer, in my opinion, than either preserve or
> maintain.
> 
> 
> 
> If the endpoint sends the data, data will be consistently available
> in that header.  The data changes, of course. [Med] I’m not sure to
> follow you here. What is meant by “consistent availability” then?
> Do you mean the same channel/procedure to communicate the
> information? Or “consistent data”?
> 
> I mean that if you define a protocol such that a well-formed message
> from the client has the data the server needs, it will be
> consistently available.  If you rely on intermediate network devices
> to add the data, it may not be available if there is not cooperating
> network device on path (e.g. if the DNS resolver does not support the
> relevant EDNS0 option).
> 
> [Med] Thank you. Please clarify this in the draft. I had troubles to
> parse what you meant by “consistent availability”. That’s said,
> there might be also “not cooperating on-path devices” that may
> strip/alter the content of client supplied data (easy for HTTP for
> example).
> 
> 
> 
> [Med] Resources may not be restricted to CPU or disk but may be
> granting access to the service (e.g., download a file when a quota
> per source address is enforced). It can be whatever the servers
> consider to be critical for them; it is up to the taste of the
> service design to characterize it. The NEW wording proposed above is
> technically correct. Please reconsider adding it to the draft.
> 
> 
> 
> I did consider it, but I continue to believe that it moves the needle
> too far into simple server preference.  I retained the original PSAP
> language in -07 as a result. [Med] emergency is only an example ;
> other services may exist that impose the same trust model.
> 
> 
> I think there is a qualitative difference between situations in which
> the resources at risk are human lives and those where they are host
> resources. [Med] I agree with you as an individual. But, it is not up
> to us to mandate this condition for executing services. It is up to
> the (protocol) designers/service providers to decide what is
> critical/key for their service operation. That's why the carve out
> was limited in the GEOPRIV case. [Med] GEOPRIV is not the only
> protocol/service that is concerned with human lives, we can consider
> vehicular networking that trust the information shared by the
> infrastructure. I prefer neutral wording that cites emergency as an
> example.
> 
> 
> I also added a note about your extensive review.  While you and I
> clearly have some differences of view, the document has gotten better
> from your engagement with it, and I appreciate your efforts. [Med] I
> reviewed the -07. Although it is better compared to -05, I still
> don’t think it is ready to be published as it is. Thank you for
> your effort. And thank you for yours, regards, Ted
> 
> regards, Ted
>

---

From: <[email-masked]>
Date: Tue, 7 Mar 2017 13:03:28 +0000

Hi Stephen,

First of all, I really thank Ted for engaging and for making some changes to the document. That's much appreciated. Nevertheless, I still think the document isn't ready to be published as it is with an IETF consensus.   

The point you mentioned about "restore" is one of the disagreements, but not the only one. I hope the discussion will continue with Ted to fix this in the document.

I checked the SAAG archives, but, unless I'm mistaken, I failed to find a technical discussion about the content of the draft or a thread about "fairly clear support" to "progressing this draft". 

I don't think there is a rush to publish the document. Do we?

Cheers,
Med 

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : mardi 7 mars 2017 13:08
> À : BOUCADAIR Mohamed IMT/OLN; Ted Hardie
> Cc : [email-masked]; [email-masked]
> Objet : Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt>
> (Design considerations for Metadata Insertion) to Informational RFC
> 
> 
> Hi Med and Ted,
> 
> > De : Ted Hardie [mailto:[email-masked]] EnvoyÃ© : lundi 6 mars
> > 2017 18:14 Ã€ : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked];
> > â€¢         A Forward-For header inserted by a proxy does not restore
> > assumed that â€œrestoredâ€ is used to mean any piece of information
> > client. What you are describing is more about â€œmaintainingâ€ or
> > â€œpreservingâ€ information not restoring it.
> >
> > address/port rewriting is required. The notion of â€œputting backâ€
> > focus on the external behavior. This is exactly the role of â€œviaâ€
> > back after loss. [Med] Please see above. Because we donâ€™t have a
> > address is â€œputting pack an information that is lostâ€.
> >
> >
> > â€œnormal operation of proxyâ€ is not a standard. A â€œnormal
> > operation of proxyâ€ would be to maintain the information sent by
> > the client when relaying it to the server. Iâ€™m sure you know for
> > â€œprotocol-specific proxyâ€: tunnel endpoint (e.g., LISP), CGN
> > exists on the path! Packets are sent to the ultimate serverâ€™s
> > consent. [Med] Hmmâ€¦Iâ€™m afraid this conclusion is not technically
> > forwarding path. Packets are sent using the serverâ€™s IP address. *
> > â€¢         An address sharing device, under for example DS-Lite
> > trivial as mentioned above. I would use â€œpreserveâ€ or
> > â€œmaintainâ€ rather than â€œrestoreâ€. Please see above.
> > in that header.  The data changes, of course. [Med] Iâ€™m not sure to
> > follow you here. What is meant by â€œconsistent availabilityâ€ then?
> > information? Or â€œconsistent dataâ€?
> >
> > parse what you meant by â€œconsistent availabilityâ€. Thatâ€™s said,
> > there might be also â€œnot cooperating on-path devicesâ€ that may
> > donâ€™t think it is ready to be published as it is. Thank you for

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Mar 2017 13:07:50 +0000

Hiya,

On 07/03/17 13:03, [email-masked] wrote:
> Hi Stephen,
> 
> First of all, I really thank Ted for engaging and for making some
> changes to the document. That's much appreciated. Nevertheless, I
> still think the document isn't ready to be published as it is with an
> IETF consensus.

That's clear yes.

> 
> The point you mentioned about "restore" is one of the disagreements,
> but not the only one. I hope the discussion will continue with Ted to
> fix this in the document.

I mentioned two points of disagreement. I didn't see others
that aren't related to those. (I did see more text, but it
seemed to be the same discussion.)

> 
> I checked the SAAG archives, but, unless I'm mistaken, I failed to
> find a technical discussion about the content of the draft or a
> thread about "fairly clear support" to "progressing this draft".

It was entwined a bit with the 3552bis discussion. Don't have time
at the 'mo to dig out references but happy to do that later.

> I don't think there is a rush to publish the document. Do we?

Rush? No. But it is IMO timely and I would like to see it done
before I finish as an AD. Call that a rush if you like but I
think we're our usual sedate selves mostly with this one:-)

Cheers,
S.

> 
> Cheers, Med
> 
>> -----Message d'origine----- DeÂ : Stephen Farrell
>> [mailto:[email-masked]] EnvoyÃ©Â : mardi 7 mars 2017
>> 13:08 Ã€Â : BOUCADAIR Mohamed IMT/OLN; Ted Hardie CcÂ :
>> [email-masked]; [email-masked] 
>> ObjetÂ : Re: Last Call:
>> <draft-hardie-privsec-metadata-insertion-05.txt> (Design
>> Thanks for the discussion. My conclusion from that is that the best
>> next step will be to continue with IESG evaluation. Progressing
>> this draft had fairly clear support in earlier discussions on the
>> saag list and in saag meetings, so it may be Med that you're just
>> in the rough - given the limited comment during LC, I'd say getting
>> the IESG to evaluate this will be the easiest way to figure that
>> out. And as an outgoing AD, I'd much prefer to try get this sorted
>> before I'm done rather than leaving it to Kathleen or Eric to pick 
>> up later. (Though we can go there if needed.) Anyway, I think
>> logistically it makes sense to keep this on the March 16th IESG
>> telechat and see where we go from there. I'll include a pointer to
>> the archive for this mail so other ADs can easily find this
>> discussion.
>> 
>> As to the content of the discussion, I think Ted has answered your
>> comments, even though you and he haven't reached full agreement on
>> all topics. For me it seems like the remaining areas of discussion
>> were:-
>> 
>> - language around "restore" or not (fwiw I agree with Ted's take on
>> that term)
>> 
>> - "consent" - actually it may be best to just remove the two uses
>> of that term entirely - the term is fairly legally "loaded" and I'm
>> not sure it's needed for this design advice anyway - if we can
>> figure a way to rephrase those bits that may be an improvement
>> worth making
>> 
>> Cheers, S.
>> PS: Sorry if I've missed anything else that is outstanding. The
>> form of (not really;-) quoting earlier messages used makes it very
>> hard to follow the conversation over more than two emails.
>> 
>>> De : Ted Hardie [mailto:[email-masked]] EnvoyÃƒÂ© : lundi 6
>>> mars 2017 18:14 Ãƒâ‚¬ : BOUCADAIR Mohamed IMT/OLN Cc :
>>> [email-masked]; [email-masked]
>>> Objet : Re: Last Call:
>>> <draft-hardie-privsec-metadata-insertion-05.txt> (Design 
wrote:
>>> 
>>> 
>>> Ã¢â‚¬Â¢         A Forward-For header inserted by a proxy does not
>>> restore any data; it does only reveal data that is already
>>> present in the packet issued by the client itself. That's what
>>> restore means here. [Med] Then, this needs to be defined in the
>>> document. I naively assumed that Ã¢â‚¬Å“restoredÃ¢â‚¬Â is used
>>> to mean any piece of information that the client does not want to
>>> insert in a packet, but an on-path device decides to inject it
>>> despite there is no consent from the client. What you are
>>> describing is more about Ã¢â‚¬Å“maintainingÃ¢â‚¬Â or 
>>> Ã¢â‚¬Å“preservingÃ¢â‚¬Â information not restoring it.
>>> 
>>> The common uses of restore in English all focus on putting
>>> something back that has been lost, [Med] But that information is
>>> not lost for an on-path device that encapsulates a packet in
>>> another one (so the inner header is still carrying the source IP
>>> address) or the one that supplies the original source IP address
>>> as a metadata when source IP address/port rewriting is required.
>>> The notion of Ã¢â‚¬Å“putting backÃ¢â‚¬Â does not make sense to
>>> me because we are not dealing with the internal processing of a
>>> packet within an on-path device, but we only focus on the
>>> external behavior. This is exactly the role of Ã¢â‚¬Å“viaÃ¢â‚¬Â 
>>> headers for SIP proxies; when there is a mismatch the received
>>> tag is completed with the visible source address.
>>> 
>>> so I believe restore is better than "maintain" or "preserve",
>>> which imply something is being carried forward as-is, rather than
>>> being put back after loss. [Med] Please see above. Because we
>>> donÃ¢â‚¬â„¢t have a standard behavior of an on-path device
>>> (proxy, tunnel-endpoint.), I seems weird to me to say that a
>>> proxy that preserves the source IP address is Ã¢â‚¬Å“putting pack
>>> an information that is lostÃ¢â‚¬Â.
>>> 
>>> 
>>> If the information is present as metadata in the packet sent to
>>> the proxy but would be absent as metadata under normal operation
>>> of the proxy, adding it back in somewhere else restores the
>>> metadata. [Med] Ã¢â‚¬Å“normal operation of proxyÃ¢â‚¬Â is not a
>>> standard. A Ã¢â‚¬Å“normal operation of proxyÃ¢â‚¬Â would be to
>>> maintain the information sent by the client when relaying it to
>>> the server. IÃ¢â‚¬â„¢m sure you know for instance that SIP B2BUAs
>>> You're right that the normal operation of a proxy is not a
>>> standard, and I should have said "the normal operation of the
>>> protocols used by a proxy". [Med] This is much better, but still
>>> not sufficient. On-path devices that manipulate packets may not
>>> be a Ã¢â‚¬Å“protocol-specific proxyÃ¢â‚¬Â: tunnel endpoint
>>> (e.g., LISP), CGN (NAT64, NAT44, DS-Lite), MAP-E BR, etc.
>>> 
>>> If the action of the proxy is to start a new TCP connection to
>>> an origin server, for example, the normal operation of TCP is to
>>> use the initiator's IP address. [Med] This is protocol-specific.
>>> I can provide an example of a proxy behavior that relays the
>>> source IP address/port as part of its normal operation: 
>>> http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt -
>>> TCP/IPv4 : "PROXY TCP4 255.255.255.255 255.255.255.255 65535
>>> 65535\r\n" => 5 + 1 + 4 + 1 + 15 + 1 + 15 + 1 + 5 + 1 + 5 + 2 =
>>> 56 chars
>>> 
>>> 65535\r\n" => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 =
>>> 104 chars
>>> 
>>> 
>>> normal operation(in other words, it elides metadata about any
>>> client that caused this new TCP connection to be createD). [Med]
>>> This makes sense if losing the original IP address is an intended
>>> propriety of the proxy. But this cannot be a generalized proxy
>>> behavior (see the example above).
>>> 
>>> packet but gets pushed from that slot when the proxy constructs
>>> the onward IP packet to the server.  For it to reach the server,
>>> it has to be placed somewhere else in the onward packet,
>>> restoring the lost metadata. [Med] The client agreed to send
>>> packets with its source IP address (which mean consent). Why the
>>> proxy would need to an extra channel to get consent for relaying
>>> the source IP address to a server?
>>> 
>>> 
>>> Because the client agreed to send packets to the proxy by putting
>>> it in the destination [Med] The client is not even aware that
>>> proxy exists on the path! Packets are sent to the ultimate
>>> serverÃ¢â‚¬â„¢s address, not the one of the proxy. Even for SOME
>>> cases where packets are sent explicitly to the proxy (e.g., SOCKS
>>> proxy), a state is already in place to graft the outgoing packets
>>> to a binding context involving the destination server.
>>> 
>>> , and did not agree to general disclosure; you can't infer
>>> onward consent. [Med] HmmÃ¢â‚¬Â¦IÃ¢â‚¬â„¢m afraid this conclusion
>>> is not technically backed, e.g., * A client that sends packets to
>>> a server located on the Internet is NOT necessarily aware that a
>>> proxy is solicited in forwarding path. Packets are sent using the
>>> serverÃ¢â‚¬â„¢s IP address. * The client and proxy may be owned
>>> by the same administrative entity (case of enterprise networks).
>>> That entity is responsible for ensure which information the proxy
>>> needs to leak. * The proxy and the server may be owned by the
>>> same administrative entity (content provider). Supplying data by
>>> a proxy to the server, based on the content of a packet received
>>> from a host, does not induce a privacy concern here because the
>>> proxy and the server owned by the same entity.
>>> 
>>> exchange, it would not have been stripped by normal operation.
>>> There proxy operation forwarding it on would be simply preserving
>>> it. [Med] This is another question: whether the same or distinct
>>> channel can be used to communicate the SAME data that was present
>>> in the initial packet issued by a host.
>>> 
>>> 
>>> That depends on the nature of the channel.  Obviously, if you set
>>> the origin clients IP address as the source address, you're going
>>> to get a different result from that spoofing than putting it in a
>>> client subnet EDNS option or forwarded-for header. [Med] Agree.
>>> 
>>> 
>>> Ã¢â‚¬Â¢         An address sharing device, under for example
>>> DS-Lite (RFC6333), that inserts the source IPv6 prefix in the TCP
>>> HOST_ID option (RFC7974) is not RESTORING any data. The content
>>> of that TCP option is already visible in the packet sent by the
>>> host. I agree with the IESG analysis of RFC7974.  It does restore
>>> information by taking information which normal operation would
>>> have elided and restores it. [Med] The  implication of what you
>>> are saying here is that proxies are good because they hide the
>>> source IP addresses of host!
>>> 
>>> 
>>> sensitive-topic.example.com<http://sensitive-topic.example.com>
>>> knows only that some user behind that proxy is looking for
>>> information on sensitive-topic.  To know which user, the observer
>>> must have either suborned the proxy or have a way of observing
>>> traffic between hosts and the proxy.  Both are more expensive and
>>> at higher risk of discovery than a simple tap near 
>>> aggregating proxy, a server can demux users by correlating
>>> various information leaked at the application layer (e.g., 
>>> https://panopticlick.eff.org/). Tracking those users when they
>>> change their source IP address is possible in this case, too.
>>> 
>>> 
>>> normally be forwarded to an upstream host and added to a portion
>>> that is forwarded to an upstream host, then the device adding the
>>> data back in should know it is a restoration. [Med] That
>>> definition is not trivial as mentioned above. I would use
>>> Ã¢â‚¬Å“preserveÃ¢â‚¬Â or Ã¢â‚¬Å“maintainÃ¢â‚¬Â rather than
>>> Ã¢â‚¬Å“restoreÃ¢â‚¬Â. Please see above. "Restore" is closer, in
>>> my opinion, than either preserve or maintain.
>>> 
>>> 
>>> 
>>> If the endpoint sends the data, data will be consistently
>>> available in that header.  The data changes, of course. [Med]
>>> IÃ¢â‚¬â„¢m not sure to follow you here. What is meant by
>>> Ã¢â‚¬Å“consistent availabilityÃ¢â‚¬Â then? Do you mean the same
>>> channel/procedure to communicate the information? Or
>>> Ã¢â‚¬Å“consistent dataÃ¢â‚¬Â?
>>> 
>>> I mean that if you define a protocol such that a well-formed
>>> message from the client has the data the server needs, it will
>>> be consistently available.  If you rely on intermediate network
>>> devices to add the data, it may not be available if there is not
>>> cooperating network device on path (e.g. if the DNS resolver does
>>> not support the relevant EDNS0 option).
>>> 
>>> [Med] Thank you. Please clarify this in the draft. I had troubles
>>> to parse what you meant by Ã¢â‚¬Å“consistent availabilityÃ¢â‚¬Â.
>>> ThatÃ¢â‚¬â„¢s said, there might be also Ã¢â‚¬Å“not cooperating
>>> on-path devicesÃ¢â‚¬Â that may strip/alter the content of client
>>> supplied data (easy for HTTP for example).
>>> 
>>> 
>>> 
>>> granting access to the service (e.g., download a file when a
>>> quota per source address is enforced). It can be whatever the
>>> servers consider to be critical for them; it is up to the taste
>>> of the service design to characterize it. The NEW wording
>>> proposed above is technically correct. Please reconsider adding
>>> it to the draft.
>>> 
>>> 
>>> 
>>> I did consider it, but I continue to believe that it moves the
>>> needle too far into simple server preference.  I retained the
>>> original PSAP language in -07 as a result. [Med] emergency is
>>> only an example ; other services may exist that impose the same
>>> trust model.
>>> 
>>> 
>>> I think there is a qualitative difference between situations in
>>> which the resources at risk are human lives and those where they
>>> are host resources. [Med] I agree with you as an individual. But,
>>> it is not up to us to mandate this condition for executing
>>> services. It is up to the (protocol) designers/service providers
>>> to decide what is critical/key for their service operation.
>>> That's why the carve out was limited in the GEOPRIV case. [Med]
>>> GEOPRIV is not the only protocol/service that is concerned with
>>> human lives, we can consider vehicular networking that trust the
>>> information shared by the infrastructure. I prefer neutral
>>> wording that cites emergency as an example.
>>> 
>>> 
>>> I also added a note about your extensive review.  While you and
>>> I clearly have some differences of view, the document has gotten
>>> better from your engagement with it, and I appreciate your
>>> efforts. [Med] I reviewed the -07. Although it is better compared
>>> to -05, I still donÃ¢â‚¬â„¢t think it is ready to be published as
>>> it is. Thank you for your effort. And thank you for yours,
>>> regards, Ted
>>> 
>>> regards, Ted
>>> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Mar 2017 21:16:10 +0000

> at the 'mo to dig out references but happy to do that later.

Sorry to not have had time earlier, but the saag threads for
this are at [1,2] and a bit of [3]. As I said the meat of this
draft was envisaged to be included in a 3552bis, but the latter
has so far not progressed. (IOW, one needs to hunt down the
discussion a bit, sorry;-)

Cheers,
S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg07452.html
[2] https://www.ietf.org/mail-archive/web/saag/current/msg07096.html
[3] https://www.ietf.org/mail-archive/web/saag/current/msg07117.html