|
Hi Ted,
Please see inline. Cheers, Med De : Ted Hardie [mailto:ted.ietf@xxxxxxxxx]
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, <mohamed.boucadair@xxxxxxxxxx> 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:
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.
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!
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.
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 |