COM/CORBA/DCOP (was: Hello people. I have some questions)

[Alex Martelli]

"Erno Kuusela" <erno-news at erno.iki.fi> wrote in message
news:ku1yllh7ra.fsf at lasipalatsi.fi...
    ...[we're supposed to be talking about NAT]...
> it does break irc and news and cvs and ntp and icq. servers.

It seems we're talking about different things.  Take news, for
example -- how would NAT break nntp?  Or ntp -- I'm running it
happily right now through NAT (through TWO layers of NAT as it
happens, since both my OpenBSD box _and_ my Zyxel router do
NAT'ting, but that doesn't matter much): how is NAT supposed
to break ntp?

If you explain to me how you believe NAT breaks nntp and ntp,
I'll get a better understanding of what you mean by NAT, I'm
sure -- because I just can't think of how it might (nor cvs
either, but I may be missing some detail of _that_, as I sure
am about irc and icq -- nntp and ntp, OTOH, I know pretty well
and am using right now through the NAT that you say breaks them).


> it does break lots of other stuff too. assuming we're talking
> about 1:n nat here and not n:n.

We're talking about M machines on a private network, to which
are allocated N public internet-routable IP addresses, with
N < M.


> here are are some improtant things off the top of my head that i
> personally use that would not work behind a NAT:
>
>  running your own services
>    remote access from outside
>      ssh
>      vnc
>      X
>      ...
>    http
>    ftp
>    smtp
>    dns

They all work fine as long as the number of separate *servers*
you want to be visible (IP-addressable) from the outside *on the
well-known ports normally associate to these services* is <=N,
of course.  ftp _clients_ using the "active" mode need special
care, which is not hard to supply and which any decent NAT (e.g.,
ipnat) does of course supply -- although it seems everybody and
their brother is going PASV today anyway -- and I have no real
knowledge about 'vnc', but unless it's changed hugely from back
when they called it RFB, it should be the same as http, etc.

Note the specifics, again: how many _distinct_ servers do you
need to be separately IP-addressable on single well-known ports.
Of course you'll never be able to have more of those, than you
own or lease separate public IP addresses.  Apart from this
obvious constraint, everything works just peachy -- NAT includes
DNAT as well as SNAT, obviously.  Indeed, DNAT is one rudimental
way to load-balance multiple servers -- in this case, you may
have K servers, but you do NOT want them to be separately
addressed from the outside -- all requests will come to the
same IP address, and DNAT will loadbalance by round-robin (or
whatever).  [Sure, sure, you can do better than that, but still,
claiming that NAT breaks http serving, when it's so often used
to ENHANCE http serving by rudimental load-balancing, is one
of the things that convinces me you must be referring to something
else than "Network Address Translation" when you say NAT].


>  file sharing service
>    smb
>    nfs
>    ...
>
>  peer-to-peer things
>    freenet
>    gnutella
>    ...

And why ever would THESE be broken by NAT'ting?  Not that I'd
ever want to run stuff as unsafe as smb over the wide-open
internet, but that's a completely different issue of course.


>  protocols that transmit ip addresses in the data payload
>    (some of the these can be fixed by using "ALGs" or hacks
>    that know about the protocol that is being run over tcp
>    and actually actively alter the data payload in the packets
>    travelling through the NAT box (this is commonly done with e.g. FTP))
>    but it only works for protocols that the nat box designer has
>    thought of and know about before hand and is just conceptually
>    too horrible to contemplate

Proxying is "conceptually horrible"?!  Since when?!  Besides,
it doesn't only work for protocols thought of beforehand: as
long as the nat implementation you're using is well designed,
you can add to it proxies written afterwards for the purpose
of hooking to it.  Whenever data and metadata get confused, as
in protocols that use data to carry metadata, the "impedance
mismatch" may need correction, and proxying is a reasonable
way to supply such correction.


>  most udp services (like peer to peer games, ntp, ...)

Take ntp, for example, which I run quite happily.  Why do
you claim NAT breaks it?!  Consider RFC 1305, specifically
http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf
section "2.1. Implementation Model":
"""
In what may be the most common client/server model a client sends
an NTP message to one or more servers and processes the replies as
received. The server interchanges addresses and ports, over-writes
certain fields in the message, recalculates the checksum and returns
the message immediately.
"""
Where does NAT break this, or any other similar UDP-based
protocol?

If you're again referring to _offering_ ntp service to the
outside (you own an atomic clock?-), then we're back to the
server issue -- you can expose as many separately IP-addressable
servers on a single well-known port as you have allocated
public IP numbers, of course.  The funny thing about some
of these examples is that, for example, "offering" more than
one ntp server from a single administrative domain (such as
a private network behind a NAT gateway) is specifically "not
a good thing" per RFC 1305... even if you own a fine personal
collection of atomic clocks, one network should still expose
just one ntp server to the rest of the world, quite apart
from any NAT issues!


>  IP protocols other than udp or tcp
>    tunneling
>    ipsec (ok, i don't personally run this, but it is very
>           important not to break imho)

I don't run it either, but I've read that it's specifically
supported by good NAT implementations.  You _are_ familiar
with http://www.vpnc.org/draft-aboba-nat-ipsec, of course?
While still an internet-draft, it seems pretty good and
mature.  IPSec AH specifically checksums the metadata and
so is of course NAT-incompatible (as well as suffering from
other rigidities related to that), but IPSec ESP is fine,
and other such issues are addressed in the paper.

>    cipe
>    6to4/sit
>    ...
>
> if everyone were behind a nat, no 2 computers on the internet could
> communicate with each other.

Again, I don't understand *WHY* one could possibly think of
saying this!  Typical scenario: my five home computers share
one public IP address (via nat, of course).  So do your three
home computers share another public IP address via NAT.

I choose to expose one NTP server on port 123 of my single
public IP address.  You choose to expose an http service on
port 80 of your single public IP address.  In each case,
DNAT routes requests coming to that port of the NAT box to
the appropriate one of the inside computers (could be more
than one, load-balancing, and NAT blissfully hides internal
administrative issues such as, how many computers do I have,
which ones are working right now, etc, etc -- a *plus*, if
you please:-).  My first home computer suddenly need to
establish an http conversation with your service, fine,
it goes out of my NAT box via SNAT, gets to your NAT box,
which DNATs it to the appropriate one of your PC's, and
the reply comes back.  At the same time your second
computer is querying the NTP server I expose -- much of
a muchness except on port 123 rather than 80.

So *what's the problem?!* -- we're BOTH "behind a NAT",
yet it's obvious that our computers on the internet ARE
communicating with each other through their NAT boxes.
So, again, you MUST mean something different by "NAT",
than I do (and, than I think the acronym _means_:-).


> and the alg idea is fundamentally
> infeasible in the long run given we'd like to run most services
> encrypted before long.

NAT need not interfere with encryption, as long as there
is no data/metadata mix being encrypted.  In the long run,
hopefully IPv6 will be widely implemented (just don't hold
your breath waiting...) and the encrypted-however-you-wish
services will run on *that* infrastructure, not IPv4.

> it also breaks tcp - it tries to keep track of the tcp connections
> that hosts keep open, but times them out if nothing happens in a while

If some specific NAT implementation violates RFC 793, that's
just a bug in that implementation, of course, with no meaning
except that you'd better fix or change that implementation.
It's not particularly hard for NAT to keep track of TCP state
and respect RFC 793 religiously, of course -- ipnat/ipfilter do.

> or the nat box gets rebooted/crashes in the middle of things, or if
> it has a dynamic address, its address changes. that makes the network
> much more fragile.

My NAT box is FAR less likely to reboot than any of my boxes
behind it -- orders of magnitude's difference wrt the Windows
boxes, of course (needing a reboot pretty often to keep them
in somewhat-usable state), but substantially less even wrt the
Linux boxes, just because on those one keeps tuning/rebuilding
kernels, runs Windows emulators, etc, etc.  If I have 3 boxes
that reboot on average twice a day, and three more that
reboot on average twice a week, then a NAT that reboots on
average once a month makes no substantial difference (most
particularly if you count the fact that the boxes are on the
same electrical circuits, so a good proportion of the NAT's
reboots are "common-mode failures" in which the other boxes
are ALSO going belly-up).  Calling this "making the network
MUCH more fragile" is a vast overbid.  Note that, as I have
no redundancy, but rather connect to my ISP via a single modem,
router and phone line, accidents taking that modem, router
and/or line out of commission kill me anyway.  From my logs
I notice the router's PPP is crashing (for durations of
several minutes, typically -- enough to kill TCP connections
with the typical default 5-minute timeout) at intervals of
between 10 and 40 hours, anyway -- and that's with absolutely
no NAT involved at all, just the typical "reliability" of a
typical ADSL supplier, in these days and this part of the
world.  My NAT making this "much more fragile"?!  *PAH*.

Dynamic address leases changing in midstream would be just as
much (or as little) of a problem without any NAT in play, of
course -- NP if you're using robust protocols, crash if you're
using fragile protocols that proceed on the unwarranted
assumption of immutability of IP addresses in a dynamic-IP-
address-assignment world:-).  If this is a problem, it's a
dynamic-IP-address-assigment problem, totally unrelated to
NAT, just like I was saying about DNS and you quote:

> | Of course, I'll have to go with dynamic DNS to match the
> | dynamic IP assignment if I want to offer servers, but that's
> | got nothing to do with NAT'ting -- even just one box with
> | a dynamic IP address would be in the same boat.


> || (unless you allow untrusted users shell accounts on it,
> || but you can't really defend someone with a shell account
> || from rootnig a unix box (including openbsd) anyway).
>
> | I wonder -- when it's consolidated and hardened enough, I
> | might experiment with that.  But anyway, who's happy with
> | a single layer of defense?  I want security in depth, and
>
> yeah, security in depth is good, but the layers are only
> helpful when they are non-trivial to break (follow bugtraq
> for a while to see why defending against local users is a
> futile exercise).

Maybe.  And then again, maybe not.  We'll see what I think
when I have things in a more stable state, and can indeed
start following bugtraq.  Right now I see six entries on
bugtraq's archive about OpenBSD 2.9: three are denial-of-
service issues, one is wrt X11 (which I don't keep on my
OpenBSD box), one about lpd (ditto), and id 2873 is a race
condition for which OpenBSD released patches on June 21st
(exactly 7 days after the race condition was published).

If this is a typical, representative sample of how many
vulnerabilities may 'lurk' in a stripped-down OpenBSD
installation, and how much time it takes to plug them
when they come to light, then I think I can keep up with
things even as a very-part-time sysadm, once I've put
the thing in a good, stable condition.  Of course, I'd
feel far less calm about it were I running something else:-).

> if you don't run any services on the firewall, then you are pretty
> well off.

That depends on how you define "services".  I do plan to
put proxies there, eventually, tripwire, that sort of
things.  But the fewer pieces there are, the fewer pieces
may break, so I'll be watching out not to load the box
down with any substantial fraction of the wealth of
riches easily available for it (I still think I started
out on the right foot by not installing any kind of X
or other graphics on it:-).


> running some servers accessible from the outside might
> prove challenging with a NAT. (unless you run them on
> non-standard ports and/or use some sort of port-forwarding kludge).

"Kludge"?!  Your unexplained detestation for NAT clearly
extends to DNAT just as much as to SNAT, but that's not
explicatory.  Again, *WHY* is it "kludgey" to put the
single public IP address I lease on a machine with a
bare minimum of "stuff", and DNAT services (on their well
known ports, say) to one or more (not that I _plan_ to
do load-balancing, with the 128 Kbps bandwidth I have
outgoing from ADSL, but that's another issue:-) servers
in the DMZ?  Putting the servers right on the machine
that's fully exposed to the "big, bad outside" (thereby
making said machine more fragile -- the more it has on
it, the more stuff can break!) seems far worse to me.


Alex