Re: [secdir] draft-ietf-behave-ftp64

Iljitsch van Beijnum <> Mon, 27 June 2011 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2C4621F85ED for <>; Mon, 27 Jun 2011 09:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H8bMsYKwdznM for <>; Mon, 27 Jun 2011 09:16:07 -0700 (PDT)
Received: from ( [IPv6:2001:1af8:3100:a006:1::]) by (Postfix) with ESMTP id 0E36321F85EC for <>; Mon, 27 Jun 2011 09:16:06 -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 (8.13.3/8.13.3) with ESMTP id p5RGGewt085252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 18:16:41 +0200 (CEST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Iljitsch van Beijnum <>
In-Reply-To: <>
Date: Mon, 27 Jun 2011 18:16:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Donald Eastlake <>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 27 Jun 2011 09:23:44 -0700
Subject: Re: [secdir] draft-ietf-behave-ftp64
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jun 2011 16:16:07 -0000

I've removed the CC to IESG, I think it's easier to first discuss this a bit more privately.

On 5 jun 2011, at 22:44, Donald Eastlake wrote:

> I have a bit of a problem with the title  ("An FTP ALG for
> IPv6-to-IPv4 translation") and the slant of some of the wording. It
> claims to be able to describe, as an Application Level Gateway,
> various recommendations which are then combined with a separate
> existing IPv6-to-IPv4 ALG. It talks about multiple ALGs being
> implemented at a single entity that are handling an single FTP
> session. This just all seems very odd to me as it isn't very clear
> what the interface between these different ALGs all somehow
> cooperating on one session is.

When you say "separate existing IPv6-to-IPv4 ALG" do you mean the NAT64 translator?

I included a few sentences about other FTP ALGs because I wanted to make the point that if you put multiple types of functionality in one big ALG, the side effect of the AUTH command must still be maintained even if using that command is not allowed by policy by "another ALG".

Do you agree that's useful? I guess I need to describe it better.

> I believe, in reality, anyone
> implementing this will take an existing ALG and modify it as suggested
> in the draft. The draft would therefore make more sense if written as
> suggested changes to a single ALG rather than as an additional ALG
> that is somehow compounded with an existing FTP ALG... Just my
> opinion.

Not sure how that would look in practice, though.

Thanks for the review,