Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-15 Thread Kirk Wolf 
On Fri, Jun 12, 2020 at 3:56 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 12 Jun 2020 20:46:49 +, Jackson, Rob wrote:
>
> >Before I found out about Co:Z I used shell scripts and REXX in OMVS to
> copy the files back and forth from MVS datasets to OMVS file systems (if
> sending to the mainframe, they would follow up the copy with a SSH and
> execute a script with a table of DSNs with DCBs to copy to a MVS dataset .
> . . or supply their own DCB and dataset name).  It was very cumbersome
> indeed.  Co:Z makes all that go away; it's simple to install, implement,
> and use.  Highly recommended.
> >
> How does it handle a program object library in a PDSE?  Or should
> I presume FSVO "makes all that go away"?
>
> Release 6.0.0 of Co:Z SFTP supports sending PDS and PDSE libraries

Kirk Wolf
Dovetailed Technologies
http://dovetail.com
Download and use Co:Z SFTP free under our Community License
http://dovetail.com/support.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-13 Thread Jackson, Rob 
A yeah, my bad, that looks right.  Details do count.  I was going from faulty 
memory.  :)  Thanks!

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Saturday, June 13, 2020 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

[External Email. Exercise caution when clicking links or opening attachments.]

THANK YOU. Yes, PASSIVEIGNOREADDR is the key (and BTW you can then eliminate 
CCC with its security exposure).

Shows what a kludge FTP is. The client says "Let's go into passive mode. Tell 
me what IP address to use, and I will ignore it. Thank you. Because after all, 
I already know your IP address."

BTW, with EPSV4 I do *not* see 227 response would be (, , , ,8,106). Instead I 
see a 229 response:

EZA1701I >>> EPSV
SC3311 getReply: entered
SC4479 getNextReply: entered with waitForData = TRUE
229 Entering Extended Passive Mode (|||2158|)
SC5291 epsvReply: entered
SC5209 parseEPSVreply: entered
SC5221 parseEPSVreply: tmpreply 229 Entering Extended Passive Mode (|||2158|)
SC5240 parseEPSVreply: i 9 tmpstr (|||2158|)
SC5249 parseEPSVReply: delimiter is |/4f

But no matter. EPSV4 seems to be a nice-to-have. PASSIVEIGNOREADDR is the key.

For anyone following this thread who is wondering what the heck I have been 
talking about there is a good (non-mainframe, but it is the same issue) 
explanation here:

https://bit.ly/2Yv0BOp

> My cruddy email application (Outlook) doesn't do the >-style quoting

Yeah, I always just do it by hand in Outlook. I have a > key.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Rob
Sent: Saturday, June 13, 2020 6:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

My cruddy email application (Outlook) doesn't do the >-style quoting (or at 
least I don't know how to make it), so let me try below with tabs; it will 
probably be ugly.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills


Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered
SC2848 sendCmd: entered
EZA1701I >>> PASV
SC3311 getReply: entered
SC4479 getNextReply: entered with waitForData = TRUE
227 Entering Passive Mode (10,200,40,20,8,106)

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

Correct, the 227 is the server response.  The first four 
comma-delimited bytes-in-decimal are the server IP; the second two are the 
port:  256*8+106.

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.

Perfect; that should make it easier.
In SYSFTPD on the client side, the first of the below sets PASV; you 
have that.  The second
tells the client to ignore the returned IP and stick with the one it 
opened;
the third tells the server to use EPSV and not to respond with one in 
the first place (227 response would be (, , , ,8,106))
FWFRIENDLY  TRUE;
PASSIVEIGNOREADDR TRUE;
EPSV4 TRUE;

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-13 Thread Charles Mills 
THANK YOU. Yes, PASSIVEIGNOREADDR is the key (and BTW you can then eliminate 
CCC with its security exposure).

Shows what a kludge FTP is. The client says "Let's go into passive mode. Tell 
me what IP address to use, and I will ignore it. Thank you. Because after all, 
I already know your IP address."

BTW, with EPSV4 I do *not* see 227 response would be (, , , ,8,106). Instead I 
see a 229 response:

EZA1701I >>> EPSV  
SC3311 getReply: entered   
SC4479 getNextReply: entered with waitForData = TRUE   
229 Entering Extended Passive Mode (|||2158|)  
SC5291 epsvReply: entered  
SC5209 parseEPSVreply: entered 
SC5221 parseEPSVreply: tmpreply 229 Entering Extended Passive Mode (|||2158|)  
SC5240 parseEPSVreply: i 9 tmpstr (|||2158|)   
SC5249 parseEPSVReply: delimiter is |/4f   

But no matter. EPSV4 seems to be a nice-to-have. PASSIVEIGNOREADDR is the key.

For anyone following this thread who is wondering what the heck I have been 
talking about there is a good (non-mainframe, but it is the same issue) 
explanation here:

https://bit.ly/2Yv0BOp

> My cruddy email application (Outlook) doesn't do the >-style quoting

Yeah, I always just do it by hand in Outlook. I have a > key.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Rob
Sent: Saturday, June 13, 2020 6:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

My cruddy email application (Outlook) doesn't do the >-style quoting (or at 
least I don't know how to make it), so let me try below with tabs; it will 
probably be ugly.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills


Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered
SC2848 sendCmd: entered
EZA1701I >>> PASV
SC3311 getReply: entered
SC4479 getNextReply: entered with waitForData = TRUE
227 Entering Passive Mode (10,200,40,20,8,106)

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

Correct, the 227 is the server response.  The first four 
comma-delimited bytes-in-decimal are the server IP; the second two are the 
port:  256*8+106.

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.

Perfect; that should make it easier.
In SYSFTPD on the client side, the first of the below sets PASV; you 
have that.  The second
tells the client to ignore the returned IP and stick with the one it 
opened;
the third tells the server to use EPSV and not to respond with one in 
the first place (227 response would be (, , , ,8,106))
FWFRIENDLY  TRUE;  
PASSIVEIGNOREADDR TRUE;
EPSV4 TRUE;

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-13 Thread Jackson, Rob 
My cruddy email application (Outlook) doesn't do the >-style quoting (or at 
least I don't know how to make it), so let me try below with tabs; it will 
probably be ugly.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills


Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered
SC2848 sendCmd: entered
EZA1701I >>> PASV
SC3311 getReply: entered
SC4479 getNextReply: entered with waitForData = TRUE
227 Entering Passive Mode (10,200,40,20,8,106)

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

Correct, the 227 is the server response.  The first four 
comma-delimited bytes-in-decimal are the server IP; the second two are the 
port:  256*8+106.

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.

Perfect; that should make it easier.
In SYSFTPD on the client side, the first of the below sets PASV; you 
have that.  The second
tells the client to ignore the returned IP and stick with the one it 
opened;
the third tells the server to use EPSV and not to respond with one in 
the first place (227 response would be (, , , ,8,106))
FWFRIENDLY  TRUE;  
PASSIVEIGNOREADDR TRUE;
EPSV4 TRUE;

- I guess "IBM" SFTP does not support legacy datasets but Dovetail SFTP does? 
Is that right?

Right, including GDSs.  The only thing I can't make it do is wildcard 
DSNs, though wildcarding OMVS files is fine.

- Big question on SFTP: does it support anything like SITE FILETYPE=JES/GET 
jcl_file system_messages ? That is, submit a job and wait for completion? 
Without that it is a re-architecting, not a re=writing project.

The manual says it supports JES2 and JES3 job submissions, status, and 
spool-file transfers; I've never tried this.

- No program objects at this point but possibly in the future.

It supports PDSE; I've never had a need to send a program object from 
distributed to MVS or vice versa, so I dunno about that.

- Yes, having to install another product is a HUGE obstacle. Not impossible, 
not saying Dovetail is not wonderfulness, just the reality of sales is that 
"you have to install this other product in order to try our product" is always 
a huge obstacle.

But it is free, and it's so good, we've never had to have support 
(sorry, Kirk).

- > FTP's dual port architecture is simply a nightmare. Yeah, it always seemed 
so to me. Why do you need two sessions -- by default initiated in opposite 
directions -- to transfer both files and control information?

I agree!

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Gibney, Dave 
In my case, it  was and is long stable FTPS jobs using standard files and no 
knowledgeable staff with time to refit to stfp.
 About a decade ago, I experimented with the idea of wrapping a PROC around the 
whole process.  Ran out of available time to solve all issues.
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Gilmartin
> Sent: Friday, June 12, 2020 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: How is Passive FTP with TLS and NAT supposed to work?
> 
> On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:
> 
> >Aside from, I think this is still true, absent Dovetail extensions, the
> >requirement that SFTP only works with ZFS/HFS files
> >>
> What's the intended recipient?  If desktop or Open Systems, zFS/HFS should
> be acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO
> TRANSMIT; copy to zFS and SFTP.
> 
> >> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and
> >> life gets much easier--most of the time.
> 
> There's some echo here of the "retire mainframe" thread.  z/OS doesn't
> "play well with others."
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Charles Mills 
I am gathering from reading the RFC that that 227 Entering Passive Mode 
(10,200,40,20,8,106) is a verbatim message from the server, and for the 
question "what *does* the server send?" the answer is "that 227 message."

Is that correct?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Friday, June 12, 2020 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered 
SC2848 sendCmd: entered  
EZA1701I >>> PASV
SC3311 getReply: entered 
SC4479 getNextReply: entered with waitForData = TRUE 
227 Entering Passive Mode (10,200,40,20,8,106)   

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.
- I guess "IBM" SFTP does not support legacy datasets but Dovetail SFTP does? 
Is that right? 
- Big question on SFTP: does it support anything like SITE FILETYPE=JES/GET 
jcl_file system_messages ? That is, submit a job and wait for completion? 
Without that it is a re-architecting, not a re=writing project.
- No program objects at this point but possibly in the future.
- Yes, having to install another product is a HUGE obstacle. Not impossible, 
not saying Dovetail is not wonderfulness, just the reality of sales is that 
"you have to install this other product in order to try our product" is always 
a huge obstacle.
- > FTP's dual port architecture is simply a nightmare. Yeah, it always seemed 
so to me. Why do you need two sessions -- by default initiated in opposite 
directions -- to transfer both files and control information?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Charles Mills 
Thanks all! Thanks much! Let me try to do one reply here to hold down the noise.

> active mode is the one using PORT; passive mode uses PASV

Thank you! It's a detail but I want to have the details right. Details are of 
the essence here. What *exactly* does the server send? On the client end I see

SC1373 initDsConnection: entered 
SC2848 sendCmd: entered  
EZA1701I >>> PASV
SC3311 getReply: entered 
SC4479 getNextReply: entered with waitForData = TRUE 
227 Entering Passive Mode (10,200,40,20,8,106)   

Where *exactly* did the client get that 10.200.40.20 from? What *does* the 
serve send to convey "open your data connection on this address"?

In other news:

- "Switching to another type of FTP" is non-trivial because the use of FTP is 
embedded in another product that builds control files on the fly. It would be a 
development project to use "a different FTP." Not out of the question, but a 
development project nonetheless.
- Both ends are z/OS FWIW. There is a mix of "legacy" and zFS. That is all 
under control presently.
- I guess "IBM" SFTP does not support legacy datasets but Dovetail SFTP does? 
Is that right? 
- Big question on SFTP: does it support anything like SITE FILETYPE=JES/GET 
jcl_file system_messages ? That is, submit a job and wait for completion? 
Without that it is a re-architecting, not a re=writing project.
- No program objects at this point but possibly in the future.
- Yes, having to install another product is a HUGE obstacle. Not impossible, 
not saying Dovetail is not wonderfulness, just the reality of sales is that 
"you have to install this other product in order to try our product" is always 
a huge obstacle.
- > FTP's dual port architecture is simply a nightmare. Yeah, it always seemed 
so to me. Why do you need two sessions -- by default initiated in opposite 
directions -- to transfer both files and control information?

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Paul Gilmartin 
On Fri, 12 Jun 2020 20:46:49 +, Jackson, Rob wrote:

>Before I found out about Co:Z I used shell scripts and REXX in OMVS to copy 
>the files back and forth from MVS datasets to OMVS file systems (if sending to 
>the mainframe, they would follow up the copy with a SSH and execute a script 
>with a table of DSNs with DCBs to copy to a MVS dataset . . . or supply their 
>own DCB and dataset name).  It was very cumbersome indeed.  Co:Z makes all 
>that go away; it's simple to install, implement, and use.  Highly recommended.
>
How does it handle a program object library in a PDSE?  Or should
I presume FSVO "makes all that go away"?

Must both the sender and the recipient have Co:Z installed?  That might
be a business obstacle.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Jackson, Rob 
Before I found out about Co:Z I used shell scripts and REXX in OMVS to copy the 
files back and forth from MVS datasets to OMVS file systems (if sending to the 
mainframe, they would follow up the copy with a SSH and execute a script with a 
table of DSNs with DCBs to copy to a MVS dataset . . . or supply their own DCB 
and dataset name).  It was very cumbersome indeed.  Co:Z makes all that go 
away; it's simple to install, implement, and use.  Highly recommended.

First Horizon Bank
Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, June 12, 2020 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

[External Email. Exercise caution when clicking links or opening attachments.]

On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:

>Aside from, I think this is still true, absent Dovetail extensions, the 
>requirement that SFTP only works with ZFS/HFS files
>>
What's the intended recipient?  If desktop or Open Systems, zFS/HFS should be 
acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO TRANSMIT; copy 
to zFS and SFTP.

>> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and 
>> life gets much easier--most of the time.

There's some echo here of the "retire mainframe" thread.  z/OS doesn't "play 
well with others."

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Paul Gilmartin 
On Fri, 12 Jun 2020 18:21:47 +, Gibney, Dave wrote:

>Aside from, I think this is still true, absent Dovetail extensions, the 
>requirement that SFTP only works with ZFS/HFS files
>>  
What's the intended recipient?  If desktop or Open Systems, zFS/HFS should
be acceptable.  If z/OS, cumbersomely flatten with TRSMAIN or TSO TRANSMIT;
copy to zFS and SFTP.

>> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life 
>> gets
>> much easier--most of the time.

There's some echo here of the "retire mainframe" thread.  z/OS doesn't "play
well with others."

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Seymour J Metz 
I've never understood why RFC 4960 Stream Control Transmission Protocol (SCTP) 
didn't catch on and get exploited by a new FTP protocol.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jackson, Rob [rwjack...@firsthorizon.com]
Sent: Friday, June 12, 2020 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How is Passive FTP with TLS and NAT supposed to work?

Well, your point is made und understood, but active mode is the one using PORT; 
passive mode uses PASV.  They both have their FW/load balancer issues.

We tend to use a variety of "fixes" for the various issues, given our 
convoluted (typical?) environment.  EPSV can help.  Some clients have the 
option to ignore PASV IP returned.  Our load balancers host our server certs in 
some cases so they can decrypt and modify the IP.  Our MFT proxy cluster has 
multiple nodes of FTP server adapter pairs, and each can be defined to return 
the same IP in the PASV response (they are session-break proxies, so they don't 
use the MFT servers' certs for encryption; they use their own); this IP would 
be the exposed forwarding VIP on the internet.

There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life gets 
much easier--most of the time.

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, June 12, 2020 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How is Passive FTP with TLS and NAT supposed to work?

[External Email. Exercise caution when clicking links or opening attachments.]

X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both urgent 
for us and perhaps a little obscure.

With Passive FTP, the server uses a PORT command to say to the client "open the 
data connection on this IP address." Unfortunately with NAT that is an internal 
address that is meaningless at the client. Many firewalls or routers that 
support NAT are apparently smart enough to translate that PORT command from an 
internal to an external address, and everything works wonderfully.

The wrinkle comes with TLS: the control connection is encrypted and 
inaccessible to the firewall or router.

Enter CCC:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
lz001/ftpcastlsrfclevel.htm
https://secure-web.cisco.com/1XiMpdy7YXR-qJrSax9Cfz6Tkc-XqxJhBDV0eW0mQfjMw62un15xXVivwXbA9XzBQA0DcZVGFk4rkS8GCnMjxCrQ1C9CF_Gzg7xXzRAzLCCC8ec_rGjSEBfqJhBLPCvzNvJ3QH5UJMjevLqbV3NzuRnnQ3wWgu_Mw6x60j6INpAC8VNwQcHaZTqvxgPK0g00dy68Nu9hbVhUiGXPWOz-cZ2EgKIKYmU9Vn5VE3UxQ5arhR8dF2xQEKrOKz_oS1SAPS-rG5dI8Nvn0wpwUMUzh7wmoQ3xrqNqiczFA6gczyF-bStlOQYaMkNEa6rDmthBjsHuJhap6js7FB-ftEM0Ua8_WgotL7MuMsogUVDS69DGPq8y2JnseDH0nMtLCN6_SH960zKssv5t9STlJY09k8xal2jrt3A9T5FhwPUOpX1idMpkolxOldKP4G_qSgzHK9RJz652lxNFv0LerbUbYgA/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4217#page-19

CCC says "stop encrypting the control connection (so the router or firewall can 
see and translate it).

Apparently -- and this is where my knowledge gets fuzzy -- the RFC now requires 
that the partners close the control connection at that point, but z/OS FTP 
perhaps does not support that (?).

CCC has security red flags all over it, which is understandable, and it looks 
like we may be encountering a firewall or router that does not support it, or 
perhaps does not support the non-RFC version of it.

I am asking here "what is the 'right' answer?" How is passive FTP supposed to 
work over a TLS session with NAT in effect?

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Gibney, Dave 
We live behind an f5 Load Balancer. It knows our certificates and can 
decrypt/recrypt to determine the PORT. We flat don't do active FTPS

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Friday, June 12, 2020 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How is Passive FTP with TLS and NAT supposed to work?
> 
> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
> 
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or routers
> that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
> 
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
> 
> Enter CCC:
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha__;!!JmPEgBY0HMszNaDT!4GFT57hI
> EMxPnyEcFR2djCexl1wVxTZKmL93Rb-QYqbEZ85Iosv_oseQGLlj0A$
> lz001/ftpcastlsrfclevel.htm
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4217*page-
> 19__;Iw!!JmPEgBY0HMszNaDT!4GFT57hIEMxPnyEcFR2djCexl1wVxTZKmL93R
> b-QYqbEZ85Iosv_osfVrkck8g$
> 
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
> 
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
> 
> CCC has security red flags all over it, which is understandable, and it looks 
> like
> we may be encountering a firewall or router that does not support it, or
> perhaps does not support the non-RFC version of it.
> 
> I am asking here "what is the 'right' answer?" How is passive FTP supposed to
> work over a TLS session with NAT in effect?
> 
> Charles
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Gibney, Dave 
Aside from, I think this is still true, absent Dovetail extensions, the 
requirement that SFTP only works with ZFS/HFS files
> 
> There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life 
> gets
> much easier--most of the time.
> 
> First Horizon Bank
> Mainframe Technical Support
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: Friday, June 12, 2020 2:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How is Passive FTP with TLS and NAT supposed to work?
> 
> [External Email. Exercise caution when clicking links or opening attachments.]
> 
> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
> 
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or routers
> that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
> 
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
> 
> Enter CCC:
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha__;!!JmPEgBY0HMszNaDT!-
> 06qLbj3iAJvLUmVpYTxCYdOLC2h3vao1713bsoyuv6dekXwEPzQAxiTIwQt9Q$
> lz001/ftpcastlsrfclevel.htm
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc4217*page-
> 19__;Iw!!JmPEgBY0HMszNaDT!-
> 06qLbj3iAJvLUmVpYTxCYdOLC2h3vao1713bsoyuv6dekXwEPzQAxhEdET62Q$
> 
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
> 
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
> 
> CCC has security red flags all over it, which is understandable, and it looks 
> like
> we may be encountering a firewall or router that does not support it, or
> perhaps does not support the non-RFC version of it.
> 
> I am asking here "what is the 'right' answer?" How is passive FTP supposed to
> work over a TLS session with NAT in effect?
> 
> Charles
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality
> notice:
> This e-mail message, including any attachments, may contain legally
> privileged and/or confidential information. If you are not the intended
> recipient(s), or the employee or agent responsible for delivery of this
> message to the intended recipient(s), you are hereby notified that any
> dissemination, distribution, or copying of this e-mail message is strictly
> prohibited. If you have received this message in error, please immediately
> notify the sender and delete this e-mail message from your computer.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Kirk Wolf 
How about after throwing firewalls in to the mix?   FTP's dual port
architecture is simply a nightmare.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Fri, Jun 12, 2020 at 1:01 PM Charles Mills  wrote:

> X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both
> urgent for us and perhaps a little obscure.
>
> With Passive FTP, the server uses a PORT command to say to the client "open
> the data connection on this IP address." Unfortunately with NAT that is an
> internal address that is meaningless at the client. Many firewalls or
> routers that support NAT are apparently smart enough to translate that PORT
> command from an internal to an external address, and everything works
> wonderfully.
>
> The wrinkle comes with TLS: the control connection is encrypted and
> inaccessible to the firewall or router.
>
> Enter CCC:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
> lz001/ftpcastlsrfclevel.htm
> 
> https://tools.ietf.org/html/rfc4217#page-19
>
> CCC says "stop encrypting the control connection (so the router or firewall
> can see and translate it).
>
> Apparently -- and this is where my knowledge gets fuzzy -- the RFC now
> requires that the partners close the control connection at that point, but
> z/OS FTP perhaps does not support that (?).
>
> CCC has security red flags all over it, which is understandable, and it
> looks like we may be encountering a firewall or router that does not
> support
> it, or perhaps does not support the non-RFC version of it.
>
> I am asking here "what is the 'right' answer?" How is passive FTP supposed
> to work over a TLS session with NAT in effect?
>
> Charles
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How is Passive FTP with TLS and NAT supposed to work?

2020-06-12 Thread Jackson, Rob 
Well, your point is made und understood, but active mode is the one using PORT; 
passive mode uses PASV.  They both have their FW/load balancer issues.

We tend to use a variety of "fixes" for the various issues, given our 
convoluted (typical?) environment.  EPSV can help.  Some clients have the 
option to ignore PASV IP returned.  Our load balancers host our server certs in 
some cases so they can decrypt and modify the IP.  Our MFT proxy cluster has 
multiple nodes of FTP server adapter pairs, and each can be defined to return 
the same IP in the PASV response (they are session-break proxies, so they don't 
use the MFT servers' certs for encryption; they use their own); this IP would 
be the exposed forwarding VIP on the internet.

There are other things, I'm sure I'm forgetting.  Switch to SFTP, and life gets 
much easier--most of the time. 

First Horizon Bank
Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Friday, June 12, 2020 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: How is Passive FTP with TLS and NAT supposed to work?

[External Email. Exercise caution when clicking links or opening attachments.]

X-Posted IBMMAIN and IBMTCP. Apologies. This is a question that is both urgent 
for us and perhaps a little obscure.

With Passive FTP, the server uses a PORT command to say to the client "open the 
data connection on this IP address." Unfortunately with NAT that is an internal 
address that is meaningless at the client. Many firewalls or routers that 
support NAT are apparently smart enough to translate that PORT command from an 
internal to an external address, and everything works wonderfully.

The wrinkle comes with TLS: the control connection is encrypted and 
inaccessible to the firewall or router.

Enter CCC:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ha
lz001/ftpcastlsrfclevel.htm
https://tools.ietf.org/html/rfc4217#page-19

CCC says "stop encrypting the control connection (so the router or firewall can 
see and translate it).

Apparently -- and this is where my knowledge gets fuzzy -- the RFC now requires 
that the partners close the control connection at that point, but z/OS FTP 
perhaps does not support that (?).

CCC has security red flags all over it, which is understandable, and it looks 
like we may be encountering a firewall or router that does not support it, or 
perhaps does not support the non-RFC version of it.

I am asking here "what is the 'right' answer?" How is passive FTP supposed to 
work over a TLS session with NAT in effect?

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN