Hi Brian, Valery FTP comes in two varieties: active and passive. There is no issue in passive mode FTP with tcpinc, as the client opens all the connections. For active, there is an issue with using tcpinc on the control connection, but no issue for the data connection.
AFAIK (and according to Wikipedia) browsers implement passive FTP so clicking on ftp:// links will work with tcpinc. 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 > >> On 21.08.2014, at 08:56, "Valery Smyslov" <[email protected]> wrote: >> >> Hi, >> >> I have some concerns regarding using of tcpinc >> with those protocols, that transfer network information inside application >> PDU. >> >> Most notable of such protocols is FTP, >> which transfers IP address and port for >> data connection inside control connection. >> Thus, when FTP is used with NAT the NAT must inspect content of control >> connection, and if PORT command (or reply to PASV command) is found, it must >> modify the address and port >> accordingly (and must prepare new NAT mapping) >> for the requested data connection to be able to be created. >> >> The tcpinc charter states that: >> - It should work over the vast majority of paths that unmodified TCP >> works over, in particular it must be compatible with NATs (at the very >> minimum with the NATs that comply with BEHAVE requirements as documented >> in RFC4787, RFC5382 and RFC5508). >> - The protocol must be usable by unmodified applications.[...] >> >> So I wonder how these requirements will deal with FTP + NAT. >> Obviously, if tcpinc protocol encrypts FTP control connection, >> then NAT cannot inspect it and FTP won't work in NATed >> environment. Using passive FTP mode would help in the >> situations when FTP client is behind a NAT, but then we will >> encounter the same problem when FTP server is behind a "reverse" NAT >> (not unusual now with "home networks"). Moreover, even today not all FTP >> clients support passive mode. >> >> And yes, FTP is a constant headache for FW and NAT developers, >> but it is still relatively widely used and one have to support it. >> >> I can see the following options for tcpinc: >> 1. Ignore the problem >> - the simplest approach, but it is against tcpinc charter >> 2. Deprecate FTP. >> - not feasible, IMHO >> 3. Deprecate NAT. >> - even less feasible, IMHO >> 4. Always pass FTP control connection in clear >> - first, how to determine FTP control connection? >> By hardcoded port number (21)? Or is there >> needed some policy - which ports to protect >> and which not? Then, passing control connection >> in clear will give passive eavesdropper plenty >> of very valuable information: ftp user name >> and password, so tcpinc won't achive its goal here. >> 5. Pass FTP control connection in clear if NAT is detected >> - need some mechanism to detect NAT inside tcpinc >> protocol. And again if control connection is in clear, >> then attacker will gain a lot of valuable information >> 6. Somehow handle FTP control connection >> so that it is partially encrypted (one approach >> is decribed in RFC4217, but it requires support in application). >> - this will significantly complicate tcpinc protocol >> >> So I wonder whether these concerns were discussed before. >> I apologize if they were discussed and I missed the discussion. >> >> Regards, >> Valery Smyslov. >> >> >> >> _______________________________________________ >> Tcpinc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tcpinc > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
