The problem with NAT for protocols like FTP can be solved by using PCP (http://tools.ietf.org/html/rfc6887).
-Tiru > -----Original Message----- > From: Tcpinc [mailto:[email protected]] On Behalf Of Valery Smyslov > Sent: Thursday, August 21, 2014 3:54 PM > To: Yoav Nir; Brian Trammell > Cc: tcpinc > Subject: Re: [tcpinc] FTP + NAT + tcpinc > > Hi Yoav, > > > Hi Brian, Valery > > > > FTP comes in two varieties: active and passive. > > True. > > > There is no issue in passive mode FTP with tcpinc, as the client opens > > all the connections. > > Not quite. For an active mode there is an issue if client is behind NAT. > For a passive mode there is an issue if server is behind NAT. > (Well, it's true that in passive mode client opens all connections, but server > still indicates the address and port the client should connect to for data > transfer in the control connection, and if the server is behind NAT then these > values need to be adjusted by NAT). I admit that the situation when server is > behind NAT is more rare, than when client is behind NAT, but it is not > uncommon. Consider home network connected to the Internet via ISP's NAT > with FTP server installed that is accessible from the internet. > Nowdays this setup is supported by most "off shelf" routers and there are > plenty of free dynamic DNS services that solve the problem of non-staticness > of IP address of the server. > > > For active, there is an issue with using tcpinc on the control > > connection, but no issue for the data connection. > > True. But note. that control connection transmits user name and password, > that may be of interest for attacker (unless it is anonymous ftp). > > > AFAIK (and according to Wikipedia) browsers implement passive FTP so > > clicking on ftp:// links will work with tcpinc. > > Agree. But there are many standalone clients that don't support passive > mode or don't use it by default. Moreover, some applications use ftp > internally (for example to get updates) and user often has no means to > change the way they do it. > > Regards, > Valery. > > > Yoav > > > > On Aug 21, 2014, at 10:41 AM, Brian Trammell <[email protected]> wrote: > > > > > Hi Valery, > > > > > > Good points, all. > > > > > > Devil's advocate position: why not deprecate FTP for all deployments > > > where security is at all important? Its design does not lend itself > > > to operation without cleartext, and at the moment I can't think of > > > an application for FTP for which there are not deployed and tested > > > alternatives (e.g. scp, https) without the ports-in-cleartext drawback. > > > Now, deprecating a protocol won't make it disappear, but we can > > > certainly put a big warning sticker on it: "does not work with > > > tcpinc, here are alternatives that do." > > > > > > > Seems to me that any attempt to solve this with protocol design > > > > (your points 4, 5, 6) will replace one set of brittle corner cases > > > > with a > > > more complex set of brittle corner cases. Best to admit it FTP > > > doesn't work in an opportunistic-security* world and move on. > > > > > > Cheers, > > > > > > Brian > > > > > > Sent from my iPhone > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
