Re: [secdir] Secdir last call review of draft-ietf-tcpm-converters-17

[[e-mail]]

Hi Christian,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Christian Huitema via Datatracker [mailto:[e-mail]]
> Envoyé : lundi 2 mars 2020 20:35
> À : [e-mail]
> Cc : [e-mail]; [e-mail]; draft-ietf-tcpm-
> [e-mail]
> Objet : Secdir last call review of draft-ietf-tcpm-converters-17
> 
> 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.

[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 

> material in the lengthy introduction sections, and I would like to see
> more clarity
> 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).

> 
> 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.

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


 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.

[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.

> 
> 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.

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

> 
> 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.

[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
> 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.

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

> 
> 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".

[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,
> 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.

[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.    

> 
> 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.

[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.

> 
> 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. 

[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
> 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.
> 
> 

[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].