hi Joe, all, 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? One possible approach here would be to detect a failed active FTP transaction, then rely on the application to try again and remember to disable itself for the second attempt (kind of like Valery's option 4, but with fallback). Of course this leads to the type of implementation complexity I was hoping to avoid through deprecation. I still think any pressure we can exert to speed active-mode FTP's retirement is effort better spent than effort building fiddly bits into tcpinc (Valery's option 6) for this corner case. Cheers, Brian On 21 Aug 2014, at 17:22, Joe Touch <[email protected]> wrote: > > > 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. > > Joe > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
