Subject: [BEHAVE] ALG manipulation for FTP64

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 May 2010 21:29:59 +0200

After my recent discussion with Dan I've been trying to write up a specification for one or two new commands that let an FTP client interact with the FTP64 ALG.

I'm pretty sure this "ALG status" command is useful:

ALGS with no argument: request ALG status

50x: means there is no ALG
216 ALG status NONE: ALG will not translate EPSV to PASV or EPRT to PORT
216 ALG status EPSV: ALG will translate EPSV to PASV but not EPRT to PORT
216 ALG status EPRT: ALG will translate EPRT to PORT but not PASV to EPSV
216 ALG status BOTH: ALG will translate EPSV to PASV and EPRT to PORT

ALGS none: disable ALG

ALGS EPSV: enable EPSV translation and disable EPRT translation

216 ALG status EPSV: ALG will translate EPSV to PASV but not EPRT to PORT

ALGS EPRT: enable EPRT translation and disable EPSV translation

ALGS BOTH: enable both EPSV and EPRT translation

The ALG SHOULD set the requested mode but MAY respond with a 216 listing a different mode.

I'm not sure it's useful to also make the ALG mention the external IPv4 address that it uses, I don't think this is useful to the client unless the client can also set up a port mapping. That could happen with the ALGP (ALG port) command:

ALGP 49152
50x: command not implemented
425 can't open data connection: mapping can't be made for some reason
229 <text indicating the ALG has set up a mapping> (<d><net-prt><d><net-addr><d><tcp-port><d>)

in the 229 case net-prt is IPv4 (value = 1), net-addr is the IPv4 address used in the mapping and tcp-port the TCP port number. This information should allow the client to use the EPRT or PORT command succesfully.

I can see how this could be somewhat useful (probably even more so for non-FTP applications!), but on the other hand it requires a significant amount of space to specify. I'm not sure it's worth the trouble to do all this. Thoughts?

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 May 2010 13:22:06 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Thursday, May 13, 2010 12:30 PM
> To: IETF BEHAVE WG
> Subject: [BEHAVE] ALG manipulation for FTP64
> 
> After my recent discussion with Dan I've been trying to write 
> up a specification for one or two new commands that let an 
> FTP client interact with the FTP64 ALG.
> 
> I'm not sure it's useful to also make the ALG mention the 
> external IPv4 address that it uses, I don't think this is 
> useful to the client unless the client can also set up a port 
> mapping. That could happen with the ALGP (ALG port) command:
> 
> ALGP 49152
> 229 <text indicating the ALG has set up a mapping> 
> (<d><net-prt><d><net-addr><d><tcp-port><d>)
> 
> in the 229 case net-prt is IPv4 (value = 1), net-addr is the 
> IPv4 address used in the mapping and tcp-port the TCP port 
> number. This information should allow the client to use the 
> EPRT or PORT command succesfully.
> 
> I can see how this could be somewhat useful (probably even 
> more so for non-FTP applications!), but on the other hand it 
> requires a significant amount of space to specify. I'm not 
> sure it's worth the trouble to do all this. Thoughts?

I fear the complexity involved with turning on/off EPSV and EPRT individually.
Is there a use case for that additional functionality?  That is, would an IPv6
FTP client ever want/need EPSV rewriting enabled in the ALG, but EPRT
rewriting disabled?

My thought is only three commands are necessary:

  ALGS STATUS64  ; returns 216 if the ALG is currently doing EPSV->PASV
                 ; and EPRT->PORT rewriting; 200 if an FTP64 ALG is 
                 ; present but disabled; 5xy otherwise
  ALGS ENABLE64  ; enables EPSV and EPRT rewriting to PASV and PORT
                 ; this is the default operation if there is 
                 ; an FTP64 ALG.  Returns 216 if ALG agrees to
                 ; rewrite EPSV and PASV per draft-ietf-behave-ftp64,
                 ; 5xy otherwise.  After issuing this command, 
                 ; "ALGS STATUS64" will return 216.
  ALGS DISABLE64 ; disables EPSV and EPRT rewriting.  Returns 216
                 ; if the ALG agrees to cease modification of EPSV
                 ; an EPRT.  After issuing this command, issuing a
                 ; subsequent "ALGS STATUS64" will return 200.

-d

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 May 2010 22:37:06 +0200

> I fear the complexity involved with turning on/off EPSV and EPRT individually.

Be glad I skipped the ALGP then.  :-)

> Is there a use case for that additional functionality?

I can probably think of something but the fact that you could flip the ALG from on to off or the other way around between an EPSV and an EPRT as you're not going to do both at the same time makes that moot.

>                 ; subsequent "ALGS STATUS64" will return 200.

Ok, that mostly makes sense except that not all ALGs will implement EPRT translation so we need to convey that capability somehow. Maybe use my original 216 codes for that?

I'll post -03 this weekend and address any other comments that I can immediately roll into that version if any come in by then.

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 May 2010 13:42:18 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Friday, May 14, 2010 1:37 PM
> To: Dan Wing
> Cc: 'IETF BEHAVE WG'
> Subject: Re: [BEHAVE] ALG manipulation for FTP64
> 
> I can probably think of something but the fact that you could 
> flip the ALG from on to off or the other way around between 
> an EPSV and an EPRT as you're not going to do both at the 
> same time makes that moot.
> 
> Ok, that mostly makes sense except that not all ALGs will 
> implement EPRT translation so we need to convey that 
> capability somehow.

Good point.

-d

> Maybe use my original 216 codes for that?
> 
> I'll post -03 this weekend and address any other comments 
> that I can immediately roll into that version if any come in by then.
> 
> Iljitsch=