Re: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
Pekka Savola <pekkas@netcore.fi> Mon, 30 May 2011 09:10 UTC
Return-Path: <pekkas@netcore.fi>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D290E06D8; Mon, 30 May 2011 02:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.784
X-Spam-Level:
X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, SARE_PROLOSTOCK_SYM3=1.63, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duFXAbEWoo-N; Mon, 30 May 2011 02:10:30 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22449E06EA; Mon, 30 May 2011 02:10:29 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id p4U9AN92013350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 12:10:23 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id p4U9ANwC013347; Mon, 30 May 2011 12:10:23 +0300
Date: Mon, 30 May 2011 12:10:23 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
In-Reply-To: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
Message-ID: <alpine.LRH.2.02.1105301209380.13115@netcore.fi>
References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
User-Agent: Alpine 2.02 (LRH 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Virus-Scanned: clamav-milter 0.97 at otso.netcore.fi
X-Virus-Status: Clean
Cc: draft-ietf-behave-ftp64.all@tools.ietf.org, behave@ietf.org
Subject: Re: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2011 09:10:31 -0000
On Fri, 20 May 2011, The IESG wrote: > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > - 'An FTP ALG for IPv6-to-IPv4 translation' > <draft-ietf-behave-ftp64-10.txt> as a Proposed Standard This is an ops-dir review of draft-ietf-behave-ftp64-10. I do not find major issues in the document. This is a somewhat complex document and I would have hoped that the spec could have been more straightforward and the result is some 50 MUSTs, SHOULDs and MAYs. But I suppose FTP legacy cases and implementations etc. make it a difficult protocol to support in the real life. substantial comments -------------------- The document does not mention or discuss LPRT and LPSV. Is that intentional? The IANA registry says these are now obsolete, but RFC1639 is still experimental and no document has (formally) obsoleted these. S 5: Telnet option negotiation attempts by either the client or the server, except for those allowed by [RFC1123], MUST be rejected by the FTP ALG without relaying those attempts. This avoids the situation where the client and the server negotiate Telnet options that are unimplemented by the FTP ALG. ... what does "rejected" mean exactly? Does the ALG send back to the negotiation attempter some error code? Does it abort the connection? ignore these options? strip them out when connecting to the other end? 8. Default port 20 translation If the client does not issue an EPSV/PASV or EPRT/PORT command prior to initiating a file transfer, it is invoking the default active FTP behavior where the server sets up a TCP session towards the client. In this situation, the source port number is the default FTP data port (port 20) and the destination port is the port the client uses as the source port for the control channel session. .. is it? I thought the source port used by the server is orthogonal to whether pasv/port is issued. AFAIK, multiple FTP server implementations never use port 20. But I have not recently tested this myself. The ALG MUST enable or disable EPSV to PASV translation as requested. If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable it and ALGS DISABLE64 SHOULD disable it along with enabling or disabling EPSV to PASV translation, respectively. If EPRT to PORT translation is not supported, ALGS ENABLE64 only enables EPSV to PASV translation. .. what does this SHOULD..along with.. mean? I read it so that it's OK that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not disabled? A different way to read it would be that both EPSV->PASV and EPRT->PORT are SHOULDs. editorial: ---------- A survey done in April of 2009 of 25 randomly picked and/or well- known FTP sites reachable over IPv4 showed that only 12 of them supported EPSV over IPv4. .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave list. the results didn't differ much (I didn't look at the numbers), but if you want to update this, now would be the chance. If such a multi-purpose ALG forbids the use of the AUTH command for policy reasons, the side effect of making the ALG stop performing the translations described here, as well as other possible interventions related to IPv6-to-IPv4 translation, MUST be retained even if the ALG responds to the AUTH command with an error and does not propagate the command to the server. .. I had a hard time following what this one sentence includign a MUST actually requires. Maybe break down to more easily digestible sentences? [Bernstein] Bernstein, D., "PASV security and PORT security", 2000, <http://cr.yp.to/ftp/security.html>. .. this reference is not cited in the doc, add or remove?
- [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.t… The IESG
- Re: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-… Pekka Savola
- [BEHAVE] FW: Last Call: <draft-ietf-behave-ftp64-… David Harrington
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Rockson Li
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Rockson Li
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Rockson Li
- [BEHAVE] question on draft-ietf-behave-ftp64-10.t… Rockson Li
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Fernando Gont
- Re: [BEHAVE] question on draft-ietf-behave-ftp64-… Iljitsch van Beijnum
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- Re: [BEHAVE] question on draft-ietf-behave-ftp64-… Rockson Li
- Re: [BEHAVE] question on draft-ietf-behave-ftp64-… Iljitsch van Beijnum
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Iljitsch van Beijnum
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- [BEHAVE] AUTH cmd and transparent mde Rockson Li
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Iljitsch van Beijnum
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Rockson Li
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Iljitsch van Beijnum
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Rockson Li
- Re: [BEHAVE] AUTH cmd and transparent mde (ftp64) Iljitsch van Beijnum