[This message is converted from WPS-PLUS to ASCII]
ABOUT ILLEGAL ADDRESSING
Just to make things clear for the readers who have had trouble following
the "illegal address" thread...
Assume you have two "planets" (Mars and Venus) that need to
communicate. They bought IPv4 technology (used and cheap) from the Earth
several years ago (Earth is running IPv13 at this time). I know, this is
borderline to plagiarism of an RFC...
They set up a bidirectional communication link between Mars and Venus
(probably can't be done with Ethernet :-)). There are zillions of IP
network numbers that have been used up on BOTH planets. Furthermore,
they need a firewall in between (the Martians don't trust the Venusians;
the Venusians are too busy with "other pursuits" to care).
How can the firewall on Mars be set up? Here is one alternative
(I have COMPLETELY ignored packet-filtering issues for this example):
Mars IP ---------------
Network ----| Application |
| Gateway |---| --------------- ----------
| "A" | | | Application | | Router |
--------------- |---| Gateway |------| 1 |
| | "B" | N1 ----------
| --------------- |
| |
Small |
Ethernet | Mars-Venus
segment | comm. link
(one class C | (N2)
network) |
|
|
|
|
----------
| Router |
| 2 |
----------
|
|
Venus IP
Network
Assuming you have IP application gateway software for all the
applications you need to run across the firewall, this will work EVEN if
you need to interconnect a Mars computer and a Venus computer that have
the exact same IP address... The minimum requirements for this to work are:
a) The Ethernet segment between the two application gateways must have
an IP network number that is unique to BOTH planets.
b) Network numbers N1 and N2 should be taken from Venus' addressing space.
The application gateways can be based on any operating system that runs
a reasonably standard TCP/IP stack (of course, I suggest Alpha AXPs running at
125Mhz or more, you will have trouble killing those with the load, and OSF is
a good platform in my opinion :-)). IP packet forwarding is turned off
(reliably...) in both application gateways, and both gateways use static
routing.
Application gateway A has a default route to the Mars network,
and the normal class C route that allows it to reach
Application gateway B.
Application gateway B has a default route to Router 1 and the normal
class C route that allows it to reach Application gateway A.
Services that run normally on a single TCP connection
(TELNET, HTTP, SMTP, etc.) can be configured indeed by running two
proxies (either two standard ones, or one "big" proxy and one "small"
proxy) back to back. Services that require multiple TCP connections
(e.g. FTP) require two "big" proxies back to back (both proxies must be
able to open TCP connections on demand as the FTP protocol requires).
UDP (or mostly-UDP) services (DNS, NTP, etc.) have to be treated
individually depending on the exact goal that must be achieved.
The whole trick relies on the fact that application proxies introduce
IP addressing "boundaries". If you do not EVER need to interconnect
equipments with colliding network numbers, you only need one proxy.
If you MAY need to interconnect equipments with colliding network numbers,
you will not be able to do it on ONE proxy system running a "classical"
TCP/IP stack. That's why you need TWO systems.
I fully agree with the approach "it is better to get registered network
numbers and fix your network". However, it is a fact of business that you
can tell your customers what they "should do" only to a certain extent.
If you want their business, you may have to consider what they need badly
now instead... On the other hand, I feel very unsure of myself telling a
customer
"you must clean up NOW, then you won't have problems again"
only to tell the customer, in maybe less than a year's time
"OK, now, to handle some IPv6, we will need to change this, this, and this"
I prefer to tell customers that they are better off starting to look at
V6 issues now (at least get some RFCs and drafts), to plan what they will
have to do when they'll need some V6 here and there, and when it starts to
spread on the backbone and when they need V6 to the Internet...
I am not proud enough to claim that ANY firewall installation is "routine".
Last time (believe it or not), I got in trouble because of a new SCSI card that
I was CONVINCED had auto-termination support, so I plugged the external disks
straight into it. Nope. Had to open the manual, and open the machine back to
remove terminators. :-(
But dual-proxy firewalls work and are only slightly harder to install
(i.e. take more installation time) than a "classical" (what's that?) firewall.
--==--==--==--==--
People worry about performance a lot these days, so here are a few
things to discuss (just theories of mine based on rough observations
on real installations, I have not measured this properly in a lab so I
may be completely off-base):
- creating a two-proxy chain adds a bit to "connection setup time"
(especially if your two proxies do full reverse DNS lookup checks, which
does not sound justified for the "inside-firewall" connection setup).
On the other hand, over the Internet, the average connection setup time
will make the "added" bit proportionally small. Furthermore, users
tend to tolerate connection setup delays, if kept within limits.
- adding a second proxy introduces extra data "transit delay".
this is probably only user-visible on terminal-type (telnet, rlogin if
you absolutely have to support it) connections, when you watch
"character echo" delay. This type of traffic is usually not the main type
of traffic on a firewall. Again, the average Internet transit delay will
make the "added" transit delay look small. Nobody cares about extra
transit delay for mail (except maybe Marcus with his IP-over-mail
implementation :-)).
- maximum amount of steady-state throughput that the firewall can handle
should not be reduced significantly by the addition of a second proxy.
I suspect that two correct TCP implementations (one on each side of a
firewall) just view the whole connection as a transport and will
attempt to fill that transport up.
Say you run an FTP session through a double-proxy firewall.
FTP connection setup time may be slightly longer, getting replies from
FTP commands may be slightly longer. But I do not see why the time
required to transfer a large file would be affected by the addition of
a second proxy...
Any comments on this? Anybody has taken the time to measure this
in a controlled environment?
--==--==--==--==--==
To summarize:
1. Illegal address setups CAN be connected to the Internet using
double-proxy techniques. Most of the "basic" Internet functionalities
organizations need CAN be put in place without problems. Performance
impact is small enough to be ignored in many configurations.
2. If you want, you can build such a firewall yourself, using software
available on the Internet, UNIX-like platforms, and maybe some "glue code"
here and there...
3. Of course, Digital Firewall Service consultants (like me) will be
pleased to evaluate your security needs and, if desired, setup
a firewall that implements the security policy you require.
We do double-proxy setups when needed.
4. Some commercial products mentioned on the list also offer
IP-address-translation capabilities. You can also check those offerings.
Regards,
Marc Chatel
Digital Equipment
Annecy, France
E-mail: try Marc .
Chatel @
aeo .
mts .
dec .
com
or chatel_m @
annecy .
enet .
dec .
com
or mchatel @
pax .
eunet .
ch
FAX: (33) 50.64.01.39
|
|
