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

[Erno Kuusela]

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

| "Erno Kuusela" <erno-news at erno.iki.fi> wrote in message
| news:kug0a2h37i.fsf at lasipalatsi.fi...

|| over here isps tend to sell ip connections with 10.x addresses + nat
|| as "internet" to people and then you can't do anything except
|| browse the web and read email.

| ...and irc and news and cvs and ntp and okbridge and icq and...
| I don't particularly care about video-on-demand at this point
| in time, but with nat &c correctly configured, I see no
| fundamental technical reason it couldn't be made to work.

it does break irc and news and cvs and ntp and icq. servers.

it does break irc client side (dcc) unless you have an ALG kludge.

well, ok, i bet you can come up with a long list of simple tcp
services that it doesn't break.

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

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

 file sharing service
   smb
   nfs
   ...

 peer-to-peer things
   freenet
   gnutella
   ...

 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

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

 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)
   cipe
   6to4/sit
   ...

if everyone were behind a nat, no 2 computers on the internet could
communicate with each other. and the alg idea is fundamentally
infeasible in the long run given we'd like to run most services
encrypted before long.

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

|| there is a good rant about this and other internet breaking stuff
|| at <URL:
|| http://www.technetcast.com/tnc_play_stream.html?stream_id=311>.

| If you can give me URL's to transcripts of this, or other
| _written_ material, I'll be happy to read and ponder over
| them, but I don't do video/audio at this point.

okay...

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

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

|| i've been pretty happy with running packet filtering on my single
|| computer i have at home, but then i don't attempt anything very
|| ambitious functionality wise.

| As for me, I do need to share the ADSL connection among
| half a dozen PC's (both Windows and Linux ones), and also
| eventually run some small servers accessible from the outside
| (unless that means code-red scans tie up all my very modest
| bandwidth, of course:-) -- and I aim to do it all in the
| safest way I can devise.  We'll see...

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

  -- erno