Subject: [BEHAVE] FW: New Version Notification for draft-tsou-behave-ftp46-00.txt

From: Tina TSOU <[email-masked]>
Date: Fri, 15 Jun 2012 22:17:54 +0000

For your comments.

Tina
408-859-4996

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 15, 2012 3:10 PM
To: Tina TSOU
Cc: [email-masked]; Huangjing
Subject: New Version Notification for draft-tsou-behave-ftp46-00.txt

A new version of I-D, draft-tsou-behave-ftp46-00.txt
has been successfully submitted by Tina Tsou and posted to the
IETF repository.

Filename:	 draft-tsou-behave-ftp46
Revision:	 00
Title:		 An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation
Creation date:	 2012-06-15
WG ID:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-tsou-behave-ftp46-00.txt
Status:          http://datatracker.ietf.org/doc/draft-tsou-behave-ftp46
Htmlized:        http://tools.ietf.org/html/draft-tsou-behave-ftp46-00

Abstract:
   An FTP ALG for NAT64 was defined in RFC 6384.  Its scope was limited
   to an IPv6 client connecting to an IPv4 server.  This memo updates
   RFC 6384 with the case of an IPv4 client connecting to an IPv6
   server.

The IETF Secretariat

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Jun 2012 18:51:23 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tina TSOU
> Sent: Friday, June 15, 2012 3:18 PM
> To: [email-masked]
> Subject: [BEHAVE] FW: New Version Notification for draft-tsou-behave-
> ftp46-00.txt
> 
> For your comments.

Why use "EPSV 2", instead of just "EPSV"?  Using "EPSV 2" will
force another ALG, should there be another NAT64 or NAT46 along
the path (to convert it to "EPSV 1").

Draft should clearly say that active mode FTP is not intended
to work (or say it works only with passive FTP -- whichever
wording feels better).

Introduction:
   When the FTP server is behind NAT, it can publish its service address
   via a redirect server located in the internet, or via modified DDNS
.........^^^^^^^^^^^^^^^
what is a 'redirect server'?  A TCP redirector?  SOCKS??  FTP proxy??

   system, or other possible methods.  It is out of the scope of this
   memo.

Why is a _modified_ DDNS needed, and a normal Dynamic DNS inadequate?

Basically, I'm not seeing a need for all that uniqueness -- the IPv4-only
FTP server just needs to know its port number (hopefully, 21) and IPv6
address, and publish its URL (ftp://ftp.example.com:PORT).  That seems
the easiest example of how to make such an FTP server work, anyway.

Section 3, the Scenarios diagrams should more clearly show which 
devices are IPv4 and which are IPv6 -- right now it just shows "NAT"
and doesn't show if the FTP client or FTP server are IPv6 or IPv4.

IPv4 addresses should probably be in the IPv4 example range, rather
than 100.1.1.10.

The FTP64 ALG document included a command to disable the FTP64 ALG.
Should FTP46 have a similar command?

A security issue does exist with FTP passive mode -- connection
theft.  I believe there is an FTP document or two that explain 
that vulnerability.  Or see http://cr.yp.to/ftp/security.html

-d

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Jun 2012 09:05:02 -0400

Dan,

Thanks for the review. I'm skipping some of your comments (that are IMHO 
valid and will need to be addressed in the next revision).

On 2012-06-18 21:51, Dan Wing wrote:
> FTP server

Our use case is IPv6-only servers talking to IPv4-only clients through a 
NAT64. I'll shortly send slides for the interim meeting with diagrams 
that will hopefully make this clear.

> just needs to know its port number (hopefully, 21) and IPv6

The whole point of RFC 6384 was to allow unmodified FTP servers to work. 
Some servers work without an ALG, some don't. In the "v6 network to v4 
Internet" use case, the NAT64 operator has no control over the IPv4 
servers and cannot modify them. So the only thing it can do is use an ALG.

The same reasoning applies to our draft. An ISP deploying NAT64 has no 
control over the FTP server software that subscribers will be running. 
Some software will work fine without an ALG, but some won't. So the only 
thing that the ISP can do is run an ALG on the NAT64.

> Should FTP46 have a similar command?

Since we're proposing that our draft update RFC 6384, the ALGS command 
will also apply. Maybe we need to extend it. At the very least we need 
text saying that it still applies. We'll look into it for the next revision.

> that vulnerability.  Or see http://cr.yp.to/ftp/security.html

Isn't that already covered by RFC 6384's security considerations section?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Jun 2012 07:06:27 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2012 6:05 AM
> To: Dan Wing
> Cc: 'Tina TSOU'; [email-masked]
> Subject: Re: [BEHAVE] FW: New Version Notification for draft-tsou-
> behave-ftp46-00.txt
> 
> Dan,
> 

Yes, because there is significant existing deployment of IPv4 FTP 
servers.  But there is no significant existing deployment of IPv6 
FTP servers.  So I'm not sure the same logic needs to apply.

And in 2012 an FTP URI is not unreasonable.

> thing that the ISP can do is run an ALG on the NAT64.

So, are you saying the IPv4 host will have to listen on port 21?  Are
you saying the ISP -- as part of their ALG -- will have to listen on
port 21, or will have to listen on some alternate port?

> text saying that it still applies. We'll look into it for the next

By extending RFC6384, is there an expectation that every FTP64 ALG
also implement the FTP46 ALG?

> Isn't that already covered by RFC 6384's security considerations

I dunno.  But a 'RFC6384's security considerations applies to
this document' doesn't hurt.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Jun 2012 10:41:19 -0400

> FTP servers.  So I'm not sure the same logic needs to apply.

Deployment base doesn't matter in our case. As soon as an ISP puts 
subscribers behind a NAT64, their FTP servers will go from IPv4 to IPv6. 
And given that current FTP server software generally includes IPv6 
support, they will just continue using the same software. Just the act 
of turning on a NAT64 will create IPv6-only FTP servers.

> And in 2012 an FTP URI is not unreasonable.

I'm not sure what you're getting at.

>> Some software will work fine without an ALG, but some won't. So the
>> only thing that the ISP can do is run an ALG on the NAT64.
>
> So, are you saying the IPv4 host will have to listen on port 21?

The FTP server is IPv6, not IPv4.

> Are you saying the ISP -- as part of their ALG -- will have to listen on

No.

We assume that not all subscribers can get port 21. They will need to 
use another port. They can use PCP or whatever else to open a port on 
the NAT64. Users are already trained to open a port in their home NAT, 
with UPnP-enabled FTP server software or statically-configured port 
redirection.

Furthermore, this is a generic problem that happens whenever you mix 
well-known port numbers with NAT. It is not specific to our draft, FTP, 
or even to NAT64. So we do not try to address it in our draft.

> also implement the FTP46 ALG?

No.

> this document' doesn't hurt.

We will definitely add that.

Thanks,
Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 19 Jun 2012 07:57:08 -0700

> Sent: Tuesday, June 19, 2012 7:41 AM
> To: Dan Wing
> >> servers and cannot modify them. So the only thing it can do is use
> an
> >> ALG.
> >

Your I-D provides no guidance on how the incoming TCP/21 connection
is expected to work with the NAT64.

But I do now understand why your document explains the ALG has to
create a mapping; I previously did not understand that.  Thanks.

> I'm not sure what you're getting at.

The difficulty in everyone running an FTP server getting port 21,
which seemed tied to your statement that FTP clients and FTP
servers need to remain un-changed.

> The FTP server is IPv6, not IPv4.

Sorry for my confusion.

Pretend I asked,

  So, are you saying the IPv6 host will have to listen on port 21?

> > also implement the FTP46 ALG?

I'm puzzled by the extension (I presume, "Update:" in the header), then.
But that's a small nit in the scheme of things.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Jun 2012 11:13:44 -0400

> is expected to work with the NAT64.

This paragraph was intended to provide such guidance:

It goes without saying that this will be much improved in the next 
revision. :)

>    So, are you saying the IPv6 host will have to listen on port 21?

That's what I did in my answer below. :)

> But that's a small nit in the scheme of things.

Maybe my understanding of what "Update:" means is broken. Let's look at 
RFC2223...

       To be used as a reference from a new item that cannot be used
       alone (i.e., one that supplements a previous document), to refer
       to the previous document.  The newer publication is a part that
       will supplement or be added on to the existing document; e.g., an
       addendum, or separate, extra information that is to be added to
       the original document.

Well, that's exactly what we mean!

Simon

---

From: Dave Thaler <[email-masked]>
Date: Tue, 19 Jun 2012 19:29:37 +0000

> Well, that's exactly what we mean!

A normative reference is one that you depend on.

Updates is used only when you are actually changing something in that document,
rather than just layering over or reusing a piece of it.

-Dave