Hi Mohamed,
Replies in-line.
On Mon, Mar 6, 2017 at 1:48 AM, <mohamed(_dot_)boucadair(_at_)orange(_dot_)com>
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, 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.
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.
· 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
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.
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] 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.
That's why the carve out was limited in the GEOPRIV case.
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