Subject: [Last-Call] Secdir last call review of draft-ietf-tcpm-converters-17

From: Christian Huitema via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 11:35:28 -0800

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.

---

From: <[email-masked]>
Date: Tue, 3 Mar 2020 09:26:55 +0000

Hi Christian,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Christian Huitema via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 2 mars 2020 20:35
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-tcpm-
> [email-masked]
> Objet : Secdir last call review of draft-ietf-tcpm-converters-17
> 
> authentication.

[Med] Proxy authentication are discussed in Section 9.5. 

We also have the following in Section 9:

   Stronger mutual authentication schemes MUST be defined to use the
   Convert Protocol in more open network environments.  One possibility
   is to use TLS to perform mutual authentication between the client and
   the Converter.  That is, use TLS when a Client retrieves a Cookie
   from the Converter and rely on certificate-based client
   authentication, pre-shared key based [RFC4279] or raw public key
   based client authentication [RFC7250] to secure this connection. 

 I also have reservations about the amount of quasi-
> marketing

[Med] I'm afraid to not understand this comment. This section includes technical details. You may refer to, e.g., 
https://datatracker.ietf.org/meeting/105/materials/slides-105-tcpm-0-rtt-converter-poc-over-real-5g-02 

> on the management implications of address-rewriting scenarios.

[Med] Sure. These matters are already discussed in RFC6269. We will add a statement (see also, your last point).

> clients.

[Med] Agree. See the discussion in Section 9.5.

 From the introduction, we infer that the protocol is meant to
> be deployed in

[Med] The assumption is as follows (Section 4.1):

   Transport Converters can be operated by network operators or third
   parties.  Nevertheless, this document focuses on the single
   administrative deployment case where the entity offering the
   connectivity service to a client is also the entity which owns and
   operates the Transport Converter.

Also reiterated in Section 9.1:

   This document assumes that all network attachments are managed by the
   same administrative entity.

> by the network operator, for example from a Wi-Fi hotspot.

[Med] The document discusses what to do when strong mutual authentication is needed (Section 9.2).

> is problematic, because the IP address of the proxy is statically
> configured.

[Med] We don't have such assumption. The document says the following: 

   This document assumes an explicit model in which a client is
   configured with one or a list of Transport Converters (statically or
                                                                     ^^
   through protocols such as [I-D.boucadair-tcpm-dhc-converter]).
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Configuration means are outside the scope of this document.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                   

 We
> The attacker could then observe the client's traffic and mount a

[Med] This is discussed in "Traffic Theft" section. Can you please indicate what we need to say more? Thank you. 

> "the problem".

[Med] The document does not reflect our opinions but those of the WG.

 A lot of that looks like marketing material extolling
> the beauty of inserting
> TCP proxies in the communication path. 

[Med] These are technical arguments, not marketing ones. I'd like we focus on technical argument rather than make assumptions on the intents of the authors/WG. Thank you.  

The authors are of course
> entitled to their opinions,

[Med] Agree that some proxies may be problematic for some extensions but the reality is that ** many extensions *** are not supported by servers as well (MPTCP, TFO, TCPinc, for example). A balanced approach should be followed here, Christian. 

Please note:
* The document uses an explicit mode: that is the network indicates explicitly what is doing.
* The host can control the connections that it wants to be assisted by the networks. 
* The protocol allows to withdraw the converter from the path if an extension requested by the host are supported by the server.    

> a proxy provides the same benefits.

[Med] Let's consider a host connected via two access networks. If a reachability issue is encountered with one of the access networks, the situation would be as follows:

* no convert: the connection won't survive. 
* convert: the connection will survives because an alternate path can be used (even if the server is not MPTCP-capable). 

That is a concrete example that we can benefit from the use of the TCP extension before they are deployed in the server. The same reason apply if the hosts want to aggregate the links or to grab more resources form an alternate access, etc. 

Of course, if the issue is located upstream these access networks (read the Converter), we can't do much if the server is not MPTCP-capable. That's why the protocol is design to encourage the use of an extension over the full path and to withdraw the Converter when it makes sense.

> services than a connection mediated by a proxy. 

[Med] Isn't that already covered by the following:

   This document does not assume that all the traffic is eligible to the
   network-assisted conversion service.  Only a subset of the traffic
   will be forwarded to a Transport Converter according to a set of
   policies.  These policies, and how they are communicated to
   endpoints, are out of scope.  Furthermore, it is possible to bypass
   the Transport Converter to connect directly to the servers that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   already support the required TCP extension(s).
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And

   The use of a Transport Converter means that there is no end-to-end
   transport connection between the client and server.  This could
   potentially create problems in some scenarios such as those discussed
   in Section 4 of [RFC3135].

And 

   The main advantage of network-assisted conversion services is that
   they enable new TCP extensions to be used on a subset of the path
   between endpoints, which encourages the deployment of these
   extensions.  Furthermore, the Transport Converter allows the client
   and the server to directly negotiate TCP extensions for the sake of
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   native support along the full path.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Or, if the authors do
> not want to say that, they

[Med] Agree. We avoided to include such details because these are deployment-specific (draft-nam-mptcp-deployment-considerations-01#section-5.6.7). But if you think this is useful to record, we can reinsert the text:

X.X.  Logging

   If the Converter is configured to behave in the address sharing mode, the
   logging recommendations discussed in Section 4 of [RFC6888] need to
   be considered.  Security-related issues encountered in address
   sharing environments are documented in Section 13 of [RFC6269].