From fernando.gont.netbook.win@gmail.com Fri Jun 3 15:16:26 2011 Return-Path: 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 2C397E07FF; Fri, 3 Jun 2011 15:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Wb0ykAyZwN2P; Fri, 3 Jun 2011 15:16:24 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58E6FE07F5; Fri, 3 Jun 2011 15:16:24 -0700 (PDT) Received: by yic13 with SMTP id 13so1221641yic.31 for ; Fri, 03 Jun 2011 15:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=Sj4Vst+u1ZbwtKHVqJr82KaaGYTOx70sLtiL61tHnWA=; b=po9gsDAhSoCIBaZA3BCxp3QOyXAEi+gRUUVprl4EAmC/aqiXIbL9srMzf4dpHMtgrv 43hKzFDyoC6wLu4IJhN6UBl0Xs28yxvd0oSRHX6Rt0lcBRV0UgT+PJKD7GS+kwOhNj7S XrdFFxuAKpXsZEyl5CdO2d9gRYi6gxoHlreSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:content-type:content-transfer-encoding; b=LJgbVnQz95Ae3EOGATAJpTpwfmkgOPUc+vsP3va9O3W3973MJC3xTITiNEJAoehVup sGo3h3mbLjHcKjzVRkONV5ryU72Zh+A84WI9sck9MidWgj/HsostN3nby52Zu+njmFZK xghUX38sDavEqt34RMRUAfd/fgr/GY/cxSVqc= Received: by 10.101.5.7 with SMTP id h7mr1816672ani.25.1307139383538; Fri, 03 Jun 2011 15:16:23 -0700 (PDT) Received: from [192.168.123.100] ([190.48.193.117]) by mx.google.com with ESMTPS id b25sm1460806anb.20.2011.06.03.15.16.20 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 15:16:22 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DE95D31.2030400@gont.com.ar> Date: Fri, 03 Jun 2011 19:16:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: draft-ietf-behave-ftp64@tools.ietf.org Subject: tsv-dir review of draft-ietf-behave-ftp64-10 X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tsv-area@ietf.org, "'ietf@ietf.org'" , TSV Dir X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 22:16:26 -0000 Hello, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. SUMMARY ------- This draft is on the right track but has open issues, described in the review. TECHNICAL --------- * 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? * 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? * 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. 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. * 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/? * 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. EDITORIAL --------- * Abstract, page 1 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" * Abstract, page 1 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/? * 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. * 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]..." * 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. * 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". Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Mon Jun 6 02:44:11 2011 Return-Path: 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 D2B9311E80E8; Mon, 6 Jun 2011 02:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XwveGvSTRq3C; Mon, 6 Jun 2011 02:44:11 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id DDF0711E808C; Mon, 6 Jun 2011 02:44:10 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p569iv1P000634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 6 Jun 2011 11:44:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: tsv-dir review of draft-ietf-behave-ftp64-10 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4DE95D31.2030400@gont.com.ar> Date: Mon, 6 Jun 2011 11:44:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28164FBC-556D-45BF-B924-A0645621B423@muada.com> References: <4DE95D31.2030400@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, tsv-area@ietf.org, "'ietf@ietf.org'" , TSV Dir X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 09:44:11 -0000 Thanks everyone for the comments. I'll look into the other technical = comments later this week, but there's one I can respond to right now: On 4 jun 2011, at 0:16, Fernando Gont wrote: > * 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? These tests were towards FTP servers found around the internet, so we = were unable to determine what exactly those servers were doing, other = than what we observed remotely. We speculate that this is the result of a firewall placed in front of = the FTP server that monitors the control channel and opens ports based = on the PASV or PORT commands, but the firewall doesn't support EPSV so = no port is opened and the data channel can never be established. I can put this discussion in the draft. (I seem to remember it was in an = earlier version.)= From dwing@cisco.com Tue Jun 21 16:16:55 2011 Return-Path: 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 B4AFF22800D; Tue, 21 Jun 2011 16:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.339 X-Spam-Level: X-Spam-Status: No, score=-110.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3x68+x1BVodv; Tue, 21 Jun 2011 16:16:55 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id F2996228006; Tue, 21 Jun 2011 16:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1767; q=dns/txt; s=iport; t=1308698214; x=1309907814; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=X746jxNlGlBvAXkMOb/itYXb1zr/mSBT8VchHM/fKs0=; b=HEN3+V+D/nvxN6vpDHWthcOoXa7UQIP3+5NGqTVab6xa4mT/gKLL3D/i adbzMKDGG5sIl9L3drTucOHuWWPILnc1YPzb3fQaQNXe+VWxiL3tS4nbv WqSzItSJN/GPfEmv1FBg/myYG/U1v2Q9S/YxrW2ssLehNjtRw7jcfJ9S0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMolAU6rRDoJ/2dsb2JhbABUmViNLneqO54ghioEhyKaag X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="382680619" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2011 23:16:54 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNGshD008712; Tue, 21 Jun 2011 23:16:54 GMT From: "Dan Wing" To: "'Transport Directorate'" , Subject: TSVDIR review, draft-ietf-v6ops-6to4-advisory Date: Tue, 21 Jun 2011 16:16:54 -0700 Message-ID: <062b01cc3069$4f3144b0$ed93ce10$@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: AcwwaU7jlTWCqbL7RwmnF47+Qbjwnw== Content-Language: en-us Cc: 'David B Harrington' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 23:16:55 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This document is ready to be published. I have one small suggestion. In Section 3, it reads: 5. PMTUD Failure: A common link MTU size observed on the Internet today is 1500 bytes. However, when using 6to4 the path MTU is less than this due to the encapsulation header. Thus a 6to4 client will normally see a link MTU that is less than 1500, but a native IPv6 server will see 1500. It has been observed that Path MTU Discovery does not always work, and this can lead to connectivity failures. Even if a TCP SYN/ACK exchange works, TCP packets with full size payloads may simply be lost. This problem is apparently exacerbated in some cases by failure of the TCP MSS negotiation mechanism. These failures are disconcerting even to an informed user, since a standard 'ping' from the client to the server will succeed, because it generates small packets, and the successful SYN/ACK exchange can be traced. Also, the failure may occur on some paths but not others, so a user may be able to fetch web pages from one site, but only ping another. this would benefit by adding an informational reference to RFC2923, "TCP Problems with Path MTU Discovery" -d From dwing@cisco.com Tue Jun 21 16:20:59 2011 Return-Path: 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 8121811E8083; Tue, 21 Jun 2011 16:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.382 X-Spam-Level: X-Spam-Status: No, score=-110.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 L2zgs0gRB6pD; Tue, 21 Jun 2011 16:20:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88F11E8075; Tue, 21 Jun 2011 16:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=585; q=dns/txt; s=iport; t=1308698455; x=1309908055; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=qFVDsOQa2jSK2+li/+6o7CSG8lm8JP6+JS1uFC8eIHs=; b=OoJGXjcyrk13LlXVc4bFodDFYOCusgOrHoN26vOOybnM4BYDHziOfPzv MzKR51GgCFWNePN+1lrzBXfzHvf01S0Hww26zzbxquRgpIA3glzw36afI 0p4U5xOLFDvKDuwhUGfi0C0Y9KHq3tc2Z+ygtpGx/Ntf8cAWAdnVAceDs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMwmAU6rRDoJ/2dsb2JhbABUmViNLneqZp4ghioEhyKaag X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="466595273" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2011 23:20:52 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNKpgC012770; Tue, 21 Jun 2011 23:20:52 GMT From: "Dan Wing" To: , "'Transport Directorate'" , Subject: TSVDIR review, draft-ietf-v6ops-6to4-to-historic Date: Tue, 21 Jun 2011 16:20:51 -0700 Message-ID: <062d01cc3069$dcafcd70$960f6850$@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: Acwwadxk88TypSiRQVm8LifDA8kfJA== Content-Language: en-us Cc: 'David B Harrington' X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 23:20:59 -0000 I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is ready for publication. I have no comments from a TSV directorate perspective. -d From iljitsch@muada.com Mon Jun 27 09:17:34 2011 Return-Path: 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 54F3921F85F0; Mon, 27 Jun 2011 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.785 X-Spam-Level: X-Spam-Status: No, score=-101.785 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 9jTvf0xWFjHX; Mon, 27 Jun 2011 09:17:33 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50A21F85E8; Mon, 27 Jun 2011 09:17:31 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5RGHu7V085279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 18:17:57 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> Date: Mon, 27 Jun 2011 18:17:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 16:17:34 -0000 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, > . > .. 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.= From fernando.gont.netbook.win@gmail.com Thu Jun 30 03:19:37 2011 Return-Path: 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 52B8E21F8808; Thu, 30 Jun 2011 03:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 DJXwv1vsDaHX; Thu, 30 Jun 2011 03:19:36 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0876E21F87DE; Thu, 30 Jun 2011 03:19:35 -0700 (PDT) Received: by yie30 with SMTP id 30so1045081yie.31 for ; Thu, 30 Jun 2011 03:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=jeBmZPmDSWs4TyAsbgE5KEqdLNm4rUakEMVQpKybk74=; b=dZzj41JS1BONi9XmFGmBX0MdFgRKm38c66gTmkmdMZGNpx80q9aaCY0bgbZ56u7W+x 3CY8cULm52jO9tWfBkkofxj17QflwZ3s/uUpbXXgVvMOmM8MjMfv0mCmwuFCysCgS18t GHXr6pzVMQ2hWWt13KgK4uRI8Fkh8LCJc57oI= Received: by 10.91.72.1 with SMTP id z1mr1665609agk.78.1309429170000; Thu, 30 Jun 2011 03:19:30 -0700 (PDT) Received: from [192.168.123.103] ([190.48.255.131]) by mx.google.com with ESMTPS id v16sm1873809ann.39.2011.06.30.03.19.20 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 03:19:28 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E0C4DA5.5000005@gont.com.ar> Date: Thu, 30 Jun 2011 07:19:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 10:19:37 -0000 Hi, Iljitsch, [I'm responding only to those parts that correspond to my tsv-dir review] On 06/27/2011 01:17 PM, Iljitsch van Beijnum wrote: > 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. Works for me. :-) -- If you have an external document with more data about this experiment, it might eb good to provide a link to it. >> * 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? * http://nmap.org/hobbit.ftpbounce.txt * http://www.cert.org/advisories/CA-1997-27.html * http://cr.yp.to/ftp/security.html * IETF RFC 2577 > 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. The point is that proxy FTP is not supporting in the FTP software I checked. >> * 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 Well, *TCP* does not state what should be done with the urgent data, since it doesn't know what's the application on top. But if you ignore urgent indications, you won't be able to interrupt ongoing commands (e.g. RETR). -- so my take is that this is important for FTP. Unfortunately, as noted in RFC6093, some middleboxes already play with urgent indications. BUt if you deliberatly ignore it, this would exacerbate the problem. >> 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? My understanding is that the implications of this is that you no longer will be able to abort commands (head of line blocking). >> * 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. Ok... I thought it was the wording of your explanation (RFC-Ed seems to prefer "can't" -> cannot "you're" -> "you are", etc.) (FWIW, I've omitted responses to comments that you've already addresses and that needed no further discussion). Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Thu Jun 30 05:37:23 2011 Return-Path: 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 C204211E8096; Thu, 30 Jun 2011 05:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.193 X-Spam-Level: X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZpqUvG6Bhlis; Thu, 30 Jun 2011 05:37:22 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 022FA9E8012; Thu, 30 Jun 2011 05:37:21 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5UCbiuO011497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 14:37:44 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <4E0C4DA5.5000005@gont.com.ar> Date: Thu, 30 Jun 2011 14:37:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58D5D2BB-1E76-4E54-8C9B-054D84067BA8@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> <4E0C4DA5.5000005@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , Pekka Savola , TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:37:23 -0000 On 30 jun 2011, at 12:19, Fernando Gont wrote: >>> 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? > * http://nmap.org/hobbit.ftpbounce.txt > * http://www.cert.org/advisories/CA-1997-27.html > * http://cr.yp.to/ftp/security.html I don't think these three are useful as they fall outside the scope of = the IETF. > * IETF RFC 2577 I think this is the relevant part: Disabling the PORT command is also an option for protecting against the bounce attack. Most file transfers can be made using only the PASV command [Bel94]. The disadvantage of disabling the PORT command is that one loses the ability to use proxy FTP, but proxy FTP may not be necessary in a particular environment. This doesn't forbid or deprecate server-to-server transfers. >> 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. > The point is that proxy FTP is not supporting in the FTP software I = checked. FTP predates TCP/IP but I doubt many implementations can still run over = NCP... Unfortunately there is no single FTP spec that lists only those things = still in active use. In fact, earlier this week I found out that wu-ftpd = still supports RFC 1639 long addresses, which is an experimental spec to = support non-32-bit addresses before IPv6 was standardized. And being good students of Jon Postel, we are conservative in what we = send and liberal in what we accept. [urgent data] > Well, *TCP* does not state what should be done with the urgent data, > since it doesn't know what's the application on top. But if you ignore > urgent indications, you won't be able to interrupt ongoing commands > (e.g. RETR). -- so my take is that this is important for FTP. > Unfortunately, as noted in RFC6093, some middleboxes already play with > urgent indications. BUt if you deliberatly ignore it, this would > exacerbate the problem. I tried interrupting a transfer, and my client (the MacOS commandline = one) did indeed send a packet with urgent data to ftp.nluug.nl but the = transfer didn't get aborted so apparently it may be unreliable either = way. So I want to add this text: Some FTP clients use the TCP urgent data feature when interrupting = transfers. An ALG MUST either maintain the semantics of the urgent = pointer when translating control channel interactions, even when = crossing packet boundaries, or clear the URG bit in the TCP header. >> 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? > My understanding is that the implications of this is that you no = longer > will be able to abort commands (head of line blocking). Hm, doesn't this only apply to the situation where command 1 is being = executed, command 2 has been given but is waiting to be executed and = command 3 is ABOR? The urgent pointer allows the server to look at the = ABOR even though command 2 is earlier in the pipeline. But if there is = no command 2 it shouldn't matter.= From iljitsch@muada.com Thu Jun 30 06:45:31 2011 Return-Path: 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 BC79E11E80CC; Thu, 30 Jun 2011 06:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 xT2NW0q2OXmF; Thu, 30 Jun 2011 06:45:31 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5511E80BF; Thu, 30 Jun 2011 06:45:30 -0700 (PDT) Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p5UDjq4O011921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2011 15:45:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: [BEHAVE] FW: Last Call: (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> Date: Thu, 30 Jun 2011 15:45:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44C34387-A958-41E9-9363-D8DB7EBBCEF0@muada.com> References: <04C1AFDBEA554F3FA5FDD978C1682D6E@davidPC> <817780D4-1CF0-4A5A-90A8-E8BF98A2274F@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-behave-ftp64@tools.ietf.org, fgont@acm.org, "behave@ietf.orgWG WG" , "ietf@ietf.org Discussion" , Daniel Stenberg , ftpext@ietf.org, TSV Area , "behave-chairs@tools.ietf.org Chairs" , TSV Dir , draft-ietf-behave-ftp64.all@tools.ietf.org, Pekka Savola X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 13:45:31 -0000 [Please note that this message is going to many mailing lists, please = trim as appropriate when responding.] I submitted a new version of the draft which addresses most, if not all = comments. The most notable change, which I would like to ask previous reviewers to = look at again, is the handling of the AUTH command, which is now made = much less prominent as a way to make the ALG transparent (clients should = use ALGS for this) so text specifying interaction of multiple ALGs could = be removed. The draft: http://tools.ietf.org/html/draft-ietf-behave-ftp64-11 The diff with -10: = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-behave= -ftp64-11.txt Thanks everyone for reviewing.= From marshall.eubanks@gmail.com Thu Jun 30 07:22:07 2011 Return-Path: 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 D8FEF21F8531; Thu, 30 Jun 2011 07:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZZgjdK0SJiiD; Thu, 30 Jun 2011 07:22:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E321F8532; Thu, 30 Jun 2011 07:22:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so1126387gwb.31 for ; Thu, 30 Jun 2011 07:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=04dPZxIj9j4wlqky9j5N8MIkchDQJ6iy7bhFUzg2VZ8=; b=O0Z8EKbHZ+m7DUTMIrVhdQTH1UomU+mj+sIthxa6+//PnPYarVn+o6NNJ79DhRECVe LfpVMwhHTpn2WzAluiiwjYnv6VKs/fDB8PC8iaEnlBtPkg5R8JIwS//wiSK9UtSpDbhx VbQUa8Wit9LoJYcLkx0sqNMLveyLooM/e/OTE= Received: by 10.150.12.10 with SMTP id 10mr1892145ybl.77.1309443725596; Thu, 30 Jun 2011 07:22:05 -0700 (PDT) Received: from [10.0.1.14] (c-67-188-32-245.hsd1.ca.comcast.net [67.188.32.245]) by mx.google.com with ESMTPS id i30sm1667452yhm.21.2011.06.30.07.22.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Jun 2011 07:22:05 -0700 (PDT) From: Marshall Eubanks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: tsv-dir review of draft-ietf-pim-mtid-08 Date: Thu, 30 Jun 2011 10:22:02 -0400 Message-Id: To: IETF Discussion Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Cc: TSV Area , pim@ietf.org, Transport Directorate X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 14:22:08 -0000 I've reviewed this document as part of the transport area directorate's = ongoing effort to review key IETF documents. These comments were written = primarily for the transport area directors, but are copied to the = document's authors for their information and to allow them to address = any issues raised. The authors should consider this review together with = any other last-call comments they receive. Please always CC = tsv-dir@ietf.org if you reply to or forward this review. Note : I also reviewed the WG mailing list discussions for this = document.=20 This draft is basically ready for publication, but has some issues that = in my opinion should be fixed before publication. There are, however, some issues that I think that should be addressed, = either in a follow-on document, or a revision of this document.=20 draft-ietf-pim-mtid introduces a new type of PIM Join Attribute = [RFC5384], the MT-ID Join Attribute, that extends PIM signaling to cover multiple topologies and to enable the = identification of which topology should be used when constructing a particular multicast distribution tree.=20 Multiple topologies have been used for some time in unicast (they are = supported by IS-IS and OSPF), and also in multicast. The most common = multicast requirement for multiple topologies is for video transport, = where important or expensive video streams (say, of sporting events) are = protected from disruption by multiple transport on completely different = network paths. In that use, if a network link goes down or becomes = congested or otherwise suboptimal, another source of the video data is = already present and the display can be seamlessly switched to the other = copy of the stream. This use case is alluded to in the document.=20 Another use case for multiple-topologies is to separate out different = types of traffic (say, latency sensitive traffic from larger, bulk, = flows). This is not alluded to in this document, and it is not clear to = what extent this was intended. These multiple topologies may or may not = result in the replication of data, and so may not be intended by the author. = However, I would say that this could be used to support this, and so it = will be. If there is some reason NOT to use this mechanism for this = purpose, some description of the reasons why would be in order.=20 This document sets up a numerical variable, the MT-ID Join Attribute, = to assign to multicast topologies, to be used to separate different = topologies for different paths. This number for a given multicast = topology need not be the same as any unicast multiple topology = identifiers, and similarly the multicast topologies and the underlying = unicast topologies may be different.=20 This document is sort, straight-forward, and relatively well-written. I = had a few non-fatal issues. (I would be glad to suggest some text for = any of these issues to the authors if they interested.)=20 Minor Issues : Section 3.2=20 "- As shown earlier, this value is not required to be the same as the = MT-ID used by the unicast routing protocols that contribute routes to = the topology. In practice, when only one unicast routing protocol (such = as OSPF or IS-IS) is used, the PIM MT-ID is RECOMMENDED to be assigned = using the same value as the IGP topology identifier. Using the same = example presented earlier, if every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to = name this RPF topology as PIM 1000 instead of PIM 500. This is for the = purpose of reducing management overhead and simplifying = troubleshooting." In the actual example, PIM 500 is not the same network topology as OSPF = 1000 (it has an extra link, to the source, obtained by MBGP). This is = specifically mentioned previously in the text. So, this is NOT the same = example as presented earlier and it is NOT clear that this = recommendation applies here.=20 If this is left as is, it will certainly confuse some people. I would = suggest adding text to clarify this, or creating another example where = the unicast and multicast topologies are the same. Section 4.2.3=20 "- There is at most 1 PIM MT-ID attribute encoded. If there are multiple = PIM MT-ID Join Attributes included, only the last one is accepted for = this particular source. Processing of the rest of the Join message = continues." Is this a typo ?=20 s/at most/at least/=20 would seem to be appropriate. (It says, "at most" 1, and then describes = what do to if there is more than 1.) Otherwise, please explain what is = meant. Section 6. The Labels for Section 6.1 and 6.2 are the same. I suspect this is just = a typo, and they should be 6.1. PIM-Hello Options 6.2. PIM Join Attribute Types More Substantive Issues : I had two substantive issues with this document.=20 1.) The range for the topologies. It is highly likely that the users of = this capability would want to use multiple topologies differently for = different multicast address ranges. For example, use of two topologies = is likely to be an expensive customer option, that not all customers = would pay for, and so would not apply to all multicast addresses. Or, = the backup typologies may (probably will be) tailored differently for = different customers in different locations. Or, topologies might be = tailored for different data types (different backups for real time video = conferencing versus TV broadcast transmissions, say). This is very = briefly alluded to in Section 3.1, but no consideration is given to = issues arising from this. For example, suppose I have two customers, and I wish to have one basic = topology (say, PIM 100) for 239.10/16, and I wish to have two backup = topologies for the two customers (say, PIM 1001 for 239.10.1/24 and PIM = 1002 for 239.10.2/24.) Can I have PIM 100 cover both the PIM 1001 and = PIM 1002 range ? Are there issues with this ? Would it be better to = split PIM 100 into pieces to match 1001 and 1002 ? Nothing like this is = discussed I can easily see interoperability issues arising from this (i.e., vendor = A might allow PIM 100 to overlap PIM 1001 and PIM 1002, and vendor B = might not). I think that some text to discuss the entire issue of = ranging (presumably, that they can be allowed and overlaps SHOULD be = supported) is needed. Again, this could be out of scope here, but, then, where will it appear = ?=20 2.) There is very little discussion as to how to use this capability. = Now, this might be considered out of scope for this document, but there = will be issues, and I do not see a follow-on in the pipeline.=20 Issues include sharing of links and the general connections between = topologies. It is likely that in real uses, a portion of the multiple = topologies may be either physically shared or directly linked. It may = not be possible to engineer out all single points of failure, for = example an undersea cable. This is possible with the first use case = (independent topologies for video) and likely with the second (different = topologies for different types of content).=20 Issues I see here include - the actual multicast data will not include any PIM attributes. How, = then, is a midpoint router receiving two copies of every packet know = that it shouldn't just drop one, and only populate one of the = downstreams ? Or, should it replicate one input into both downstream = topologies ? I can easily see interop issues here, and possibly even = more basic transport issues from replicated data.=20 - if at any point the two multicast topologies go through a shared LAN = or switch or any sort of multiple access network, how are the = topological flows going to be kept distinct. (This is similar to the = above, but the actual routers might be kept separate.)=20 - what happens with failovers ? If a link fails, SHOULD the backup links = not collapse the topologies ? Again, I think some thought and text would = be useful. If there is a solution to this, it may be simple (you MUST use tunnels) = or it may be complicated. In either case, some text here would be good.=20= Regards Marshall=20=