Subject: Re: [BEHAVE] General Comments draft-ietf-behave-ftp64-00

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 2 May 2010 22:58:05 +0200

About the comments in the PDF file:

I don't think it makes sense to refer to RFC 3033 as it would suggest we say something about the particular messages in that document rather than just middleboxes in general.

I moved the text as per the next comment.

Highlighting this:

>> but an ALG may translate EPSV commands to PASV commands, conflicting with the earlier "EPSV ALL".

You say:

> Comment: Why > would > a > new > FTP64 > ALG >  do > that > (as > opposed > to > a > FTP44 > ALG)? > I >  think > here > we > have > the > opportunity > to > say >  that > “FTP64 > ALGs >  > must > not > translate > ESPV >  commands > to > PASV > commands > unless > it > can >  detect > that > the > server > does > not > support > it”. > I >  mean, > aren’t > we > recommending > that > the >  client > retries > with > PASV > if > not > successful? > 
  Otherwise it is conflicting with the  recommendations to the client. 

(You may want to yell at your PDF generation tool vendor.)

I don't understand that comment. The whole basis of the FTP64 ALG is translation of client issued EPSV commands into PASV commands seen by the server.

Then:

>> However, an ALG used with a stateless translator should also support EPRT

> Comment: How > can > it > be > stateless > in > the >  case > of > EPRT? >  > When > you > change > the > IP >  address > inside > the > EPRT > command > you > need >  to > adjust > TCP > sequence > numbers. > Doesn’t >  that > make > it > stateful.? > 

The IPv6-to-IPv4 translation (and the other way around) is stateless. So it's possible to set up a data channel for EPRT (IPv4 side to IPv6 side) without trouble just like for EPSV (IPv6 side to IPv4 side) in the stateful case. Translation of TCP fields is unnecessary, with the possible exception of the checksum. Of course the control channel session is a different story, but this session is piped through the ALG, while the data session only goes through the IP version translator and not through the ALG.

I added text about seqnums and AUTH.

About the default in EPSV to PASV translation, I removed the word "may", it's now:

> As such, an FTP ALG translates all occurrences of the EPSV command issued by the client to the PASV command

I don't really want to use the word "MUST", as nobody is required to implement an FTP64 ALG. However, this action is fundamental to being an FTP64 ALG so it doesn't make sense to omit it.

Re: is EPRT translation possible, it's pretty easy. I didn't even put in an example until now.

Yes, IPv6.

On 6 jan 2010, at 13:37, Reinaldo Penno wrote:

> I would suggest a new revision
> where normative wording is fixed so that correct interpretation (and a new
> revision) can be made.

Done.

> 3. The document specifies how an ALG would handle many different cases but
> not what is the expected (as in SHOULD) default behavior. SHOULD it
> translate ESPV by default or not?

New text:

Note that the translation of EPSV through all translators and EPRT through a stateless translator is relatively simple and translation of EPRT through a stateful translator relatively difficult. As such, an ALG used with a stateful translator SHOULD support EPSV and MAY support EPRT. However, an ALG used with a stateless translator SHOULD also support EPRT.

> 4. If one would assume that at the beginning of time a IPV6 only deployment
> would start with a FTP64 ALG in the translator given there is no way to know
> which IPv4 servers support what and you need connectivity; sometimes the
> recommendation for client/servers and ALG seems conflicting.

The recommendations are:

Servers: support EPSV over IPv4

Clients: fall back to PASV

ALGs: only deploy if you must, then: see above.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 3 May 2010 01:07:05 +0200

> (You may want to yell at your PDF generation tool vendor.)

Ugh, when I pasted this there were no spaces between the words, this is even worse.

> I don't really want to use the word "MUST", as nobody is required to implement an FTP64 ALG. However, this action is fundamental to being an FTP64 ALG so it doesn't make sense to omit it.

Changed my mind a bit, it's now:

   As such, an FTP ALG MUST
   translate all occurrences of the EPSV command issued by the client to
   the PASV command, and reformat a 227 response as a corresponding 229
   response.  However, an ALG MAY forego EPSV to PASV translation if it
   has positive knowlegde, either administratively configured or learned
   dynamically, that EPSV will be successful without translation to
   PASV.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 May 2010 10:46:57 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Sunday, May 02, 2010 4:07 PM
> To: Iljitsch van Beijnum
> Cc: IETF BEHAVE WG
> Subject: Re: [BEHAVE] General Comments draft-ietf-behave-ftp64-00
> 
> >> As such, an FTP ALG translates all occurrences of the EPSV 
> command issued by the client to the PASV command
> 
> > I don't really want to use the word "MUST", as nobody is 
> required to implement an FTP64 ALG. However, this action is 
> fundamental to being an FTP64 ALG so it doesn't make sense to omit it.
> 

The text implies that the ALG needs only knowledge that the EPSV command will
be successful (2xx response).  But it's important that it have knowledge the
EPSV command *and* the transfer will be successful.  For example, using EPSV
with ftp.dell.com is successful (it returns a 2xx response), however
attempting to make a TCP connection to the indicated port fails.

I suggest:

OLD:
    dynamically, that EPSV will be successful without translation to
    PASV.
NEW:
    dynamically, that EPSV will be successful without translation to
......................^^^^
               "EPSV-initiated file transfer"
    PASV.

-d

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 May 2010 19:06:19 +0200

On 3 mei 2010, at 19:46, Dan Wing wrote:

>> However, an ALG MAY forego EPSV to PASV 
>> translation if it

> EPSV command *and* the transfer will be successful.

Ah, right.

>    dynamically, that EPSV will be successful without translation to

What about:

However, an ALG MAY be configured to forego EPSV to PASV translation for certain servers. Also, an ALG MAY attempt to determine whether a server can support EPSV file transfers successfully. In this case, any failures to set up the data channel TCP session or complete the transfer successfully MUST result in using EPSV to PASV translation for that server for a period of at least 7 days, and foregoing additional attempts to use EPSV towards servers that are not know to support EPSV for at least one hour. This one hour period MAY be applied on a per-client basis.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 May 2010 08:33:36 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Tuesday, May 04, 2010 10:06 AM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> However, an ALG MAY be configured to forego EPSV to PASV 
> translation for certain servers.
.................................^
                          or certain clients.

(for example, an FTP client might do all of this EPSV/PASV magic, or might
send PASV if it knows it is talking through a NAT64 translator
[draft-wing-behave-learn-prefix].  I do wish there was a way for an IPv6 FTP
client to declare it is "Smarter Than Your Average IPv6 FTP client".)

> Also, an ALG MAY attempt to 
> determine whether a server can support EPSV file transfers 
> successfully. In this case, any failures to set up the data 
> channel TCP session or complete the transfer successfully 
> MUST result in using EPSV to PASV translation for that server 
> for a period of at least 7 days, and foregoing additional 
> attempts to use EPSV towards servers that are not know to 
> support EPSV for at least one hour. This one hour period MAY 
> be applied on a per-client basis.

I feel that is too prescriptive.  FTP server could fail a 
transfer because of per-client bandwidth limits, per-client
connection limit, etc. -- and because of IP address sharing,
this could create a false positive about the FTP server's
support of EPSV.  I suggest removing the text starting with
"In this case" and just leave that "MAY attempt to determine"
as an implementation detail.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 11 May 2010 09:30:48 +0200

>> translation for certain servers.

Right.

> client to declare it is "Smarter Than Your Average IPv6 FTP client".)

What about repeating a command that has no side effects? Such as issuing FEAT or NOOP twice immediately after logging in?

> as an implementation detail.

What I'm worried about is that an ALG may use simplistic logic to do this and consistently fail, so the user doesn't get anywhere. I can write some text that is less prescriptive and just explains the problem, though.

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 May 2010 16:09:50 -0700

> Sent: Tuesday, May 11, 2010 12:31 AM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> What about repeating a command that has no side effects? Such 
> as issuing FEAT or NOOP twice immediately after logging in?

Might be worth considering.  Or a "NOOP DISABLE_FTP_ALG", with
some sort of positive response (from the ALG) if it agrees
to step out of the way.  Seems to be more hacky, though, but
something along these lines might be worth considering.  (special
uppercase/lowercase of the two NOOP commands that you suggested?)

> What I'm worried about is that an ALG may use simplistic 
> logic to do this and consistently fail, so the user doesn't 
> get anywhere. I can write some text that is less prescriptive 
> and just explains the problem, though.

Thanks.
-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 12 May 2010 14:48:30 +0200

> uppercase/lowercase of the two NOOP commands that you suggested?)

I don't think there are bad side effects from issuing an unknown command, so we could invent a new command for this, such as "NALG". But do we need to provide feedback to the client? In all cases, the client will issue EPSV to initiate a data transfer.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 May 2010 08:22:26 -0700

> Sent: Wednesday, May 12, 2010 5:49 AM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> I don't think there are bad side effects from issuing an 
> unknown command, so we could invent a new command for this, 
> such as "NALG". But do we need to provide feedback to the 
> client?

I believe it's best, yes.  That isn't hard; the ALG is 
manipulating commands and responses already.

> In all cases, the client will issue EPSV to initiate 
> a data transfer.

-d