Brian,
okay, I'm convinced for passive FTP (and s/FTP/active-mode FTP/g in my previous message). Now the problem would remain -- how, in an interfaceless environment, can the tcpinc machinery tell passive from active FTP in advance?
It can't. The problem with the FTP-ALG is that it needs to change the content of the payload of TCP packets to translate the addresses. Allowing middleboxes to change the content of packets is clearly something that tcpinc wants to prevent. The receiver could detect this modification as MPTCP does in this case, but a fallback to non-encrypted TCP to allow FTP-ALG to work would completely jeopardise the security of tcpinc.
I'd personnaly prefer a tcpinc that breaks FTP when used through NATs and ALG but remains secure over a tcpinc that enables middleboxes to change the packet payload to support FTP-ALG.
As a datapoint, we measured how MPTCP works through such FTP-ALG in various networks and found the following :
"We discovered that even with regular TCP, active FTP works only in 23 out of the 50 access networks. Many NAT devices are not able to correctly modify the IP address in the control connection, and thus do not allow FTP to operate correctly.
In the networks where active FTP over regular TCP worked, FTP over MPTCP succeeded in 86% of the cases. In the cases were MPTCP failed, the IP address contained in the PORT command was not properly modified by the NAT."
See http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof
Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
