Last Call Review of draft-ietf-tcpm-converters-17
review-ietf-tcpm-converters-17-secdir-lc-huitema-2020-03-02-00

I have reviewed this document as part of the security directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These comments were written
primarily for the benefit of the security area directors. Document editors and WG chairs
should treat these comments just like any other last call comments.

In my opinion, this draft is not ready.

The convert protocol enables clients to use a TCP proxy in an attempt to obtain better
performance than on a direct connection between client and server. It is an alternative
to the SOCKS 5 protocol. The client is configured with IP address of the proxy. Instead
of establishing a direct connection to the server, it will establish a a "convert"
connection to the proxy and proceed with an initial exchange according to the "convert"
protocol. The proxy will then relay the connection to the server.

I have doubts about the security properties of the proposed protocol, and in
particular the weakness of the client authentication and the lack of proxy
authentication. I also have reservations about the amount of quasi-marketing
material in the lengthy introduction sections, and I would like to see more clarity
on the management implications of address-rewriting scenarios.

The client has to trust the proxy to correctly relay the connection, and also to not
abuse its intermediate position and collect metadata or clear text data when relaying
the TCP connections. The proxy has to make sure that it is only used by authorised
clients. From the introduction, we infer that the protocol is meant to be deployed in
constrained network, such as cellular network. The proxy would be deployed by the
operator of the cellular network, which also provides the connectivity to the client.

The privacy and security issues mostly arise when the client is connected to several
networks, such as cellular and Wi-Fi. If the client is solely connected through the
cellular network, the proxy is not obtaining any metadata or clear text data that
would not be already observable by the network, and the proxy can verify that it is
only used by authorized cellular network subscribers. However, the emphasis on
providing TCP multipath between client and proxy let me think that the service is
not restricted to just one network. 

I have some serious doubts about the security properties of the "convert" protocol. 
The protocol operates by configuring the IP address of the proxy in the clients. The
protocol includes the possibility to authenticate a client by sending a clear text
cookie when setting up the connection between client and proxy. This has all the
(lack of) security of authentication with clear text passwords. The cookie can be
observed if the client initiates a connection from outside the network controlled
by the network operator, for example from a Wi-Fi hotspot.

The protocol does not provides means for the client to authenticate the proxy. This
is problematic, because the IP address of the proxy is statically configured. We
have to assume that the proxy addresses can be disccovered by third parties. A
client might try to issue a proxy connection from an unmanaged network. An attacker
might arrange that packets bound to the proxy's IP are delivered to a system under
the attacker's control, allowing the attacker to behave as a man-in-the-middle (MITM).
The attacker could then observe the client's traffic and mount a variety of
attacks.

I think these security issues must be addressed before the draft is published. I
understand that the authors may not want to develop a full security solution for
what is presented as an experiment. Since this experimental draft describes a system
designed for a close environment such as a cellular network, one way to address the
issue would be to limit the use of the proxy service to addresses issued by the
cellular network. This should be detailed in the security section.

The introduction of the draft contains a long explanation describing what the authors perceive as
"the problem". A lot of that looks like marketing material extollling the beauty of inserting
TCP proxies in the communication path. The authors are of course entitled to their opinions, 
but the introduction presents opinions as facts, and publishing that as an RFC seems to assert
that there is IETF consensus on these opinions. This is far from true. The draft justifies
inserting proxies by explaining that it takes a long time for servers and clients to deploy
the latest extensions to TCP, but experience shows that deployment is slowed when old
network proxies do not support these extensions.

Moreover, the draft asserts that the clients can benefit from using TCP extensions before they
are deployed on the server, because the connections between them and the proxy can use these
extensions. This is a rather questionable statement. For example, TCP multipath enables a
connection to survive the loss of one of the paths between client and server by moving traffic
to an alternate path. It is not clear at all that using an alternate path between a client and
a proxy provides the same benefits.

The draft would benefit from either presenting discussing enhancements versus ossification, and
acknowledging that in most cases a direct connection between client and server provides better
services than a connection mediated by a proxy. Or, if the authors do not want to say that, they
could make the draft shorter and easier to read by removing most of the material in section
1 and 2, and simply stating that they present here a protocol for interacting with proxies that
they think is superior to Socks 5. The presentation of the protocol only starts after 20 pages
of introduction. Reducing that long presentation to 3 or 4 pages would markedly improve
readability.

When a client uses a proxy, the server will normally see the TCP connection as originating
from the source address of a proxy. The draft supports that mode of operation, as explained
in sections 4.3 and 4.4. There is a direct security implication here, because the
client cannot be tracked by IP address. On one hand this may improve a client's privacy, but
on the other hand this creates a management problem similar to that encountered with
carrier grade NAT (CGN). In practice, network managers have to be able to identify the client
who originated a specific TCP connection. For CGN, that translates into onerous logging
requirements. This should be discussed in the security section.