Re: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design

Hiya,

On 07/03/17 13:03, mohamed(_dot_)boucadair(_at_)orange(_dot_)com 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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] Envoyé : mardi 7 
> > mars 2017
> > 13:08 À : BOUCADAIR Mohamed IMT/OLN; Ted Hardie Cc :
> > draft-hardie-privsec-metadata-insertion(_at_)ietf(_dot_)org; 
> > ietf(_at_)ietf(_dot_)org 
> > 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(_dot_)boucadair(_at_)orange(_dot_)com wrote:
> > > Hi Ted,
> > >
> > > Thank you for the answers.
> > >
> > > Please see inline.
> > >
> > > Cheers, Med
> > >
> > > De : Ted Hardie [mailto:ted(_dot_)ietf(_at_)gmail(_dot_)com] Envoyé : 
> > > lundi 6
> > > mars 2017 18:14 À : 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, Replies in-line.
> > >
> > >
> > > On Mon, Mar 6, 2017 at 1:48 AM, 
> > > <mohamed(_dot_)boucadair(_at_)orange(_dot_)com<mailto: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, [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

signature.asc
Description: OpenPGP digital signature