Re: [ftpext] [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05

"Dan Wing" <dwing@cisco.com> Thu, 23 December 2010 18:04 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7063A6856; Thu, 23 Dec 2010 10:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.512
X-Spam-Level:
X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tt0sfHNKVxh; Thu, 23 Dec 2010 10:04:35 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 81FDC3A6850; Thu, 23 Dec 2010 10:04:35 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAN8dE02rR7H+/2dsb2JhbACXN4x0c6Vnmy6FSgSEZQ
X-IronPort-AV: E=Sophos;i="4.60,219,1291593600"; d="scan'208";a="640611294"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Dec 2010 18:06:36 +0000
Received: from dwingWS (sjc-vpn2-687.cisco.com [10.21.114.175]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oBNI6ajr022399; Thu, 23 Dec 2010 18:06:36 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Dave Thaler'" <dthaler@microsoft.com>, "'Iljitsch van Beijnum'" <iljitsch@muada.com>
References: <0cac01cb58ea$32d19a60$9874cf20$@com> <9B57C850BB53634CACEC56EF4853FF65343005F2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <B166ACF7-FA96-4954-8411-A86BC7923A76@muada.com> <9B57C850BB53634CACEC56EF4853FF653447D195@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447ECAF@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <8B73074C-5B7E-425F-B8B2-C28757FB7CD6@muada.com> <9B57C850BB53634CACEC56EF4853FF653447F40D@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653447F599@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 23 Dec 2010 10:06:36 -0800
Message-ID: <049901cba2cc$238f67e0$6aae37a0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActY6jKKLqeAf6WHSOikuiNZqgewtAH/d6IwBraFzQAJXXikgAAN1huAACguIwAABqYt8AALsh7QABxF4tA=
Content-Language: en-us
Cc: draft-ietf-behave-ftp64@tools.ietf.org, ftpext@ietf.org, 'Behave WG' <behave@ietf.org>
Subject: Re: [ftpext] [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Dec 2010 18:04:37 -0000

<soapbox>
This thread underscores why standardizing an ALGs is terribly 
difficult.  In this case, the addition of a new feature (LANG
command) on the client and server requires the ALG to either
break that new feature or to fully support the new feature.
For the ALG to fully support LANG, that means an ALG has 
to support all possible languages that can be expressed by 
LANG.

... and, remember, FTP is a "simple" protocol.
</soapbox>

The best solution I see is the FTP64 ALG has to (MUST) 
remove LANG from the server's FEAT response, and translate
the LANG command to NOOP and return a 5xy response to the
client.


If an FTP client, running on an IPv6-only machine, does not
like LANG being disabled, there are two solutions:

  1. the FTP client has to implement the "ALGS DISABLE64" 
     command, and ensure the IPv4-only FTP server it is 
     using properly supports the EPSV command.  This
     is, effectively, draft-ietf-ftpext2-ftp64-00.
OR
  2. have the FTP server add an AAAA record, and properly
     support the EPSV command.  This causes the FTP traffic
     to not use the NAT64 or FTP64 ALG.

-d




> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Dave Thaler
> Sent: Wednesday, December 22, 2010 9:19 AM
> To: Dave Thaler; Iljitsch van Beijnum
> Cc: draft-ietf-behave-ftp64@tools.ietf.org; ftpext@ietf.org; Behave WG
> Subject: Re: [BEHAVE] one week WGLC, draft-ietf-behave-ftp64-05
> 
> One more comment...
> 
> [...]
> > > Ideally, the ALG would observe the LANG negotiation and then send
> text
> > > in the desired language. However, there is no way to make sure that
> > > the ALG supports all the languages that clients and servers may
> > > support, so even if the ALG makes this attempt, there will be cases
> > > when it can't provide text in the desired language.
> > >
> > > When that happens, there are two choices:
> > >
> > > 1. block the LANG negotiation and use the default language
> > >
> > > 2. ignore the LANG negotiation and use the default language
> >
> > Yes for LANG (as opposed to the FEAT exchange), those are the same as
> I
> > described in my email.
> >
> > > The advantage of 1 is consistency. However, this is more complex to
> > > implement and despite some evidence of LANG support I fear that
> actual
> > > use of this feature is too low to see good real-world testing, so
> > > there is a significant risk of bugs that won't come to light until
> the
> > > ALG is widely deployed. Another downside is that the user is now
> > > deprived of text in the desired language for text sent by the
> server that isn't
> > touched by the ALG. Most notably, this would be the greetings.
> > > With failed LANG negotiation, users probably also wouldn't be able
> to
> > > use UTF-8 user names, passwords or path names.
> >
> > The last sentence is not correct.   The LANG command only controls
> the
> > language
> > of the server's text responses.  It has no effect on the ability for
> the client (or
> > server) to use UTF-8 user names, passwords, or path names.
> >
> > But yes, the advantage is consistency, and the disadvantage is that
> you're
> > limited to languages supported by both the server and the ALG.
> >
> > >
> > > The advantage of 2 is implementation simplicity and that the
> majority
> > > of the text is still in the desired language. However, some server
> > > responses will be in the ALG's (default) language rather than in
> the
> > > negotiated language. (But informed users can still see what's going
> on
> > > from the numeric response, the text is merely additional
> information.)
> >
> > To repeat my earlier point, the disadvantages are
> > 1) Text from the ALG may render as garbage (even overwriting the
> numeric
> > response,
> >    making it impossible for the user to see what's going on...
> remember some
> > languages
> >    are bidirectional so this isn't just about the backspace
> character)
> > 2) Some clients might even crash or have other unexpected behavior,
> since
> >     2 appears to violate RFC 2640 and hence could easily have
> untested behavior.
> >
> > To me, the above disadvantages are strong arguments against 2.
> 
> Of course, in theory, neither of the above *should* be a problem
> if implementations deal with text correctly.  I guess the main point
> is about RFC compliance and levels of testing.
> 
> I wouldn't want to apparently violate RFC 2640 without the
> FTPEXT group's consent, so that would be the question to the FTPEXT
> list.
> 
> -Dave
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave