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

[Ted Hardie <[e-mail]>]

Hi Mohamed,

Replies in-line.



On Mon, Mar 6, 2017 at 1:48 AM, <[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, 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
>