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
