Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
Rockson Li <zhengyli@cisco.com> Thu, 30 June 2011 07:30 UTC
Return-Path: <zhengyli@cisco.com>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B8F21F86A4; Thu, 30 Jun 2011 00:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.969
X-Spam-Level:
X-Spam-Status: No, score=-8.969 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_PROLOSTOCK_SYM3=1.63]
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 gsiSLJoHcoGk; Thu, 30 Jun 2011 00:30:57 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C69D821F869C; Thu, 30 Jun 2011 00:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=14340; q=dns/txt; s=iport; t=1309419057; x=1310628657; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=m1oJffSywAc2r1JKOPPATBFeUitOq3e7Y1YP4CHM5JU=; b=B3NVfwv7hWlZIxaF9UvL2Xr7vBviQBD9mx2Tya4GMAH0Rwws37EZavSy t/ojatoHBdibPrnmuhPCxp99m3C0WuU3sYUliPsx4hGBJRPp7pfrw4uE+ 6Ylxlcn7CpsBUZxb+UslPKW87Kk479aUdS0k7a0Wyzaex9888opraheU4 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPwkDE5Io8UR/2dsb2JhbABSp013qiqeDIYwBIc4imuEdYtD
X-IronPort-AV: E=Sophos;i="4.65,449,1304294400"; d="scan'208";a="98948280"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2011 07:30:50 +0000
Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5U7UgBU014117; Thu, 30 Jun 2011 07:30:44 GMT
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Thu, 30 Jun 2011 15:30:38 +0800
Subject: Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
From: Rockson Li <zhengyli@cisco.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>, David Harrington <ietfdbh@comcast.net>
Message-ID: <CA324709.23D0F%zhengyli@cisco.com>
Thread-Topic: [BEHAVE] FW: Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Fri, 01 Jul 2011 08:08:07 -0700
Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" <behave@ietf.org>, Pekka Savola <pekkas@netcore.fi>, TSV Area <tsv-area@ietf.org>, "behave-chairs@tools.ietf.org Chairs" <behave-chairs@tools.ietf.org>, TSV Dir <tsv-dir@ietf.org>, draft-ietf-behave-ftp64.all@tools.ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2011 07:30:59 -0000
|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. [RL] It looks like sec 2.5 of RFC5797 has obsoleted those two commands. Regards, -Rockson On 6/28/11 12:17 AM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote: >FTP ALG implementers: please respond if you have an opinion, some stuff >below may make your life harder! (This is a response to two different >messages.) > >On 3 jun 2011, at 14:06, David Harrington wrote: > >> Can you address these issues? >> Do you have any other comments you know of that need to be included in >> a new rev? > >There were three reviews. See below for two, I'm trying to clear >something up about the other more directly. > >On 30 mei 2011, at 11:10, Pekka Savola wrote: > >> This is an ops-dir review of draft-ietf-behave-ftp64-10. > >> 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. > >I managed to overlook RFC 1639, and it wasn't brought up by anyone else >during the process. Apparently wu-ftpd implements this and curl used to, >but both failed to see any real-world usage so I think we can ignore this >without creating problems. > >> 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? > >What I had in mind was reply with a "DON'T". Is this text more clear? > > 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. For the purpose of > Telnet option negotiation, an FTP ALG MUST follow the behavior of > an FTP server as specified in [RFC1123] section 4.1.2.12. This... > >That section says: > > 4.1.2.12 Connections: RFC-959 Section 5.2 > > The words "and the port used" in the second paragraph of > this section of RFC-959 are erroneous (historical), and they > should be ignored. > > On a multihomed server host, the default data transfer port > (L-1) MUST be associated with the same local IP address as > the corresponding control connection to port L. > > A user-FTP MUST NOT send any Telnet controls other than > SYNCH and IP on an FTP control connection. In particular, it > MUST NOT attempt to negotiate Telnet options on the control > connection. However, a server-FTP MUST be capable of > accepting and refusing Telnet negotiations (i.e., sending > DONT/WONT). > > DISCUSSION: > Although the RFC says: "Server- and User- processes > should follow the conventions for the Telnet > protocol...[on the control connection]", it is not the > intent that Telnet option negotiation is to be > employed. > >> 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. > >RFC 959: > > 3.2. ESTABLISHING DATA CONNECTIONS > > The mechanics of transferring data consists of setting up the data > connection to the appropriate ports and choosing the parameters > for transfer. Both the user and the server-DTPs have a default > data port. The user-process default data port is the same as the > control connection port (i.e., U). The server-process default > data port is the port adjacent to the control connection port > (i.e., L-1). > >> 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. > >I think what it says is that it's optional to disable PORT->EPRT upon >DISABLE64. Enabling is optional because the feature is optional, but I >guess if you have the feature disabling should be mandatory, so >SHOULD->MUST: > > The ALG MUST enable or disable EPSV to PASV translation as requested. > If EPRT to PORT translation is supported, ALGS ENABLE64 MUST enable > it and ALGS DISABLE64 MUST disable it along with... > >Agree? > >> 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. > >I don't see the need to. > >> 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? > >What about this: > >If such a multi-purpose ALG forbids the use of the AUTH command for >policy reasons, the side effect of the AUTH command as described in this >document MUST be retained. In other words, if the ALG does not propagate >the AUTH command to the server, the ALG MUST still stop all possible >interventions related to IPv6-to-IPv4 translation. This is true for the >remaining duration >of the control channel session, and applies even if the ALG >responds to the AUTH command with an error. > >> [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? > >I'll remove it. > > >On 4 jun 2011, at 0:16, Fernando Gont wrote: > >> I've reviewed this document as part of the transport area directorate's >> ongoing effort to review key IETF documents. > > >> * Section 1, page 3: >> In 5 cases, issuing the EPSV >> command to the server led to a significant delay, in 3 cases followed >> by a control channel reset. > >> Could you please clarify what was the cause of the delay? And, btw, have >> you guys put the details of your results publicly available somewhere? > >What about the following text: > >Due to lack of additional information, it is impossible to determine >conclusively why certain FTP servers reset the control channel connection >some time after issueing an EPSV command. However, a reasonable >explanation would be that these FTP servers are located behind >application-aware firewalls which monitor the control channel session and >only allow the creation of data channel sessions to the ports listed in >the responses to PASV (and maybe PORT) commands. As the response to an >EPSV command is different (a 229 code rather than a 227 code), a firewall >that is unaware of the EPSV command would block the subsequent data >channel setup attempt, after which the FTP server may decide to terminate >the control channel session which isn't progressing the way it should. > >> * Section 1, page 3-4: >> Clients that want to engage in more complex behavior, such as server- >> to-server transfers, may make an FTP application layer gateway (ALG) >> go into transparent mode by issuing AUTH or ALGS commands as >> explained in Section 5. > >> I thought server-to-server transfer had been banned for many years now >> (it was exploited for address scan purposes). Am I missing something? > >Do you have a reference? > >As it's only listed here as an example of something that isn't addressed, >I don't think it's an issue to include this here. > >> * Section 5: >> In the second case, an implementation MUST have the ability to track >> and update TCP sequence numbers when translating packets as well as >> the ability to break up packets into smaller packets after >> [....] > >> What about the TCP URG flag and the Urgent Pointer? FTP is one of the >> few legacy applications that make use of TCP's urgent mode. And while >> use in new applications is deprecated, and TCP urgent mode itself is >> unreliable (see RFC 6093), you should make an explicit decision about >> what to do with TCP urgent mode when used for the FTP control channel. > >The word "urgent" isn't mentioned in RFC 959 or the FTP-related part of >RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, which >involves using urgent data. However, it looks like it's legal to ignore >the urgent pointer, from RFC 793: > > TCP also provides a means to communicate to the receiver of data that > at some point further along in the data stream than the receiver is > currently reading there is urgent data. TCP does not attempt to > define what the user specifically does upon being notified of pending > urgent data, but the general notion is that the receiving process will > take action to process the urgent data quickly > >> When packets are translated individually, the ALG should update the >> Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP >> session, there's the question of whether urgent mode should be "copied" >> from the IPv6 session to the IPv4 session. > >I think it's not worth the trouble and unlikely to be tested well, so I >would be in favor of clearing the URG flag. Any objections? > >> * Section 5.1, page 7: >> For the time being, ALG implementations may employ >> one of the following strategies regarding LANG negotiation > >> Should you s/may/MAY/? > >Not really. I'll see what the RFC Editor says. > >> * Section 5.1, page 8: >> 3. Block LANG negotiation by translating the LANG command to a NOOP >> command, and translating the resulting 200 response into a >> response appropriate for unsupported commands, such as 500. Text >> is sent in the default language. > >> I think you should mandate which exact code the 200 should be translated >> to, rather than just provide an example. > >Let's make it a 502 then. > >> The File Transfer Protocol (FTP) has a very long history, and despite >> the fact that today, other options exist to perform file transfers, >> FTP is still in common use. > >> Remove the comma between "today" and "others" > >Ok. > >> translators >> are used to bridge that gap, FTP is made to work through these >> translators as best it can. > >> s/as best as it can/to the best possible extent/? > >Why not. > >> * Section 5.1 (page 7) and elsewhere: >> So the situation where the client and server try to >> negotiate a language that the ALG doesn't support can't be avoided. > >> Expand doesn't to "does not", "can't" to "cannot", etc. > >Hm, the 425 code has "can't" in it. I'll leave this open and see what the >RFC Editor says. > >> * Section 5.1, page 8: >> Note that [RFC2640] section 3.1 specifies new handling for spaces and >> the CR character in path names. > >> Rephrase to "Note that Section 3.1 of [RFC2640]..." > >I adopted the word order but not the capitalization. > >> * Section 11, page 12: >> ALGs MUST support the new ALGS (ALG status) command that allows >> command MUST be passed on to the server without modification, and the >> clients to query and set the ALG's status. > >> I had trouble parsing this sentence. > >This is the text that is in -10: > > ALGs MUST support the new ALGS (ALG status) command that allows > clients to query and set the ALG's status. FTP servers (as opposed > to ALGs) MUST NOT perform any actions upon receiving the ALGS > command. FTP servers MUST still send a response, however. > If FTP servers recognize the ALGS command, the best course > of action would be to return a 202 response: > >Apparently two lines got lost at your end. > >> * Section 11, page 12: >> A client can use the ALGS command to request the ALG's status and to >> enable and disable EPSV to PASV and, if implemented, EPRT to PORT >> translation. > >> Please rephrase to "...disable EPSV to PASV translation and, if >> implemented, EPRT to PORT translation". > >Ok. > >Both of you, thanks for the reviews. >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Fernando Gont
- Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ft… Iljitsch van Beijnum
- 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