Re: Reverse NAT and Masquerade Question

Steven J. Hathaway wrote:
> This is a network feasibility question.
>
> Do you know which of the following firewalls can perform a reverse
> address translation?
>
> Checkpoint Firewall-1
> Netfilter (IPtables)
> CISCO IOS Firewall
> CISCO PIX Firewall
>
> The issue is to map a specific external IP address or transport domain
> address onto a
> local network IP address. The result of which would allow a workstation
> or server on the
> local network to establish a session to a remote host by virtue of
> addressing data to the
> virtualized local IP address.
>
> [snip]

They can all do one-to-one NAT. Depending upon how your ISP connection
is configured, you may also need to set up proxy arp for the "virtual"
addresses (if they're truly virtual).

One-to-one means just that. One external address to one internal
address. There's no dynamic remapping like many-to-one (10.x internal
with a single external). So if you want a bunch of machines to be
visable externally, you need that many IP addresses, generally.
(Sometimes you can overlap if each internal machine offers different
services, but that's getting a bit trickier than your question.)

Allen Kistler wrote:

> Steven J. Hathaway wrote:
> > This is a network feasibility question.
> >
> > Do you know which of the following firewalls can perform a reverse
> > address translation?
> >
> > Checkpoint Firewall-1
> > Netfilter (IPtables)
> > CISCO IOS Firewall
> > CISCO PIX Firewall
> >
> > The issue is to map a specific external IP address or transport domain
> > address onto a
> > local network IP address. The result of which would allow a workstation
> > or server on the
> > local network to establish a session to a remote host by virtue of
> > addressing data to the
> > virtualized local IP address.
> >
> > [snip]
>
> They can all do one-to-one NAT. Depending upon how your ISP connection
> is configured, you may also need to set up proxy arp for the "virtual"
> addresses (if they're truly virtual).
>
> One-to-one means just that. One external address to one internal
> address. There's no dynamic remapping like many-to-one (10.x internal
> with a single external). So if you want a bunch of machines to be
> visable externally, you need that many IP addresses, generally.
> (Sometimes you can overlap if each internal machine offers different
> services, but that's getting a bit trickier than your question.)

My problem is not the forward-nat addressing that firewall devices implement.

Reverse-nat is independent of the number of IP addresses a service provider
gives you for communications. Dial-up point-to-point connections with
dynamic IP assignment should also work.

A trivial example of what I am looking for is to allow local machines to
access an external DNS server without having to know its public IP address
or DNS name. All the local machines need to do is to place in their
configuration files the virtual local IP address that is NAT translated
to some external DNS.

Then when the remote DNS fails - functionality can be restored by creating
another reverse=nat mapping to a functional DNS elsewhere. I then do not
have to reconfigure the local machines for DNS access.

My true requrements go beyond this trivial DNS example.

- Steve Hathaway

> A trivial example of what I am looking for is to allow local machines to
> access an external DNS server without having to know its public IP address
> or DNS name. All the local machines need to do is to place in their
> configuration files the virtual local IP address that is NAT translated
> to some external DNS.
>
> Then when the remote DNS fails - functionality can be restored by creating
> another reverse=nat mapping to a functional DNS elsewhere. I then do not
> have to reconfigure the local machines for DNS access.

iptables that comes with the 2.4 kernel can do that. We have a Linux
Security Server set up (from www.ComputerSecurityResearch.com, if that
matters) that does the DNAT just as your example needs. All the internal
boxes have their DNS pointing to the security server, and it in turn it
DNATs the DNS requests out to the current DNS server. If that DNS server
starts acting buggy we just make one change on the security server and all
the clients benefit from the change. Sounds like just what you need.

Now here's one hitch I can see, and I see the way around it. Let's say you
have networks A and B, each with more than one machine, and each with only
one public IP (or IP that will be used to link them together). So computer
A.1 wants to connect to B.1, the security server for A correctly changes the
destination IP to B's public IP. B's security server gets this packet and
doesn't know which internal computer to send it to.

The way around it is what we've done with this security server. A's and B's
security servers create an IPSEC tunnel between them and have route entries
that say "anything for B's net - route to B's IPSEC IP" and likewise for A.
Works like a charm because their isn't any DNAT involved. You wouldn't need
the tunnel, we just needed the data to be secure between the networks.

In the case where you have A, B, and C *and* two networks (say B and C) have
the same private address range, you have the combination of the two examples
above put together. A's network thinks B's and C's networks are actually
different, and a DNAT translation happens on B's and C's security servers.
What you end up with is a "global address map" that says network A has this
"public" range (not true public, but only used once within all your
networks), B has this "public" range, etc... Then anything destined for A
will be addressed to that "public" range, and A's security server is
expected to do the DNAT to the real internal IP address.

It's complicated, but it works. And none of our local nets had to get
renumbered.

One thing that stinks is the one-to-one NAT. Each box has one line DNAT,
and one line SNAT per internal IP. The nice thing here is the only NAT is
happening on the security server responsible for those IPs. This lets us
add more IPs to a network without having to go change all the security
servers, we just change the one that manages that network. And the load of
doing the NAT is on the local security server, so if we have a new local
network with thousands of IPs, we get a more powerful (as in CPU/mem)
security server just for that network, we don't have to upgrade the whole
infrastructure to support the increase in NATs of more IPs. That security
server is the only one that realizes the load of those additional IPs and
their resultant NATs.

no body wrote:

> > A trivial example of what I am looking for is to allow local machines to
> > access an external DNS server without having to know its public IP address
> > or DNS name. All the local machines need to do is to place in their
> > configuration files the virtual local IP address that is NAT translated
> > to some external DNS.
> >
> > Then when the remote DNS fails - functionality can be restored by creating
> > another reverse=nat mapping to a functional DNS elsewhere. I then do not
> > have to reconfigure the local machines for DNS access.
>
> iptables that comes with the 2.4 kernel can do that. We have a Linux
> Security Server set up (from www.ComputerSecurityResearch.com, if that
> matters) that does the DNAT just as your example needs. All the internal
> boxes have their DNS pointing to the security server, and it in turn it
> DNATs the DNS requests out to the current DNS server. If that DNS server
> starts acting buggy we just make one change on the security server and all
> the clients benefit from the change. Sounds like just what you need.
>
> Now here's one hitch I can see, and I see the way around it. Let's say you
> have networks A and B, each with more than one machine, and each with only
> one public IP (or IP that will be used to link them together). So computer
> A.1 wants to connect to B.1, the security server for A correctly changes the
> destination IP to B's public IP. B's security server gets this packet and
> doesn't know which internal computer to send it to.
>
> The way around it is what we've done with this security server. A's and B's
> security servers create an IPSEC tunnel between them and have route entries
> that say "anything for B's net - route to B's IPSEC IP" and likewise for A.
> Works like a charm because their isn't any DNAT involved. You wouldn't need
> the tunnel, we just needed the data to be secure between the networks.
>
> In the case where you have A, B, and C *and* two networks (say B and C) have
> the same private address range, you have the combination of the two examples
> above put together. A's network thinks B's and C's networks are actually
> different, and a DNAT translation happens on B's and C's security servers.
> What you end up with is a "global address map" that says network A has this
> "public" range (not true public, but only used once within all your
> networks), B has this "public" range, etc... Then anything destined for A
> will be addressed to that "public" range, and A's security server is
> expected to do the DNAT to the real internal IP address.
>
> It's complicated, but it works. And none of our local nets had to get
> renumbered.
>
> One thing that stinks is the one-to-one NAT. Each box has one line DNAT,
> and one line SNAT per internal IP. The nice thing here is the only NAT is
> happening on the security server responsible for those IPs. This lets us
> add more IPs to a network without having to go change all the security
> servers, we just change the one that manages that network. And the load of
> doing the NAT is on the local security server, so if we have a new local
> network with thousands of IPs, we get a more powerful (as in CPU/mem)
> security server just for that network, we don't have to upgrade the whole
> infrastructure to support the increase in NATs of more IPs. That security
> server is the only one that realizes the load of those additional IPs and
> their resultant NATs.

Another project I am working with is a backend secure or top-secret
capable network that will handle traffic to 15,000 - 35,000 separately
administered private networks. I am finding it extremely difficult to acquire
public registered IP addresses in North America for each security server
to NAT address its resources. Many of the 15,000 - 35,000 networks
will have conflicting private addresses. This secure private backbone
will not be connected to the Internet.

I am toying with the idea of using a registered address space
allocated to some other continental IP registry for use in this
virtual link-layer backbone. With appropriate NAT policy, the local
network attached devices, except for the security access servers,
will have no knowledge of the link-layer backbone transport network.
All services advertized by NAT to the link-layer backbone will
be reverse-NAT advertized into each local network as a virtualized
local IP address.

I cannot use the "link-layer" address block reserved by IANA
because the special use is for development of zeroconf IPv4
devices. The operation of these devices on the "link-layer"
address block makes the address space unusable for the secure
backbone service.

IPsec-ESP has problems if the tunnel endpoints are address-translated.

With the "link-layer" transport in question, and that security devices
have both forward NAT and reverse NAT to protect and isolate
the addressing zones, IPsec operations fail.

Local Network A

Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]

Local Network B

Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]

Without encryption, Host-A can communicate with Host-B by addressing
Virtual Host A'

Without encryption, Host-B can communicate with Host-A by addressing
Virtual Host B'

Attempts to link Network A and Network B with IPsec, and other IP tunnel
protocols fails because of the network address translation issues.
Tunnel technology currently requires Network A and Network B tunnel
endpoints to be in separate IP address zones (not sharing the same subnet
or IP addresses).

What will work for security is the use of SSL or TLS at the application
interface to a communications path suchas TCP or IP-Stream. But there are
currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
protocols that are compatible with the endpoints being address translated.

- Steve Hathaway

> Another project I am working with is a backend secure or top-secret
> capable network that will handle traffic to 15,000 - 35,000 separately
> administered private networks. I am finding it extremely difficult to
acquire
> public registered IP addresses in North America for each security server
> to NAT address its resources. Many of the 15,000 - 35,000 networks
> will have conflicting private addresses. This secure private backbone
> will not be connected to the Internet.

Woah, looks like you have a big project. Need a security tech to help you
out?

> I am toying with the idea of using a registered address space
> allocated to some other continental IP registry for use in this
> virtual link-layer backbone.

It doesn't sound to me like you need it. Why get all "real" public IPs when
you're not connected to the Inet and won't need to worry about their traffic
being routed on the Inet? What your project sounds like to me is one large
private network that connects many many private networks. I'm not sure
where the Inet comes into play here. And if it's not involved, why worry
about the expense and headache of having to find/buy enough public IPs to
pull this off?

How about this model. One huge network. If you use the private class A
10.x you get 16 million IP addresses. That should be more than enough for
you, unless you have 35,000 networks and each network has more than an
average of 479 IPs (if this is the case you go to model 2). Each computer
has it's current "real" IP plus it's virtual 10.x IP. Your security
gateways perform the NAT back and forth. This works foolproof with all
protocols including IPSec-ESP (more on that below). Each security gateway
is responsible for correctly routing the 10.x network, and anything with the
virtual IP destination of it's internal computers it DNATs to the correct
internal computer. And then it SNATs everything going out, one-for-one.
Each computer inside gets SNATed to it's own personal 10.x virtual IP.

> With appropriate NAT policy, the local
> network attached devices, except for the security access servers,
> will have no knowledge of the link-layer backbone transport network.

Sounds like you are thinking of a little bit different model. You envision
one routing network and 35,000 private nets joined by this routing network.
Your NAT will only NAT to the gateway (security server) IPs, thus prevent
some protocols (namely IPSec-ESP) from working in some situations (more
below). The model I give above is much better and doesn't have this problem
because in my model *every machine has it's own "routing network" IP*.

> All services advertized by NAT to the link-layer backbone will
> be reverse-NAT advertized into each local network as a virtualized
> local IP address.
>
> I cannot use the "link-layer" address block reserved by IANA
> because the special use is for development of zeroconf IPv4
> devices. The operation of these devices on the "link-layer"
> address block makes the address space unusable for the secure
> backbone service.

Can you explain why? Thanks.

>
> IPsec-ESP has problems if the tunnel endpoints are address-translated.

This is half true. Let's talk about the typical user with several internal
boxes, one NATing gateway to the Internet. And for the sake of argument
let's say that gatway can correctly NAT IPSec (like linux). Internal box A
want's to IPSec to external box X. The gateway NATs the source address to
B, the external IP of the gateway. X thinks it's talking to B and replies
back as such. The gateway DNATs the IPSec back to box A. It's all
transparent and it all works. Now internal box C wants to talk to Y, and
the gateway NATs these packets the same as before. Although IPSec is proto
50 (with no concept of a port) and ESP is port 500 on both ends the gateway
can keep the conversations separate by the external end of the connection.
So in this sense your above statement is false. I have systems right now
that have their end-points NATed and they talk to eachother via IPSec.

Everything will work fine as long as no two computers inside try to IPSec to
the same server on the outside. This is the fault of having both ends of
the ESP set to UDP port 500 and the fact that IPSec is one whole protocol.
If different ports could have been used on the client side and IPSec was
session aware this wouldn't be a problem, but it's not that way so two
internal systems in our above example can't IPSec to the same external
system. So in this sense your above statement is true.

The work around in this example is you get one public IP per internal box
that will IPSec. And any IPSec coming from that box gets SNATed to it's
specific public IP. Then as many boxes as have their own public IP NAT will
be able to connect to the same IPSec server on the outside. And this is how
we make your statement above back to not being true.

This translates to one virtual IP per computer in your model. That's how
you get IPSec to work for your setup and invalidate your above statement.

> With the "link-layer" transport in question, and that security devices
> have both forward NAT and reverse NAT to protect and isolate
> the addressing zones, IPsec operations fail.
>
> Local Network A
>
> Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
> Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]
>
> Local Network B
>
> Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
> Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]
>
> Without encryption, Host-A can communicate with Host-B by addressing
> Virtual Host A'
>
> Without encryption, Host-B can communicate with Host-A by addressing
> Virtual Host B'
>
> Attempts to link Network A and Network B with IPsec, and other IP tunnel
> protocols fails because of the network address translation issues.

Only in your model. So throw that model away and get one that works, like
the one I proposed. It will work. I have it working right now.

> Tunnel technology currently requires Network A and Network B tunnel
> endpoints to be in separate IP address zones (not sharing the same subnet
> or IP addresses).

That's only if you don't (a) NAT and/or (b) have a separate virtual IP for
each box.

> What will work for security is the use of SSL or TLS at the application
> interface to a communications path suchas TCP or IP-Stream. But there are
> currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
> protocols that are compatible with the endpoints being address translated.

????? My above example shows that IPSec would work. And that's not just
theory. I have it working right now. You can say all you want that it
doesn't work, but its working right now. Maybe I'm fooling myself and don't
really understand what you are saying.

And what about ppp over ssh? I also do that to without any problems. As
matter of fact I set my ppp/ssh network up as a WAN that securly routes
between several private networks. And each of these private networks have
only one public IP. And they NAT between them using the ppp/ssh IPs.

no body wrote:

> > Another project I am working with is a backend secure or top-secret
> > capable network that will handle traffic to 15,000 - 35,000 separately
> > administered private networks. I am finding it extremely difficult to
> acquire
> > public registered IP addresses in North America for each security server
> > to NAT address its resources. Many of the 15,000 - 35,000 networks
> > will have conflicting private addresses. This secure private backbone
> > will not be connected to the Internet.
>
> Woah, looks like you have a big project. Need a security tech to help you
> out?
>
> > I am toying with the idea of using a registered address space
> > allocated to some other continental IP registry for use in this
> > virtual link-layer backbone.
>
> It doesn't sound to me like you need it. Why get all "real" public IPs when
> you're not connected to the Inet and won't need to worry about their traffic
> being routed on the Inet? What your project sounds like to me is one large
> private network that connects many many private networks. I'm not sure
> where the Inet comes into play here. And if it's not involved, why worry
> about the expense and headache of having to find/buy enough public IPs to
> pull this off?

The trusted backend network is for the transport of classified, secret, and
time-sensitive communications between trusted entities. The backend
network will not have or provide Internet access. Hundreds or
thousands of separately administered private/public networks, connecting
to this backend network, will have Internet access and include all registered
public networks in their routing zones. They will still need secure connected
access (albeit transparent) to a backend information network. IP addresses
for the backend network must be unique amongst all of the connecting
networks. Addresses in the backend transport network must be hidden
from the local networks and not be part of their routing zones. This is the
reason for both forward-nat and reverse-nat addressing in the security
devices. The routing domain for each security device will be the
trusted client network domain (i.e. NET-A or NET-B) and the backend
transport domain.

A host in NET-A,. when communicating with a resource in NET-B,
sends packets addressed to the virtual destination.

A host in NET-B when returning communications to NET-A, sends
packets addressed to the virtual source.


NET-A Transport Virtual
+-----+ Source +-----+ Source
-->| NAT o-------------->| NAT o-->
Actual / +-----+ +-----+ \ Actual
Source o-- Transport --o Dest
\ +-----+ Destination +-----+ /
<--o NAT |<--------------o NAT |<--
Virtual +-----+ +-----+ NET-B
Dest


The network management service for the trusted backend network has
no authority over IP assignments in any of the connecting entities. IP
addresses in the secure backend transport network must not be used
by any of the connecting client networks. Thus the RFC1918 private
network address space is not usable. A registered address space must
therefore be used even though the backend transport network does
not and will not communicate to the Internet.

>
>
> How about this model. One huge network. If you use the private class A
> 10.x you get 16 million IP addresses. That should be more than enough for
> you, unless you have 35,000 networks and each network has more than an
> average of 479 IPs (if this is the case you go to model 2). Each computer
> has it's current "real" IP plus it's virtual 10.x IP. Your security
> gateways perform the NAT back and forth. This works foolproof with all
> protocols including IPSec-ESP (more on that below). Each security gateway
> is responsible for correctly routing the 10.x network, and anything with the
> virtual IP destination of it's internal computers it DNATs to the correct
> internal computer. And then it SNATs everything going out, one-for-one.
> Each computer inside gets SNATed to it's own personal 10.x virtual IP.
>

The administrative authority for the transport network has no authority
for assignments of RFC1918 private network IPs in the attached client
networks.


>
> > With appropriate NAT policy, the local
> > network attached devices, except for the security access servers,
> > will have no knowledge of the link-layer backbone transport network.
>
> Sounds like you are thinking of a little bit different model. You envision
> one routing network and 35,000 private nets joined by this routing network.
> Your NAT will only NAT to the gateway (security server) IPs, thus prevent
> some protocols (namely IPSec-ESP) from working in some situations (more
> below). The model I give above is much better and doesn't have this problem
> because in my model *every machine has it's own "routing network" IP*.
>
> > All services advertized by NAT to the link-layer backbone will
> > be reverse-NAT advertized into each local network as a virtualized
> > local IP address.
> >
> > I cannot use the "link-layer" address block reserved by IANA
> > because the special use is for development of zeroconf IPv4
> > devices. The operation of these devices on the "link-layer"
> > address block makes the address space unusable for the secure
> > backbone service.
>
> Can you explain why? Thanks.
>

If it were not for the zeroconf project <http://www.zeroconf.org>,
the link-local IP address space would be perfect for my applications.
I had communications with the "zeroconf" designers and their
ties to equipment manufacturers. I posed this question to them,
and their response is -- if any "zeroconf" capable device
becomes attached to the transport network (if using the
link-local ip address space) may cause significant network
malfunctions.

I have also looked into RFC-3330 that describes special purpose
IP networks, to find something usable for my applications. The
link-local IP address block is reserved by IANA for the
explicit use of "zeroconf" capable IPv4 devices.

>
> >
> > IPsec-ESP has problems if the tunnel endpoints are address-translated.
>
> This is half true. Let's talk about the typical user with several internal
> boxes, one NATing gateway to the Internet. And for the sake of argument
> let's say that gatway can correctly NAT IPSec (like linux). Internal box A
> want's to IPSec to external box X. The gateway NATs the source address to
> B, the external IP of the gateway. X thinks it's talking to B and replies
> back as such. The gateway DNATs the IPSec back to box A. It's all
> transparent and it all works. Now internal box C wants to talk to Y, and
> the gateway NATs these packets the same as before. Although IPSec is proto
> 50 (with no concept of a port) and ESP is port 500 on both ends the gateway
> can keep the conversations separate by the external end of the connection.
> So in this sense your above statement is false. I have systems right now
> that have their end-points NATed and they talk to eachother via IPSec.
>

I still need to digest your comments here. Thanks for the insight!

>
> Everything will work fine as long as no two computers inside try to IPSec to
> the same server on the outside. This is the fault of having both ends of
> the ESP set to UDP port 500 and the fact that IPSec is one whole protocol.
> If different ports could have been used on the client side and IPSec was
> session aware this wouldn't be a problem, but it's not that way so two
> internal systems in our above example can't IPSec to the same external
> system. So in this sense your above statement is true.
>
> The work around in this example is you get one public IP per internal box
> that will IPSec. And any IPSec coming from that box gets SNATed to it's
> specific public IP. Then as many boxes as have their own public IP NAT will
> be able to connect to the same IPSec server on the outside. And this is how
> we make your statement above back to not being true.
>
> This translates to one virtual IP per computer in your model. That's how
> you get IPSec to work for your setup and invalidate your above statement.
>
> > With the "link-layer" transport in question, and that security devices
> > have both forward NAT and reverse NAT to protect and isolate
> > the addressing zones, IPsec operations fail.
> >
> > Local Network A
> >
> > Host A [192.168.1.1] --> transport Host-A [14.1.1.1]
> > Virtual Host A' [192.168.1.2] <-- transport Host-B [14.2.2.2]
> >
> > Local Network B
> >
> > Host B [192.168.1.1] --> transport Host-B [14.2.2.2]
> > Virtual Host B' [192.158.1.2] <-- transport Host-A [14.1.1.1]
> >
> > Without encryption, Host-A can communicate with Host-B by addressing
> > Virtual Host A'
> >
> > Without encryption, Host-B can communicate with Host-A by addressing
> > Virtual Host B'
> >
> > Attempts to link Network A and Network B with IPsec, and other IP tunnel
> > protocols fails because of the network address translation issues.
>
> Only in your model. So throw that model away and get one that works, like
> the one I proposed. It will work. I have it working right now.
>
> > Tunnel technology currently requires Network A and Network B tunnel
> > endpoints to be in separate IP address zones (not sharing the same subnet
> > or IP addresses).
>
> That's only if you don't (a) NAT and/or (b) have a separate virtual IP for
> each box.

If I could use the Internet Paradigm, then I see usability with IPsec.
I am still studying the issues of virtualizing specific external addresses
to local addresses. The result would allow communicating with a
remote service by addressing its virtualized local address in the
local network address domain. This reverse NAT would hide the
routing domain and the actual destination of the remote service.

Routers on the Internet are configured with a forward-NAT paradigm.
This translates a physical local address to a virtual address in the
public transport domain.

Reverse NAT will virtualize an external virtual or physical address
associated with a remote resource, into the local network address
space.

Reverse masquerade can be ugly. The entire Internet can be
masqueraded to a local firewall address for incoming data. There
goes security.

>
>
> > What will work for security is the use of SSL or TLS at the application
> > interface to a communications path suchas TCP or IP-Stream. But there are
> > currently few programs that are SSL/TLS compliant. I know of NO IP Tunnel
> > protocols that are compatible with the endpoints being address translated.
>
> ????? My above example shows that IPSec would work. And that's not just
> theory. I have it working right now. You can say all you want that it
> doesn't work, but its working right now. Maybe I'm fooling myself and don't
> really understand what you are saying.
>

I have only studied the IPsec theory, not its application. Thanks again
for this information.

>
> And what about ppp over ssh? I also do that to without any problems. As
> matter of fact I set my ppp/ssh network up as a WAN that securly routes
> between several private networks. And each of these private networks have
> only one public IP. And they NAT between them using the ppp/ssh IPs.

One of my secure applications, currently does not perform TCP/IP
communications.
It uses over 100 leased data circuits with synchronous modems, subrate-DSUs
and RS-232 data lines to communicate between a server and remote public-safety
dispatch and records systems. If I could use Internet carriers to serve TCP/IP

to all my clients, my network addressing and topology problems would be solved.

Current policies of some of my clients require a network infrastructure with
uptime and availability guarantees that are not commensurate with ISP offerings

in our geographic area. The BiSync data protocol is the message transport
to be replaced by TCP. This network of leased serial-synchronous data circuits

currently supports a population of over 14,000 computer systems.

--
Steven J. Hathaway