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

From: "David Harrington" <[email-masked]>
Date: Tue, 17 May 2011 14:03:44 -0400

Hi,

I reviewed draft-ietf-behave-ftp64 and have a few questions.
Overall I think the document looks to be in good shape.
I spotted a few things that might cause IESG approval to be delayed,
and had a couple questions because I am not an expert in the content.
Some text modifications might make things clearer.

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.

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?

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?

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

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

Thanks,
David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 May 2011 19:26:22 +0200

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

Ok.

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

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

> to be held up in processing. is there a way to eliminate this reference? Can an
> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 20 May 2011 21:46:17 +0200

I have submitted -10 with the FTPEXT2 reference removed and no NOOP ABNF:

https://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/