Hiya, On 07/03/17 13:03, mohamed.boucadair@xxxxxxxxxx wrote: > Hi Stephen, > > First of all, I really thank Ted for engaging and for making some > changes to the document. That's much appreciated. Nevertheless, I > still think the document isn't ready to be published as it is with an > IETF consensus. That's clear yes. > > The point you mentioned about "restore" is one of the disagreements, > but not the only one. I hope the discussion will continue with Ted to > fix this in the document. I mentioned two points of disagreement. I didn't see others that aren't related to those. (I did see more text, but it seemed to be the same discussion.) > > I checked the SAAG archives, but, unless I'm mistaken, I failed to > find a technical discussion about the content of the draft or a > thread about "fairly clear support" to "progressing this draft". It was entwined a bit with the 3552bis discussion. Don't have time at the 'mo to dig out references but happy to do that later. > > I don't think there is a rush to publish the document. Do we? Rush? No. But it is IMO timely and I would like to see it done before I finish as an AD. Call that a rush if you like but I think we're our usual sedate selves mostly with this one:-) Cheers, S. > > Cheers, Med > >> -----Message d'origine----- De : Stephen Farrell >> [mailto:stephen.farrell@xxxxxxxxx] Envoyé : mardi 7 mars 2017 >> 13:08 À : BOUCADAIR Mohamed IMT/OLN; Ted Hardie Cc : >> draft-hardie-privsec-metadata-insertion@xxxxxxxx; ietf@xxxxxxxx >> Objet : Re: Last Call: >> <draft-hardie-privsec-metadata-insertion-05.txt> (Design >> considerations for Metadata Insertion) to Informational RFC >> >> >> Hi Med and Ted, >> >> Thanks for the discussion. My conclusion from that is that the best >> next step will be to continue with IESG evaluation. Progressing >> this draft had fairly clear support in earlier discussions on the >> saag list and in saag meetings, so it may be Med that you're just >> in the rough - given the limited comment during LC, I'd say getting >> the IESG to evaluate this will be the easiest way to figure that >> out. And as an outgoing AD, I'd much prefer to try get this sorted >> before I'm done rather than leaving it to Kathleen or Eric to pick >> up later. (Though we can go there if needed.) Anyway, I think >> logistically it makes sense to keep this on the March 16th IESG >> telechat and see where we go from there. I'll include a pointer to >> the archive for this mail so other ADs can easily find this >> discussion. >> >> As to the content of the discussion, I think Ted has answered your >> comments, even though you and he haven't reached full agreement on >> all topics. For me it seems like the remaining areas of discussion >> were:- >> >> - language around "restore" or not (fwiw I agree with Ted's take on >> that term) >> >> - "consent" - actually it may be best to just remove the two uses >> of that term entirely - the term is fairly legally "loaded" and I'm >> not sure it's needed for this design advice anyway - if we can >> figure a way to rephrase those bits that may be an improvement >> worth making >> >> I'll start the iesg evaluation process for -07 shortly. >> >> Cheers, S. >> >> PS: Sorry if I've missed anything else that is outstanding. The >> form of (not really;-) quoting earlier messages used makes it very >> hard to follow the conversation over more than two emails. >> >> On 07/03/17 07:31, mohamed.boucadair@xxxxxxxxxx wrote: >>> Hi Ted, >>> >>> Thank you for the answers. >>> >>> Please see inline. >>> >>> Cheers, Med >>> >>> De : Ted Hardie [mailto:ted.ietf@xxxxxxxxx] Envoyé : lundi 6 >>> mars 2017 18:14 À : BOUCADAIR Mohamed IMT/OLN Cc : >>> ietf@xxxxxxxx; draft-hardie-privsec-metadata-insertion@xxxxxxxx >>> Objet : Re: Last Call: >>> <draft-hardie-privsec-metadata-insertion-05.txt> (Design >>> considerations for Metadata Insertion) to Informational RFC >>> >>> Hi Mohamed, Replies in-line. >>> >>> >>> On Mon, Mar 6, 2017 at 1:48 AM, >>> <mohamed.boucadair@xxxxxxxxxx<mailto:mohamed.boucadair@xxxxxxxxxx>> >>> >>> 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, [Med] But that information is >>> not lost for an on-path device that encapsulates a packet in >>> another one (so the inner header is still carrying the source IP >>> address) or the one that supplies the original source IP address >>> as a metadata when source IP address/port rewriting is required. >>> The notion of “putting back†does not make sense to >>> me because we are not dealing with the internal processing of a >>> packet within an on-path device, but we only focus on the >>> external behavior. This is exactly the role of “via†>>> headers for SIP proxies; when there is a mismatch the received >>> tag is completed with the visible source address. >>> >>> 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. [Med] Please see above. Because we >>> don’t have a standard behavior of an on-path device >>> (proxy, tunnel-endpoint.), I seems weird to me to say that a >>> proxy that preserves the source IP address is “putting pack >>> an information that is lostâ€Â. >>> >>> >>> 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". [Med] This is much better, but still >>> not sufficient. On-path devices that manipulate packets may not >>> be a “protocol-specific proxyâ€Â: tunnel endpoint >>> (e.g., LISP), CGN (NAT64, NAT44, DS-Lite), MAP-E BR, etc. >>> >>> 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. [Med] This is protocol-specific. >>> I can provide an example of a proxy behavior that relays the >>> source IP address/port as part of its normal operation: >>> http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt - >>> TCP/IPv4 : "PROXY TCP4 255.255.255.255 255.255.255.255 65535 >>> 65535\r\n" => 5 + 1 + 4 + 1 + 15 + 1 + 15 + 1 + 5 + 1 + 5 + 2 = >>> 56 chars >>> >>> - TCP/IPv6 : "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 >>> 65535\r\n" => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = >>> 104 chars >>> >>> >>> 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). [Med] >>> This makes sense if losing the original IP address is an intended >>> propriety of the proxy. But this cannot be a generalized proxy >>> behavior (see the example above). >>> >>> 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 [Med] The client is not even aware that >>> proxy exists on the path! Packets are sent to the ultimate >>> server’s address, not the one of the proxy. Even for SOME >>> cases where packets are sent explicitly to the proxy (e.g., SOCKS >>> proxy), a state is already in place to graft the outgoing packets >>> to a binding context involving the destination server. >>> >>> , and did not agree to general disclosure; you can't infer >>> onward consent. [Med] Hmm…I’m afraid this conclusion >>> is not technically backed, e.g., * A client that sends packets to >>> a server located on the Internet is NOT necessarily aware that a >>> proxy is solicited in forwarding path. Packets are sent using the >>> server’s IP address. * The client and proxy may be owned >>> by the same administrative entity (case of enterprise networks). >>> That entity is responsible for ensure which information the proxy >>> needs to leak. * The proxy and the server may be owned by the >>> same administrative entity (content provider). Supplying data by >>> a proxy to the server, based on the content of a packet received >>> from a host, does not induce a privacy concern here because the >>> proxy and the server owned by the same entity. >>> >>> 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. [Med] Agree. >>> >>> >>> • 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<http://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<http://sensitive-topic.example.com>. >>> >>> [Med] The main point here is that, even in the presence of an >>> aggregating proxy, a server can demux users by correlating >>> various information leaked at the application layer (e.g., >>> https://panopticlick.eff.org/). Tracking those users when they >>> change their source IP address is possible in this case, too. >>> >>> >>> 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] Thank you. Please clarify this in the draft. I had troubles >>> to parse what you meant by “consistent availabilityâ€Â. >>> That’s said, there might be also “not cooperating >>> on-path devices†that may strip/alter the content of client >>> supplied data (easy for HTTP for example). >>> >>> >>> >>> [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. [Med] I agree with you as an individual. But, >>> it is not up to us to mandate this condition for executing >>> services. It is up to the (protocol) designers/service providers >>> to decide what is critical/key for their service operation. >>> That's why the carve out was limited in the GEOPRIV case. [Med] >>> GEOPRIV is not the only protocol/service that is concerned with >>> human lives, we can consider vehicular networking that trust the >>> information shared by the infrastructure. I prefer neutral >>> wording that cites emergency as an example. >>> >>> >>> 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 >>> >
Attachment:
signature.asc
Description: OpenPGP digital signature