ietf
[Top] [All Lists]

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

2017-03-06 03:48:30
Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Hardie [mailto:ted(_dot_)ietf(_at_)gmail(_dot_)com]
Envoyé : samedi 4 mars 2017 00:49
À : BOUCADAIR Mohamed IMT/OLN
Cc : ietf(_at_)ietf(_dot_)org; 
draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org
Objet : Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design 
considerations for Metadata Insertion) to Informational RFC

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<mailto: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.
[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.


•         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!



•         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.
[Med] A BN is defined here : https://tools.ietf.org/html/rfc7665#section-4.4


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.
[Med] That definition is not trivial as mentioned above. I would use “preserve” 
or “maintain” rather than “restore”.

(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] 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”?


[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 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
<Prev in Thread] Current Thread [Next in Thread>