Subject: Re: [BEHAVE] WGLC, draft-ietf-behave-ftp64-03

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 01 Jul 2010 12:21:59 -0400

sorry, I meant that I concurred with your responses to their comments, 
and was supporting the draft anticipating those edits to be included. 

On 6/30/2010 4:30 AM, Iljitsch van Beijnum wrote:
> On 29 jun 2010, at 23:00, Ed Jankiewicz wrote:
>
>   
>> I have reviewed the doc and comments submitted by Dave Thaler and Andrew Sullivan, and would support advancing the draft assuming those issues are addressed first.  I don't have anything to add at this time.
>>     
>
> Which issues specifically do you mean?
>
> Iljitsch
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>   

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 2 Jul 2010 14:25:46 +0200

On 11 jun 2010, at 18:47, Andrew Sullivan wrote:

> The reason not to use ALGs and such like is
> because things _work better_ the less sludge you have in the way.  I
> would restate that this way:

>    The best way to solve IP version mismatches between FTP clients
>    and FTP servers is to change the clients or servers (or both) in
>    order to allow them to communicate natively.  That strategy allows
>    the protocol to work as designed and reduces complexity.

> Or something like that.

I changed it to this:

The ideal way to solve an IP version mismatch between FTP clients and FTP servers would be by changing clients and servers rather than using an IPv6-to-IPv4 translator for the data channel and using an application layer gateway on the control channel.
As such, it is recommended to update FTP clients and servers as required for IPv6-to-IPv4 translation support where possible, to allow proper operation of the FTP protocol without the need for ALGs.

> Shouldn't this be an error or something, and not just undefined?

I changed the "undefined" to "the ALG SHOULD NOT attempt any translation, but pass along the command unchanged" for the EPRT stuff.

And then:

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

>   The suggested time for removal of a server from this case is 7
>   days, 1 day when the server indicates EPSV support in its FEAT
>   response where it previously did not.

> Is there any special reason for those numbers, or do they just seem
> like nice round numbers?  I think it might be helpful to have some
> justification in the text.

I added:

These intervals limit the exposure of the user to timeouts. Different intervals MAY be appropriate, however.

>   The main rationale for ignoring the IPv4 address in the 227
>   response, even if the client has IPv4 connectivity, most servers
>   will only allow a data connection from the same client address as
>   seen in the control channel connection, see [Bernstein].

> Nit: I think that this needs an "is that" between "connectivity,
> most".  Also, the comma before "see" at the end looks wrong.  Use
> parentheses around the reference instead, I suggest.

It's now:

The main rationale for ignoring the IPv4 address in the 227 response is that, even if the client has IPv4 connectivity, most servers will only allow a data connection from the same client address as seen in the control channel connection. See <xref target="Bernstein" />.

> Appendix A, (nit): I guess this should say that the appendix should be
> removed prior to publication?

It's gone.

Iljitsch

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Jul 2010 08:38:56 -0400

Thanks.  This addresses all the comments I made.  I support the
document proceeding.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 2 Jul 2010 23:49:47 +0200

On 15 jun 2010, at 1:33, Dave Thaler wrote:

> My review is now at 
> http://research.microsoft.com/en-us/um/people/dthaler/draft-ietf-behave-ftp64-03.pdf

I haven't adopted this one:

Comment [DT9]: Reword as: “An ALG MAY impose restrictions required by security policies.”

The reason for this is that I'm pointing towards other types of ALGs that are not specified here, so the RFC 2119 language would not be appropriate.

You suggest using "FTP64" for "the translator" twice, but this would be the NAT64 or SIIT or other translator of data packets, not the ALG.

About "Note that this command be implemented in FTP servers": this is a normative specification for this command, so it's appropriate to specify that servers aren't allowed to implement it.

About this:

> it is better to ignore the
> server-supplied address and set up a data connection towards the IPv6
> address of the server that is used for the control channel session

You say:

> Comment [DT22]: Is this behavior already allowed/suggested by any existing RFC? Or is this specifying new normative client behavior?

It isn't allowed or suggested by existing specifications, although http://cr.yp.to/ftp/security.html (one of the references) as well as Dan's tests suggest that this is the right thing to do. Clearly, the specifications, which stem from well before NAT became widespread, no longer apply to current practice.

The lack of RFC 2119 language indicates that nothing normative is happening here.

However, note that what we do here is tell client that they should do on their own what we normatively specify the ALG SHOULD do:

> The ALG SHOULD ignore the IPv4 address in the server's 227 response.

You continue:

> If the latter, it would be more appropriate to either
> a)Move them to a separate doc (my personal preference), or b)Make this doc be a joint Behave/Ftpext document (which would certainly slow it down and hence I would argue against this), or c)Make this doc be a joint Behave/AD-sponsored doc (which seems unlikely if the AD charters FTPEXT), or
> d)Replace this section with a set of requirements for a separate client behavior document to meet (my second preference).

I guess this dovetails with the other stuff we suggest clients do to which you've indicated you'd like to see moved to a different document. I suggest that we apply whatever resolution we find for that to this as well.

In the meantime, the text a little bit later now says:

> The main rationale for ignoring the IPv4 address in the 227 response is that, even if the client has IPv4 connectivity, most servers will only allow a data connection from the same client address as seen for the control channel connection. See <xref target="bernstein" />. Using IPv6 for the control channel and IPv4 for the data channel means that the source address will almost certainly be different in both cases, making it unlikely that the data connection can be established successfully. Also, IPv4 reachability towards the server-supplied address may or may not exist, while IPv6 reachability has been established by virtue of the control channel connection. Finally, servers residing behind a NAT may provide an <xref target="RFC1918" /> address in their 227 response, and connecting to that address will not be successful. 

> 1) It leaves a number of things "undefined".

> 2) The doc specifies that servers SHOULD return a 202 response to an ALGS command.
> However, I just tried it with a server and got "500 Unknown command."  
>> From RFC 959, 500 seems like a reasonable response and I don't see why existing servers
> would be suddenly declared to be non-compliant to this RFC.

Right:

> Note that this command MUST NOT be implemented in FTP servers. If those recognize the command, the best course of action would be to return a 202 response success despite the fact that the command isn't implemented) when encountering the ALGS command. However, as FTP servers don't implement the command, there is no reason for them to specifically recognize this command, and returning any 50x response that is normally returned when commands are not recognized is appropriate.

I added a request to IANA to add the ALGS command to the FTP registry.

Iljitsch