> 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.