Subject: [tcpinc] FTP + NAT + tcpinc

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Aug 2014 10:56:20 +0400

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.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Aug 2014 09:41:29 +0200

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-masked]> wrote:
> 
> Hi,
> 
> with those protocols, that transfer network information inside application PDU.
> 
> 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
> - 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).
> (not unusual now with "home networks"). Moreover, even today not all FTP clients support passive mode.
> 
>   is decribed in RFC4217, but it requires    support in application).
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Aug 2014 11:02:16 +0300

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Aug 2014 14:23:34 +0400

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.

> > 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Aug 2014 14:33:48 +0400

Hi Brian,

> 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

I don't think it is so easy in real life. True, there are alternatives to 
ftp, but
sometimes end user is unable to use them. For example, if some of
your favourite software gets updates via FTP, than you will face
a dilemma: either don't use tcpinc or don't update these software
(and wait untill its vendor swithes to some different protocol).
I don't know what you will chose. If this software is critical
for you then you will probably get rid of tcpinc. All these cases
will definitely slow down tcpinc deployment.

Regards,
Valery.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 21 Aug 2014 14:15:32 +0000

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-masked]] 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
> >
> > There is no issue in passive mode FTP with tcpinc, as the client opens
> > all the connections.
> 
> (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.
> 
> 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
> >
> > > 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
> > > 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
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 21 Aug 2014 18:58:16 +0400

Hi Tiru,

> (http://tools.ietf.org/html/rfc6887).

Sure it can and even should. But the tcpinc charter states that the
solution must not require modifying existing applications, and PCP
is not widely supported nowdays, AFAIK.

Valery.

> > server

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Aug 2014 08:19:44 -0700

On 8/20/2014 11:56 PM, Valery Smyslov wrote:
> 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

I doubt we should assume a solution beyond that which is already widely 
used in when encryption is combined with NATs - e.g., passive FTP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Aug 2014 08:22:21 -0700

On 8/21/2014 12:41 AM, Brian Trammell wrote:
> 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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Aug 2014 17:47:06 +0200

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-masked]> wrote:

> 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
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Aug 2014 09:10:33 -0700

On 8/21/2014 8:47 AM, Brian Trammell wrote:
> hi Joe, all,
>
> okay, I'm convinced for passive FTP (and s/FTP/active-mode FTP/g in
> myprevious message).
>
> Now the problem would remain -- how, in an interfaceless
> environment, can the tcpinc machinery tell passive from active FTP in
> advance?

Why would it want/need to, any more than IPsec over UDP would?

However, a SYN issued from port 20 would tell you it's active.

> 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).

FTP users already know to try passive mode FTP, AFAICT.

> 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.

There's no need tor retire anything. You can just recommend that the 
default is to use passive mode if you want, though.

Joe

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Aug 2014 18:14:18 +0200

> Why would it want/need to, any more than IPsec over UDP would?

... ah, right, because the subsequent passive-mode connection would Just Work. (Please forgive my rustiness with FTP; I honestly don't know whether I've used it directly this century.)

> FTP users already know to try passive mode FTP, AFAICT.

Yep... if this is the case, then there's no problem here.

Cheers,

Brian

> There's no need tor retire anything. You can just recommend that the default is to use passive mode if you want, though.
> 
> Joe
> 
>

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 21 Aug 2014 10:22:33 -0700

> 21 aug 2014 kl. 08:47 skrev Brian Trammell <[email-masked]>:
> 

This have been an issue for a implementors of RFC 2228 (FTP Security Extensions) and RFC 4217 (Securing FTP with TLS)

so nothing really new under the sun here for ftp implementors, active mode have always been an issue with firewall and nats.

The implementations I’ve touched have had fallback code to the other mode in case of failure, usually trying PASV first.

Love

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 22 Aug 2014 10:51:02 +0400

Hi Joe,

> 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). 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).

My main concern here is that if user experience
any troubles with his/her current working environment
after enabling tcpinc, he/she will most probably
disable it systemwide. So, inability to seamlessly
support FTP would hurt other applications as well.

Regards,
Valery.

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Aug 2014 09:49:48 -0700

On 8/21/2014 11:51 PM, Valery Smyslov wrote:
>> 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.
>
> 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

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

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 22 Aug 2014 21:59:25 +0200

Brian,
> Now the problem would remain -- how, in an interfaceless environment, can the tcpinc machinery tell passive from active FTP in advance?

It can't. The problem with the FTP-ALG is that it needs to change the 
content of the payload of TCP packets to translate the addresses. 
Allowing middleboxes to change the content of packets is clearly 
something that tcpinc wants to prevent. The receiver could detect this 
modification as MPTCP does in this case, but a fallback to non-encrypted 
TCP to allow FTP-ALG to work would completely jeopardise the security of 
tcpinc.

I'd personnaly prefer a tcpinc that breaks FTP when used through NATs 
and ALG but remains secure over a tcpinc that enables middleboxes to 
change the packet payload to support FTP-ALG.

As a datapoint, we measured how MPTCP works through such FTP-ALG in 
various networks and found the following :

"We discovered that even with regular TCP, active FTP works only in 23 
out of the 50 access networks. Many NAT devices are not able to 
correctly modify the IP address in the control connection, and thus do 
not allow FTP to operate correctly.

In the networks where active FTP over regular TCP worked, FTP over MPTCP 
succeeded in 86% of the cases. In the cases were MPTCP failed, the IP 
address contained in the PORT command was not properly modified by the NAT."

See 
http://inl.info.ucl.ac.be/publications/are-tcp-extensions-middlebox-proof

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be