Subject: Re: [BEHAVE] Questions on draft-ietf-behave-ftp64-00.txt

From: "Michael Lui (milui)" <[email-masked]>
Date: Tue, 16 Mar 2010 10:43:03 -0700

________________________________

From: Michael Lui (milui) 
Sent: Monday, March 08, 2010 4:48 PM
To: [email-masked]'
Subject: Questions on draft-ietf-behave-ftp64-00.txt

Hi,
 
I have a few questions on draft-ietf-behave-ftp64-00.txt.
 
1) In the following statement:
    "... 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...."

    Why is translation of EPRT through a stateful translator more
difficult? Pls clarify.

2) > In "..
       negotiation attempts by either the client or the server, except
for
       those allowed by [RFC1123], should be rejected by the FTP ALG
       without relaying those attempts.  This avoids the situation where
the
       client and the server negotiate options unknown to the FTP
ALG..."

       Not sure what kind of "options" should be allowed? Can you
clarify this in the doc?
 
3) In 4.2 "EPSV to PASV translation", it mentions:
   "..    If the client issues EPSV ALL, the FTP ALG must not pass this
command
          to the server, but respond with:

          202 Command not implemented.
    "
 
    Is it a MUST to respond 202 to the client? Is it acceptable not
sending anything back to the client?
    In some ALG implementation, sending a response directly from ALG is
quite different from than modifying a packet and then sending it out. It
will have a lot of implications.
    I like to know if there is other alternative than sending a response
from ALG to the client in this scenario.
 
4) When an IPv6 client sends PASV to a IPv4 server, does FTP ALG needs
to do anything? Will the PASV command and response remain intact?
    Something like:
               ipv6 client                 ftp alg
ipv4 server
                                   PASV                     PASV
                                ----------->            -------------->
                                           
            229 Entering Passive Mode     227 Entering Passive Mode
                   (a,b,c,d,e,d)
(a,b,c,d,e,d)
                                 <-----------            <--------------
 
5) When IPv6 client sends an EPRT command to IPv4 server using stateless
1:1 translation,
 
               ipv6 client
ftp alg                                               ipv4 server
                               EPRT |2|1080::8:800:200c:417A|6275
PORT a,b,c,d,e,f
 
------------------------------------------------>
------------------->
       
    a,b,c,d is the translated ipaddr from NAT after FTP64 and e,f will
be the same number as in the EPRT command.
 
    Is this correct?
 
6) Same question as in (5) but this time EPRT will have an IPv4 address
like:
               ipv6 client
ftp alg                                               ipv4 server
                                         EPRT |1|132.235.1.2|6275
PORT a,b,c,d,e,f
 
------------------------------------------------>
------------------->
       
    a,b,c,d is the translated ipaddr from NAT after FTP64 and e,f will
be the same number as in the EPRT command.
 
    Is this correct?
 
7) When IPv6 client sends an EPRT command to IPv4 server using stateful
1:N translation,
 
               ipv6 client
ftp alg                                               ipv4 server
                               EPRT |2|1080::8:800:200c:417A|6275
PORT a,b,c,d,e,f
 
------------------------------------------------>
------------------>
       
    a,b,c,d is the translated ipaddr from NAT after FTP64 and e,f will
be the NEW translated port number from NAT after FTP64.
 
    Is this correct?
 
8) Same question as in (7) but this time EPRT will have an IPv4 address
in it.

Thanks,
- Michael

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Mar 2010 21:54:01 +0100

Hi Michael,

Thank you for your remarks, sorry I didn't respond last week when you  
sent them to me directly yet, but here goes.

On 16 mrt 2010, at 18:43, Michael Lui (milui) wrote:

>     "... Note that the translation of EPSV through all translators  
> and EPRT

For EPRT translation the server sets up a connection back to the  
client. For this to work though a translator, the translator must set  
up mapping state between the moment the client issues the EPRT command  
and the server receives the translated command.

I'll add some text to the draft.

> 2) > In "..
>        negotiation attempts by either the client or the server,  
> except for
>        without relaying those attempts.  This avoids the situation  
> where the

The FTP spec says the control channel should behave like a telnet  
session, which can have all kinds of weird options. I would very much  
like to steer clear of having to say anything about those specific  
options because I don't think anything good can come of that. In  
practice, I'm pretty sure FTP software doesn't implement any telnet  
options.

>    "..    If the client issues EPSV ALL, the FTP ALG must not pass  
> this command

> sending anything back to the client?

Yes, MUST is the idea. I'll have to go back to RFC 959 to be sure, but  
I believe all commands must generate a response, even though RFC 2428  
doesn't specify one for EPSV ALL. No response would get the client  
stuck and thus kill the session.

>     In some ALG implementation, sending a response directly from ALG  
> is quite different from than modifying a packet and then sending it  
> out. It will have a lot of implications.
>     I like to know if there is other alternative than sending a  
> response from ALG to the client in this scenario.

I guess you could translate the EPSV ALL into NOOP and then the 200  
that comes back from the server into 202.

> 4) When an IPv6 client sends PASV to a IPv4 server, does FTP ALG  
> needs to do anything? Will the PASV command and response remain  
> intact?

I think under the notion of "don't mess with things you don't  
understand" simply relaying the command (and thus the response)  
unchanged would be best. I'll add this to the text.

> 5) When IPv6 client sends an EPRT command to IPv4 server using  
> stateless 1:1 translation,

>                ipv6  
> client                                                              
> ftp alg                                               ipv4 server
>                                EPRT |2|1080::8:800:200c:417A| 
> 6275                       PORT a,b,c,d,e,f
>                                 
> ------------------------------------------------ 
> >                       ------------------->

>     a,b,c,d is the translated ipaddr from NAT after FTP64 and e,f  
> will be the same number as in the EPRT command.

>     Is this correct?

If I interpreted your diagram correctly, yes.

> 6) Same question as in (5) but this time EPRT will have an IPv4  
> address like:
>                ipv6  
> client                                                              
> ftp alg                                               ipv4 server
>                                          EPRT |1|132.235.1.2| 
> 6275                               PORT a,b,c,d,e,f

You mean the IPv6 client issues an IPv4 address in the EPSV command?

I think in that case the command should be passed along without  
modification as the translator can't know what the client tries to do  
here.

> 7) When IPv6 client sends an EPRT command to IPv4 server using  
> stateful 1:N translation,

>     a,b,c,d is the translated ipaddr from NAT after FTP64 and e,f  
> will be the NEW translated port number from NAT after FTP64.

>     Is this correct?

Yes.

> 8) Same question as in (7) but this time EPRT will have an IPv4  
> address in it.

Same as with the stateless translation and IPv4.

Do you want me to add examples (where supported) or text (where  
unsupported) to the draft for these cases?

Iljitsch

---

From: "Michael Lui (milui)" <[email-masked]>
Date: Thu, 18 Mar 2010 10:39:36 -0700

Hi Iljitsch,

Thanks for the reply and this helps to clarify my confusion.
Pls see inlines [Michael]...

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Tuesday, March 16, 2010 1:54 PM
To: Michael Lui (milui)
Cc: [email-masked]
Subject: Re: [BEHAVE] Questions on draft-ietf-behave-ftp64-00.txt

Hi Michael,

>     Why is translation of EPRT through a stateful translator more 

For EPRT translation the server sets up a connection back to the client.
For this to work though a translator, the translator must set up mapping
state between the moment the client issues the EPRT command and the
server receives the translated command.

> sending anything back to the client?

Yes, MUST is the idea. I'll have to go back to RFC 959 to be sure, but I
believe all commands must generate a response, even though RFC 2428
doesn't specify one for EPSV ALL. No response would get the client stuck
and thus kill the session.

> response from ALG to the client in this scenario.

I guess you could translate the EPSV ALL into NOOP and then the 200 that
comes back from the server into 202.

[Michael] Some clarification in the text will help. Otherwise, it's
really up to reader's intrepretation :)

Yes.

[Michael] It will be very helpful to have some examples in the doc on
all the combinations:
- EPRT
		v6 -> v4
		v4 -> v6
		v6 (with v4 embedded address) -> v4
- EPSV
		similar combination

Thanks for your attention.
- Michael

Iljitsch