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