On 8/21/2014 11:51 PM, Valery Smyslov wrote:
Hi Joe,
On 8/21/2014 12:41 AM, Brian Trammell wrote:
Hi Valery,
Good points, all.
Devil's advocate position: why not deprecate FTP for all deployments
where security is at all important?
Because it remains a very useful access method, and because FTP lacks
security itself. And because we don't need to modify FTP to make it
work with security and NATs - just use passive-mode. This won't solve
all scenarios, but it will allow tcpinc to support FTP in ways that
FTP can already be used with other security protocols.
FTP + IPsec doesn't have this issue if SA is per IP (not per TCP
connection).
FTP + TLS as described in RFC4217 deals with this issue
by introducing new FPT command that allows application
to tear down TLS on control connection (see Section 5).
Passive mode is not a panacea, it will work for most scenarios
but not for all (e.g. FTP server behind NAT).
FTP servers behind NATs typically require a DMZ; once you do that,
passive mode would work fine.
I cannot estimate
whether the percentage of scenarios when it won't work
is essencial or negligible. And sometimes it is not so easy
for the user to switch FTP to passive mode (ftp often used
internally by applications without user control, e.g.
for getting updates).
None of this is new. As I already noted, this is already a common issue,
and already commonly solved using passive mode. I.e., TCPINC solutions
won't make this situation worse AFAICT, and there's clearly no current
pressing need to make things better.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
