Secure FTP on the Mainframe

There is an RFC about the problems converting FTP from arpanet (host protocol) to IP (internetworking protocol).

Arpanet had a lot of similarities to JES2 networking ... homogeneous networking, host to front end processor (in arpanet case, called an IMP), limited number of nodes, no gateway functionality, etc.

some minor references (the following NCP references is not to the mainframe variety):

the above makes reference to RFC721 ... out-of-band control signals in a host-to-host protocol ... and some of the difficulties of converting application like FTP to TCP.

from my RFC index

summery for RFC 721

721 Out-of-band control signals in a Host-to-Host Protocol, Garlick L., 1976-09-01 (7pp) (.txt=13566) (Refs 675)

as always ... clicking on the ".txt=nnnn" field in an rfc summary fetches the actual RFC.

now, the internal network

originated at science center

in many ways was a lot more robust ... didn't have the network size limitation and effectively had a type of gateway function in every node. this contributed to the internal network being larger than the arpanet-internet into approx. summer of 1985. the big change in the arpanet was the great cahnge over on 1-1-83 to internetworking protocol ... and getting gateway functionality. arpanet had almost its limited of 255 nodes at the switchover.

jes2 sort of had 255 node limitations ... jes2 networking had come from hasp ... quite a bit having been originated at TUCC. They used the hasp psuedo device table to define nodes. A typical hasp-jes2 installation might have 60-80 psuedo devices defined ... so that actually only left maybe 170-190 positions for defining network nodes.

jes2 had (at least) two problems ... one was that network control information was all jumbled up with other control information in the header and it would trash any incoming traffic if either the origin node or the destination node were not defined in the limited table.

shortly after the 1-1-83 conversion to internetworking protocol, the internal network pbutted 1000 nodes

and was way beyond any JES2 network addressing capability at the time.

because of the tendency for trashing traffic where it didn't have the origin and-or destination nodes defined ... and its inability to even come close to defining all the nodes in the internal network ... jes2 nodes were pretty much relegated to boundary nodes.

the other problem was the jumbling of information in jes2 control headers. a jes2 system at a different version or release level could have slightly different header definition and result in crashing other jes2 systems and bringing the whole mvs systems crashing down.

the standard internal networking software developed a extensive library of gateway code for different hasp and jes2 releases and versions. When a jes2 system would crash bringing down the mvs system, it would frequently be blaimed on the standard internal networking software not correctly protecting one jes2 from another jes2. It quickly became the responsibility of the gateway code in the standard internal networking nodes to correctly re-arrainge jes2 header information to correspond to the version-level of the jes2 system it was directly communicating with (regardless of what jes2 system that such trafic might have originated with).

--