|
RE: Last Call: <draft-hardie-privsec-metadata-insertion-05.txt> (Design considerations for Metadata Insertion) to Informational RFC
2017-03-07 07:03:50
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.
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 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".
I don't think there is a rush to publish the document. Do we?
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
|
|