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

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Jun 2010 07:02:28 -0700

Correction (thanks, Dave Thaler):  We need to get 5 reviews before 
advancing the document to IESG.  We currently have 1, and Dave's 
review will bring the count to two.

One of the recent changes to the document has included a new FTP verb
to enable/disable the FTP64 ALG.  This verb is intended to support
IPv6 FTP clients who want to disable the FTP64 ALG because the IPv6
FTP client is implementing its own support for traversal of its NAT64.
I know this new verb has received little comment from the working
group and comments on that idea, and the specific suggestions in the
text, would be valuable.

Please review draft-ietf-behave-ftp64-03.

-d

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, June 10, 2010 12:32 AM
> To: [email-masked]'; 
> [email-masked]'; 'Iljitsch van Beijnum'
> Cc: 'Behave Chairs'
> Subject: RE: WGLC, draft-ietf-behave-ftp64-03
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[email-masked]] 
> > Sent: Wednesday, May 19, 2010 1:48 PM
> > To: [email-masked]'
> > Cc: 'Behave Chairs'; [email-masked]'
> > Subject: WGLC, draft-ietf-behave-ftp64-03
> > 
> > This email announces WGLC for draft-ietf-behave-ftp64-03,
> > 
> >   http://tools.ietf.org/html/draft-ietf-behave-ftp64-03
> > 
> > Please send comments to the author and the mailing list.
> > 
> > WGLC ends in two weeks on Wednesday, June 2.
> 
> The only comments received were from me.
> 
> Iljitsch, please update ftp64 with the comments received and
> I will advance the document to our AD.
> 
> -d
>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 11 Jun 2010 12:47:10 -0400

> Please review draft-ietf-behave-ftp64-03.

Dear colleagues,

I have read the draft.  I have some comments.

First, I confess that I am personally uninterested in continued
support for FTP, so the reasons anyone would go to the work here to
solve the problems it solves are somewhat mysterious to me.  (I say
this not to disparage the work, but so that the Chairs can evaluate
the worth of my review.)  Nevertheless, I think the draft does a
pretty good job of laying out what the issues are and suggesting what
to do.  I find it clear, detailed when it needs to be without being
needlessly verbose, and easy to follow.  I support its publication.

Most of the specific comments below are just nits.  None of them
really need to be addressed for me to support the document, but if
there were changes being made it might be a good idea to address them.

Specific comments:

Multiple places, (nit): "The FTP protocol …" Since the "P" in "FTP"
stands for "protocol", I think that's redundant.

Section 4:    

   Many within the IETF community argue that an IP version mismatch
   between FTP clients and FTP servers is better solved by changing
   clients and servers rather than using a translator.  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.

Surely this advice isn't good just because of the bizarre prejudices
of a bunch of IETF geeks?  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.  As written, that's a little redundant with
the subsequent text in the draft (which I think is fine as it is).

Section 4.3.2:

   If the address in the EPRT command is not the client's IPv6 address,
   the ALG's response is undefined.

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

Section 4.5: 

   As such, the behavior of an ALG is undefined when a client issues
   both PASV and PORT.

I assume this is because it's really effectively undefined in RFC 959?
That's how I read the text, anyway: the argument immediately before
makes that argument.

Section 5:

   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.

   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.

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

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

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Jun 2010 23:33:58 +0000

> Sent: Thursday, June 10, 2010 7:02 AM
> To: [email-masked]
> Cc: 'Behave Chairs'; [email-masked]
> Correction (thanks, Dave Thaler):  We need to get 5 reviews before advancing
> the document to IESG.  We currently have 1, and Dave's review will bring the
> count to two.
> 
> One of the recent changes to the document has included a new FTP verb to
> enable/disable the FTP64 ALG.  This verb is intended to support
> IPv6 FTP clients who want to disable the FTP64 ALG because the IPv6 FTP client
> is implementing its own support for traversal of its NAT64.
> I know this new verb has received little comment from the working group and
> comments on that idea, and the specific suggestions in the text, would be
> valuable.
> 

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

Besides editorial nits, my technical feedback is summarized below:

1) It leaves a number of things "undefined".  Since that's what got us into the mess
we have with NAT's today, this doesn't seem like a good idea to me.  I'd rather 
at least recommend some default (like what is already in 4.6) rather than saying
they're "undefined".  Perhaps that was the intent, but the word "undefined" in
various places is what I'm pushing back against.

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.

3) The doc contains behavioral statements about clients and servers, not just ALGs.
For example, Section 5 in particular recommends specific behavior for clients.  
Is this behavior already allowed/suggested by any existing RFC or is this specifying 
new normative client behavior? If the latter, I believe 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).

(The common characteristic of all of the above options, and perhaps others I didn't
think of, is that Behave is not specifying new FTP client or server behavior, only 
new ALG behavior.)

-Dave Thaler

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Jun 2010 12:41:43 +0200

> various places is what I'm pushing back against.

This is mostly about the situation where the EPRT arguments are such that simple translation in the ALG is impossible. I suppose mandating that in these cases the EPRT command is simply left untranslated would be a good alternative here.

However, there's also the case where a client issues both PASV and PORT. RFC 959 allows this, but I really don't see how this could work. I guess we could say to just ignore the PORT command and just handle PASV as defined previously...?

> would be suddenly declared to be non-compliant to this RFC.

Right. 202 (success despite the fact that the command isn't implemented) would probably be the most appropriate response, but any 50x would also be ok.

> Is this behavior already allowed/suggested by any existing RFC

No.

> or is this specifying 
> new normative client behavior?

Also no.

> think of, is that Behave is not specifying new FTP client or server behavior, only 

We've had that discussion before. Removing this stuff from the document upsets the balance between "we hate ALGs" and "we have to be pragmatic" and may lead to more objections elsewhere. These are specifically recommendations, and where they disagree with the established standard this is both supported by solid reasoning (see the Bernstein reference) and common practice in the wild.

I suggest we ask the ADs for guidance on this.

Thanks,

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Jun 2010 13:01:44 +0200

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

> I find it clear, detailed when it needs to be without being

Thanks!  :-)

> stands for "protocol", I think that's redundant.

Well, sometimes it's necessary to draw attention to the protocolness of FTP, and saying "the FT protocol" or "the file transfer protocol" would be somewhat awkward. In the case of "PIN number" I'd agree with you to a larger degree, because there are no other aspects to a PIN than the number. But there are FTP servers, FTP clients, FTP sessions... and the FTP protocol.

>    the protocol to work as designed and reduces complexity.

Ok.

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

See my message to Dave. I think IF we want to define something, it needs to be passing the command along unmodified. Of course this won't lead to a succesful transfer in 98% of all cases.

> like nice round numbers?

I'm afraid so. The logic is that this may lead to a timeout so the user shouldn't be inconvenienced too often.

> I think it might be helpful to have some

I'll add something in the vein of the above.

> parentheses around the reference instead, I suggest.

Ok.

> removed prior to publication?

I'll remove it myself in the next update.

Iljitsch

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jun 2010 09:28:19 -0400

On Tue, Jun 15, 2010 at 12:41:43PM +0200, Iljitsch van Beijnum wrote:
> This is mostly about the situation where the EPRT arguments are such
> that simple translation in the ALG is impossible. I suppose
> mandating that in these cases the EPRT command is simply left
> untranslated would be a good alternative here.

I think specifying something is good, no matter what.  That proposal
seems like the best alternative.
 
> However, there's also the case where a client issues both PASV and
> PORT. RFC 959 allows this, but I really don't see how this could
> work. I guess we could say to just ignore the PORT command and just
> handle PASV as defined previously...?

This was a different thing I was worried about.  Maybe the best answer
is to extend the existing prose a little.  You make a subtle argument
that RFC 959 allows this, but that it's effectively undefined
behaviour (because it's internally inconsistent).  What you could do,
then, is just say that it's undefined behaviour "in the same way that
it seems to be undefined under RFC 959".  That'd be enough to satisfy
me, anyway.  (I of course don't speak for Dave).

A

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

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 29 Jun 2010 17:00:40 -0400

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.

On 6/10/2010 10:02 AM, Dan Wing wrote:
> _______________________________________________
> 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: Wed, 30 Jun 2010 10:30:20 +0200

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