Re: [BEHAVE] AD review: draft-ietf-behave-ftp64-09

[Iljitsch van Beijnum <[e-mail]>]

On 17 mei 2011, at 20:03, David Harrington wrote:

> I reviewed draft-ietf-behave-ftp64 and have a few questions.

Ok.

> 1) should security considerations discuss trust between client-alg and
> alg-server? I assume TLS cannot be used end-to-end for FTP, but must be
> hop-to-hop client-to-alg, and alg-to-server. Assuming different credentials
> apply, the secuirty association must be established between the client and the
> alg, not client-server, and the security association  must be established
> between the alg and server, not client-server. I would also assume that how this is
> accomplished depends on whether active or passive mode is being used to establish
> connections. The text as written might already already say that only passive
> mode is used in the presence of TLS protection, but I'm not sure that
> is what the text says. This might be made clearer.

What you describe is not the intended behavior. Hopefully this is clearer:

If the client issues the AUTH command, then the client is attempting to negotiate <xref target="RFC2228" /> security mechanisms which are likely to be incompatible with the FTP ALG function. For instance, if the client attempts to negotiate TLS protection of the control channel (<xref target="RFC4217" />, an ALG can do one of three things. It can transparently copy data transmitted over the control channel back and forth, so the TLS session works asexpected but the client commands and server responses are now hidden from the ALG. It can also block the negotiation of additional security, which will likely make the client and/or the server break off the session, or if not, perform actions in the clear thatwere supposed to be encrypted. The third option is to negotiate with both the clientand the server so two separate protected sessions are set up and the ALG is still ableto modify client commands and server responses. However, again clients and servers are likely to reject the session because this will be percieved as a man-in-the-middle attack.

An ALG MUST adopt the first option, and allow a client and a server to negotiatesecurity mechanisms. To ensure consistent behavior, as soon as the initial AUTH command is issued by the client, an ALG MUST stop translating commands and responses, and start transparently copying back and forth TCP data sent by the client and the server.
This applies even if the AUTH command is unsuccessful.

> 2) section 4 "As such, an ALG used with a stateful translator MUST support EPSV
> and MAY support EPRT. However, an ALG used with a stateless translator SHOULD
> also support EPRT. " Is there a requirement regarding stateless and EPSV?

Right, I've made that explicit:

Note that the translation of EPSV through all translators and EPRT through a stateless translator is relatively simple but supporting translation of EPRT through a stateful translator is relatively difficult, because in the latter case a translation mapping must be set up for each data transfer using parameters that must be learned from the client/server interaction over the control channel. This needs to happen before the EPRT command can be translated into a PORT command and passed on to the server. As such, an ALG used with a stateful translator MUST support EPSV translation and MAY support EPRT translation. However, an ALG used with a stateless translator MUST support EPSV translation and SHOULD also support EPRT translation.

> 3) in section 9, "Implementations SHOULD NOT try to detect the
> situation where both PASV and PORT commands are issued prior to a command that
> initiates a transfer, but rather, apply the same translation they would have if
> there had not been a PASV command prior to a PORT command or a PORT command
> prior to a PASV command. " I find this a bit ambiguous. Is it expected that the
> translation they would have done be based on having received only the second
> command (as if the first had not been received), or based on not having received
> either?

Ok, I changed the text to:

<xref target="RFC0959" /> allows a client to issue both PORT and PASV to use non-default ports on both sides of the connection. However, this is incompatible with the notion that with PASV, the data connection is made from the client to the server, while PORT reaffirms the default behavior where the server connects to the client. As such, the behavior of an ALG is undefined when a client issues both PASV and PORT. Implementations SHOULD NOT try to detect the situation where both PASV and PORT commands are issued prior to a command that initiates a transfer, but rather, translate commands as they occur. So if a client issues PASV, PASV is then translated to EPSV. If after that, before any transfers have occurred, the client issues PORT and the ALG supports PORT translation for this session, the ALG translates PORT to EPRT.

I could go on with a PORT first, PASV later example and explicitly say something about how regular garbage collection applies, but I don't want this extreme corner case to take up the better part of a page.

> 4) should the NOOP in section 12 be reflected in the ABNF algs-command
> ?

How would that work?

And is the text insufficient? I don't know off the top of my head but there could be several cases with conditionals where this applies, making for lengthy and/or ugly ABNF.

> 5) draft-liu-ftp64-extensions should be updated to
> draft-ietf-ftpext2-ftp64
> during subsequent processing.


> 6) The normative reference to ftpext2 work could cause this document
> to be held up in processing. is there a way to eliminate this reference? Can an
> implementation "support EPSV successfully" without this ftpext2
> extension? The text isn't clear that "successfully" means requiring support for an
> IPv4-IPv6 translation environment; that is only implied by the choice of
> reference [2428] vs [ftpext2]. 

The reference is only there to give credit, there is no dependency. I can remove it. (It's an informative reference, btw.)

Let me know about the above and I'll submit -10.

Iljitsch