Reviewer: Christian Huitema Review result: Not Ready 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
