Subject: [BEHAVE] FTP64's assumption that data=control connection

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Mar 2010 17:57:34 -0800

BEHAVE WG, Iljitsch, (*)

As you know, FTP64 assumes the data and control channel will be the same with
the PASV command.  draft-ietf-behave-ftp64-00 says:

  "If the server's 227 response contains an IPv4 address that doesn't
   match the destination of the control channel, the FTP ALG should send
   the following response to the client:

      425 Can't open data connection."

Researching something else I bumped into the URL below which mentions
Microsoft's .NET framework also breaks if the IPv4 address in PASV doesn't
match the IPv4 address of the control connection:

https://connect.microsoft.com/VisualStudio/feedback/details/97409/ftpwebreques
t-passive-mode-with-different-data-ip

So, apparently, this sometimes happens in the wild.  Yet, I didn't uncover it
occuring in the wild with the ~2000 anonymous FTP servers that I tested on the
Internet.

I briefly thought to suggest removing the 425 error from FTP64, but I doubt
that would improve the chance of the FTP client to connect to the listening
TCP port.  Instead it would cause delays (because the TCP data connection
would not successfully complete).

I wanted everyone to be aware of this in case someone thinks of a creative
answer.

-d

(*) I was going to write "Behave, Iljitsch", but that comes across almost as
strangely as "Let's eat, Grandma!" versus "Let's eat Grandma!"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 14 Mar 2010 11:04:25 +0100

> occuring in the wild with the ~2000 anonymous FTP servers that I tested on the

I think the issue here is when a home user runs an FTP server behind a home gateway with NAT, where the FTP server sends back its RFC 1918 address because it doesn't know any better, and by ignoring this address everything works but of course refusing to connect or throwing an error breaks this.

> would not successfully complete).

What about ignoring the address if it's an RFC 1918 address but returning a 425 error if the address is a different non-RFC 1918 address?

Always ignoring the address is also an option.