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(_dot_)boucadair(_at_)orange(_dot_)com>
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.
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”?
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.
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.
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