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

[Erno Kuusela]

In article <9n7t4207k at enews1.newsguy.com>, "Alex Martelli"
<aleax at aleax.it> writes:

| "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 [...]

seems that stray "." character hit an unfortunate spot!

in case you ignored tha "." and are asking why it would break nntp and
ntp servers, it is because the nat box has no way of knowing which
machine it should relay the incoming packets to.

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

ok. in that case you can make many of the non-encrypted
services work like you describe on "servers".

i was talking about 1:n nat.

that still leaves broken the protocols that the nat box
does not know how to handle (typically everything not based
on tcp or udp).

| They all work fine as long as the number of separate *servers*
| you want to be visible (IP-addressable) from the outside *on the

you seem to have this notion that your computer either is a "server"
or it is a "client", and in the "client" case you don't need an ip
address that is visible to the outside world, and they will have all
the stuff i listed broken, including remote access and file sharing
and peer-to-peer apps and games and ipsec and ....


| Apart from this obvious constraint, everything works just peachy

well, yeah, if you want to call it peachy. i would hesitate
to call it internet connectivity though.

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

you can run them pretty happily over the wide-open internet
if you use some packet filtering to restrict connections and/or 
run them over ipsec.

they will be broken for your "client" machines because the
nat box will not know which machine to forward incoming packets
from the outside, because they don't have permanent mappings.
 
|| 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?! 

proxying isn't horrible. what is horrible is that you sniff tcp
connections based on what port they happen to use, and reach inside
and replace bits of the data payload if you guess that it is likely to
represent an ip address.


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

well, yeah, of course people are furiously working around
the breakage introduced by nats. this is a good example
where an ip-based service gets broken and the nat box and/or
service needs to work around it.

how are people supposed to introduce new internet applications
if half the people use nats?

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

well, yeah, if you use one public ip address per offered
service, then you of course can do it.

(...assuming you have root on the nat box and know how to use it and
the nat box supports it and the protocol happens to tolerate it.)

but then you might as well give the real ip address to that computer
and have much less hassle.

| You choose to expose an http service on
| port 80 of your single public IP address. [...]

yeah, yeah, if all of the machines happen to all want
different services, then you can stretch one address
to a couple of machines.

relying on two machines never wanting to use the same service
doesn't strike me as a very industrial strength setup.

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

of course this is an unworkable restriction.

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

yes, the sooner the better... everyone grab as many ipv4 addresses
as you can, fast! then everyoen will have to start to deploy ipv6 :)

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

infact it is impossible, unless the nat has infinite amounts of
memory. it has no way of knowing
whether one end of the connection has just went away for good.

all nat implementations that i have seen have timeouts on tcp
connections.

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

well, yeah, you can explain this away by saying you reboot
other computers often anyway but it still leaves the timeout
question.

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

it is kludgey compared to how straightforwardly things would work if
you just used real ip addresses.

yeah, it works a lot of the time for many things if you put some
effort into it. but it's not how the internet was designed to work.
end-to-end and all that...

you can use a packet filter and/or ipsec to cover yourself
from the "big, bad internet" - don't confuse NAT boxes with firewalls,
even if it's possible to combine these into one physical box.

  -- erno