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

[<[e-mail]>]

Hi Ted,

Thank you for the answers.

Please see inline.

Cheers,
Med

De : Ted Hardie [mailto:[e-mail]]
Envoyé : lundi 6 mars 2017 18:14
À : BOUCADAIR Mohamed IMT/OLN
Cc : [e-mail]; [e-mail]
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, <[e-mail]<mailto:[e-mail]>> 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 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.


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!


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.



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